S-TEN/D3.1/clause 5 Requirements for STEP-OWL mapping language
From WikiSTEP
This clause explains the basic structure of STEP and the semantics covered by it. Then basic requirements for a translation to OWL are defined and finally possible ways how to implement a converter are considered.
Basic STEP structure and covered semantics
The semantics of STEP is covered by
- application activity models (AAM) to provided an aid to understanding the scope and information requirements defined in application protocols, using the functional modelling language IDEF0
- EXPRESS based data models, defining formal data-types and constraints. This is split in several hierarchies and layers, see below.
- textual definitions
- mapping between the EXPRESS data models ARM and AIM/MIM, see below
- recommended practises
The EXPRESS modelling language is used at different levels which are build on each other:
- Integrated resources (IR) which are divided into
- Integrated generic resources in the 40 and 50 series
- Integrated application resources in the 100 series
- Application interpreted constructs (AIC) in the 500 series
- STEP modules (1000 series) and traditional non-modularized STEP APs (200 series). At this level we have to deal with two data-models in parallel:
- the Application Reference Model (ARM) which covers the specific application oriented aspects
- the Application Interpreted Model (AIM) for APs respectively Module Interpreted Module (MIM)for the modules. This is what has to be implemented by conforming applications.
- These two models are mapped to each other using a special mapping syntax. See clause 5.1 in APs and modules. The mapping is often rather complex and contain semantic as well.
It should be noted here that super-types and attributes e.g. relations must be introduced by the IRs only. The AICs, modules and APs are only allowed to constrain things further by global and local rules in subtypes.
STEP ARM to MIM/AIM/AIC/IR mapping
The data-model of STEP APs and modules consist of two EXPRESS defined data models the Application Reference Model (ARM) and the Application Interpreted Model (AIM) for APs respectively the Module Interpreted Module (MIM) for modules and a mapping specification between them. For the data conversion all this tree elements ARM, AIM/MIM and mapping have to be taken care. In some areas such a geometry the IR is pretty sufficient. In other areas such a extended product structures things are only clear from the ARM. The mapping links both EXPRESS data models together.
For the purpose of creating ontologies and mapping STEP data to OWL we have to decide which element to take from the ARM and which from the AIM. LKSOFT and LKBALTIC decided to base the development on their proprietary XIM schemas because here ARM and MIM (for modules and AP214) are already merged together. In addition the XIM contains are further specialised ARM concepts (super-ARM) for particular usages, e.g. there is a specialised Organization_person_in_organization_assignment in the role id_owner. These concepts are directly mapped to OWL and so using the XIM schemas and related software simplifies the translation between OWL and STEP significantly.
Requirements for the transformation language:
Open versus closed world
What is means:
- Closed world
- It is assumed that all that is recorded is all that there is.
- If it is only recorded that A is connected to B and A is connected to C, then it is assumed that A is not connected to D.
- Open world
- It is assumed that what is recorded may be only part of what there is.
- To make is clear that A is not connected to D, it must be recorded that the set of all things to which A is connected is {B, C}.
Why it is relevant:
- The closed world assumption is suitable for exchange
- The 'world' is defined by the exchange file
- ISO 10303 relies partly upon a closed world assumption
- The closed world assumption can be made to work for a data warehouse
- This requires the enforcement of procedures for the loading of data into the data warehouse
- ISO 15926-2 relies upon a close world assumption
- Data on the Web is an open world
- An intra-net can be regarded as a data warehouse
- OWL assumes an open world
- There is nothing implicit – if we have closure then this must be stated
Requirement: Define which entities/relations define an open or closed world concept. By default OWL is open world environment. E.g. we may have only one version for a particular product, but there may be other version of the products somewhere around. On the other hand we assume that all property_definition and next_assembly_usage_occurrence (NAUO) for a product_definition are completely available. By this a product_definition is nothing else but the collection of its properties and NAUOs. This interpretation is in accordance with the definition in part 41 of STEP.
Entity attributes defining rdfs:subClassOf or rdf:type
Specify which relation is taken as a member-of or subclass of. E.g. the attribute of_product of a Part_version is a subclass of Part. On the other hand a Product_as_individual_version may be a member of a Part_version.
Too generic supertypes used in STEP
Too often STEP requires to use a supertpye of an entity in one case and to use specialised subtypes in other cases. For the first case specialised subtypes had to be taken as well. STEP is unable to fix such glitches because of upward-compatible issues. However when deriving an OWL ontology from STEP we have the chance to do things right from the beginning on. Example is representation_relationship_with_transformation which is originally defined as non-directed concept, but which is used in the case of assemblies as a definition concepts (the one representation takes part in the definition of the other representation).
Supertype entities to be suppressed
Some supertype entities from STEP are not going to be represented in OWL at all. Example is the generic "product", both IR/MIM and ARM. We only represent specializations such as Part and Document.
Generic attributes on supertypes
Rather often the supertype offers a generic set of string attributes such as id, name, description, role, but then for subtypes on the ARM level these attributes are no longer available because they are occupied by the mapping. Again there is a problem when these attributes are used for the supertype, but then are no longer available for the subtype. Example shape_aspect.name.
In addition often string attribute values are left blank (empty string) or are set to "/NULL" which indicate that the sending system has no value for them. These cases should not be translated to the OWL world.
Invisible entities in ARM to MIM/AIM mapping
The ARM to AIM mapping sometimes require additional or dummy entities to populate, which have no semantic meaning. These entities should be eliminated when transforming the data to the OWL world (and needs to be added when translating data from OWL to the STEP world). Examples are simple properties such as weight which require a property_definition and a measure_with_unit and not needed intermediate property_definition_representation, representation, representation_context.
Individual or Class
STEP does not say whether instances of entities define a class or some individual piece of information. So when creating STEP ontologies we have to add this additional semantic. E.g. instances of Part/Part_version are classes while instances of Product_as_individual/_version are individuals in the OWL sense.
Attribute "name" and Multi linguism
The functionality provided by
ISO/TS 10303-1105:2004 Multi linguism
or the equilvalent constructs in AP214 have to be mapped to the "xml:lang" functionality available in OWL. E.g. for the multi-lingual name of a product we may use something similar to this:
<owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> <rdfs:label xml:lang="en">wine</rdfs:label> <rdfs:label xml:lang="fr">vin</rdfs:label>
Here the product is given two names, "wine" for English and "vin" for France. Note that we are likely going to skip the name of the attribute, in this case "product.name".
Others
Remaining non-public stuff is stripped of.
