S-TEN/D3.1/clause 7 Core STEP-OWL mapping specification

From WikiSTEP

This page defines an Ontology derived from core STEP (ISO 10303) entities into OWL together with a mapping specification so that it is possible to map application data from STEP to OWL and backwards. To explain the details of the mapping we have to refer to both, the STEP ARM (Application Reference Model) and partly the MIM (Modular Integrated Models) that is a specialization of the STEP Integrated Resources (IR).

Contents 1 References 2 General 2.1 Meta levels 2.2 Instance Identifier 2.3 String attributes 2.4 Units, quantities and representation of measure values 2.4.1 Number with unit 2.4.2 Physical quantity value and description 2.4.3 Numbers 2.4.4 Scales 2.4.5 Scales and units 3 Product_class and Product_concept 4 Product_specification and Product_configuration 5 Part 6 Part_version 7 Product_version_relationship 8 Part_view_definition 9 Units, measure values and representation 9.1 Units 9.2 Measurements 9.3 Representation entities 10 Independent and assigned properties 11 Assembly and Product_occurrence 12 Physically realized product 13 Properties for Physically Realized Products 14 Person & Organization

References

A typical OWL data-set for STEP will start with these references:

<rdf:RDF 
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
 xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 
 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 
 xmlns:step="http://owl.wikistep.org/s_ten/d3_1_basic_step_ontology.owl#"

 xmlns="xxx_your_data_set_uri_xxx#" >

General

For the mapping from STEP to OWL we use some common mechanisms defined here.

Meta levels

The STEP-OWL mapping is illustrated by the simple example as shown below. In this example an individual VW Beetle is a member of the following classes:

• a part_version - a specification of what is manufactured;
• a product_specification - a specification of what is supplied to the customer;
• a product_class - a high level grouping within which there may be many product specifications
• a user defined class, such as a classification defined by a hire car company.

STEP application data is available on three available meta levels:

• individual products such as my notebook with a specific serial number "x123456789"
• typical products such as the the "IBM ThinkPad T43"
• classes of typical products such as "notebook types"

For the purpose of clearly separating out these meta levels we define corresponding OWL classes:

<owl:Class rdf:about="#Physical_object"/>

<owl:Class rdf:about="#Class_of_physical_object">
 <owl:equivalentClass>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
   <owl:hasValue rdf:resource="#Physical_object"/>
  </owl:Restriction>
 </owl:equivalentClass>
</owl:Class>

<owl:Class rdf:about="#Class_of_class_of_physical_object">
 <owl:equivalentClass>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
   <owl:hasValue rdf:resource="#Class_of_physical_object"/>
  </owl:Restriction>
 </owl:equivalentClass>
</owl:Class>

The restriction classes defined here ensure that

• a member of Class_of_class_of_physical_object is also a subclass of Class_of_physical_object. So "notebook types" is an individual of type Class_of_class_of_physical_object and is also a sub-class of Class_of_physical_object.
• a member of a Class_of_physical_object is also a subclass of Physical_object. So "IBM ThinkPad T43" is an individual of type Class_of_physical_object and of type "notebook types" and is also a sub-class of Physical_object.
• My notebook "x123456789" is an individual of type "IBM ThinkPad T43" and also of type Physical_object.

It is important to understand that my notebook "x123456789" is not of type "notebook types". In STEP these things are not always clearly separated from each other which can lead to some confusion. When representing STEP data in the semantic web we must ensure this clarity because otherwise reasoning will not work.

Instance Identifier

The instance-identifier in a STEP-File or the persistent-label in the SDAI environment maps to rdf:about or rdf:ID attributes and prefix the number with "_" because "#" is not possible here.

String attributes

ISO 10303-41 defines the following STRING types with a specific semantic which are used throughout STEP for all IR/AIC/AIM/MIM schema:

TYPE identifier = STRING; END_TYPE;
TYPE label = STRING; END_TYPE
TYPE text = STRING; END_TYPE;

They map to corresponding OWL constructs defined in the core STEP ontology:

<owl:DatatypeProperty rdf:ID="label">
  <rdfs:range rdf:resource="&xsd;string"/>
  <rdfs:comment>XA label is an alphanumeric string that represents the human-interpretable name of
                something and shall have a natural-language meaning.</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="text">
  <rdfs:range rdf:resource="&xsd;string"/>
  <rdfs:comment>A text is an alphanumeric string intended to be read and understood by a human being.
                It is for information purposes only.</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="identifier">
  <rdfs:range rdf:resource="&xsd;string"/>
  <rdfs:comment>An identifier is a string suitable for identifying some product data.</rdfs:comment>
</owl:DatatypeProperty>

The specialized string types are used by many entity attributes such as

  id : identifier;
  name : label;
  description : text;
  version_id : identifier;
  role : label;

In OWL this maps to corresponding specialized DatatypeProperties which are sub-properties of the ones defined above:

<owl:DatatypeProperty rdf:ID="id">
  <rdfs:subPropertyOf rdf:resource="#identifier"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="version_id">
  <rdfs:subPropertyOf rdf:resource="#identifier"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="name">
  <rdfs:subPropertyOf rdf:resource="#label"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="role">
  <rdfs:subPropertyOf rdf:resource="#label"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="description">
  <rdfs:subPropertyOf rdf:resource="#text"/>
</owl:DatatypeProperty>

The handling of ARM-attributes shall follow their corresponding mapping on the MIM/IR level.

Example usage:

 <step:id rdf:datatype="&xsd;string">4711</step:id>
 <step:name rdf:datatype="&xsd;string">l-bracket assembly</step:name>
 <step:description rdf:datatype="&xsd;string">L-Bracket and Fixings</step:description>

Units, quantities and representation of measure values

In a first approach for D3.1 we created a detailed "data model" kind of ontology for both ISO 1000 and ISO 31 to explicitly represent the structural concepts defined in these standards. The main problem addressed in this approach was to clearly work out the differences between the concepts of a unit, physical quantities and properties. This first approach had a problem that measurement values could not be fully addresses as a scaling relative to a unit value which is required for ISO 15692 ontologies. Also the later linking with a mathematical ontology would have been problematic.

We therefore developed new ontologies in this area with the focus of having a measurement represented as scaling of a unit value. The scaling is represented in OWL as an object property.

Number with unit

The path to a formal approach to units of measure begins with the concept of "number with unit". This is a number with some information about what it means. For example we may have:

[  a              myOnt:number_with_unit ;
   myOnt:number   "27.0" ;
   myOnt:unit     si:metre ]

NOTE Examples are given in http://www.w3.org/DesignIssues/Notation3. They should be readable even if you do not know the format.

The problem with "number with unit" is that its meaning is vague. Is it not just a number, but is it a length or an information object which describes a length?

Physical quantity value and description

The 27.0 metres is a length. Length is a "category of comparable physical quantities". (This phrase is taken from the introduction to ISO 31-0.) The length of 27.0 metres may be described by an information object that consists of a number and a unit. For example we may have:

[  a        myOnt:length ;
   myOnt:described_by
            [ a              myOnt:physical_quantity_description
              myOnt:number   "27.0" ;
              myOnt:unit     si:metre ]  ]

There is nothing wrong with this approach, but it ignores the mathematics of the relationship between categories of physical quantities and numbers. As a result we have to invent new information objects for all related concepts such as length intervals, probability distributions over length, etc..

Numbers

In the examples so far, we have regarded numbers as just literals. If we wish to use mathematics it is necessary to recognize that:

• A number is an object. A number can have a representation in decimal or hex. Some numbers have names, such as "pie" (3.14...).
• A number space consists of a set of numbers, and relationships between the numbers which define the structure of the space. A number space is more than just a set.

A number space can be regarded as an owl:Class. Hence the literal "27" in the examples above can be replaced by the anonymous object:

[  a              maths:real ;
   maths:decimal  "27.0"  ]

or more concisely, just:

[  maths:decimal  "27.0"  ]

Scales

A scale is a function from a "category of comparable physical quantities" (or "physical quantity space") to a number space. A physical quantity space consists of a set of physical quantities, and relationships between the physical quantities which define the structure of the space.

A scale has properties (such as being increasing or continuous) which depend upon the structures of its domain and range.

An ontology can define celsius and metre_scale, as follows:

:celsius      a             owl:FunctionalProperty;
             rdfs:domain  iso31:temperature  ;
             rdfs:range   maths:real  .
:metre_scale  a             owl:FunctionalProperty;
             rdfs:domain  iso31:length  ;
             rdfs:range   maths:real  .

Using an ontology of scales, the representation of a physical quantity value is simple, rigorous and concise. For the length 27.0 we have:

[  a               myOnt:length ;
  si:metre_scale  [  maths:decimal  "27.0"  ]  ]

or more concisely:

[  si:metre_scale  [  maths:decimal  "27.0"  ]  ]

Similarly the representation of the temperature 20 degrees Celsius is:

[  si:celsius  [  maths:decimal  "20.0"  ]  ]

Scales and units

The suffix "_scale" has been included in the ID "metre_scale", because the SI concept of metre is not a scale but a named length. In an ontology, the metre would be:

:metre        a            iso31:length  ;
              rdfs:comment "Defined by the BIPM."  .

Because metre_scale (like all other scales derived from units) is linear, the metre_scale is completely defined by the statements:

:metre_scale  a  maths:linear_function  .
:metre  :metre_scale  [  maths:decimal  "1.0"  ]  .

The standards on units are not good at distinguishing between units and scales. It is clear that all the SI base units are indeed units and not scales. The only two scales in common use are Celsius and Fahrenheit.

NOTE The Kelvin is a unit. It is a named temperature. The Celsius is not a unit.

The temperature scale ITS-90 (see http://www.its-90.com) is a scale. It is a practical approximation to the scale, that is derived from the Kelvin unit.

Product_class and Product_concept

ARM-Express:

ENTITY Market;
  name : STRING;
  market_segment_type : OPTIONAL STRING;
END_ENTITY; 

ENTITY Product_concept;
  id : STRING;
  name : STRING;
  description : OPTIONAL STRING;
  target_market : OPTIONAL Market;
UNIQUE
  UR1 : id;
END_ENTITY;

ENTITY Product_class
  SUBTYPE OF (Product_concept);
  version_id : OPTIONAL STRING;
  level_type : OPTIONAL STRING;
WHERE
  WR1: NOT EXISTS(SELF\Product_concept.target_market);
END_ENTITY;

ENTITY Product_class_relationship;
  description : OPTIONAL STRING;
  relating : Product_class;
  related : Product_class;
  relation_type : STRING;
END_ENTITY;

For Product_class_relationship.relation_type the following values are defined:

• 'derivation': the related Product_class is derived from the relating Product_class;
• 'hierarchy': the relating Product_class is on a higher level in the hierarchy of Product_class instances than the related Product_class;
• 'substitution': the related Product_class replaces the relating Product_class;
• 'version sequence': the relating Product_class is the preceding version and the related Product_class is the following version.

For the restricted scope of the technological validation we support only 'hierarchy'.

MIM/IR-Express:

ENTITY product_concept_context
  SUBTYPE OF (application_context_element);
  market_segment_type : label;
END_ENTITY;

ENTITY product_concept;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  market_context : product_concept_context;
UNIQUE
  UR1 : id;
END_ENTITY;

ENTITY product_class
  SUBTYPE OF (product_concept, characterized_object);
END_ENTITY;

ENTITY product_concept_relationship;
  name : label;
  description : OPTIONAL text;
  relating_product_concept : product_concept;
  related_product_concept : product_concept;
END_ENTITY;

The ARM entity Market is not mapped to a class by itself but is only converted into a dataTypeProperty. On the OWL-level both ARM/IR entities Product_concept and Poduct_class are covered by one class only:

<Class_of_class_of_physical_object rdf:ID="Product_class">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
</Class_of_class_of_physical_object>

<owl:DatatypeProperty rdf:ID="market">
  <rdfs:subPropertyOf rdf:resource="#name"/>
  <rdfs:domain rdf:resource='#Product_class'/>
  <rdfs:range rdf:resource="&xsd;string"/>
</owl:DatatypeProperty>

Issue: Product_class.id should be a functional property.

The reason is that the splitting of the concept in STEP into two entities is more because of historical reasons. A product_class can't be referenced by property_definition. Only when introducing a new subtype which includes characterized_object this is possible. is that from a users and logical perspective they are very similar.

The fact that a Product_class (ARM) is not allowed to have a target_market is also questionable on the IR level because product_concept.market_context is a mandatory attribute which requires to have a product_concept_context anyway, only it may have a name with an empty string. We consider this as a flaw of the STEP standard and will write a SEDS about this.

A Product_class_relationship with the relation type hierarchy shall be mapped into a subClassOf statement.

Example:

#200=APPLICATION_CONTEXT();
#201=PRODUCT_CONCEPT_CONTEXT('German car market',#200,);
#202=PRODUCT_CLASS('pc1','VW Beetle',,#201,$,$);
#203=PRODUCT_CLASS('pc2','VW Beetle CD',,#201,$,$);
#204=PRODUCT_CONCEPT_RELATIONSHIP('hierarchy',,#202,#203);

<step:Product_class rdf:about="#_202">
  <step:id rdf:datatype="&xsd;string">pc1</step:id>
  <step:name rdf:datatype="&xsd;string">VW Beetle</step:name>
  <step:market rdf:datatype="&xsd;string">German car market</step:market>
</step:Product_class>
<step:Product_class rdf:about="#_203">
  <rdfs:subClassOf rdf:resource="#_202"/>
  <step:id rdf:datatype="&xsd;string">pc2</step:id>
  <step:name rdf:datatype="&xsd;string">VW Beetle CD</step:name>
  <step:market rdf:datatype="&xsd;string">German car market</step:market>
</step:Product_class>

Product_specification and Product_configuration

ARM-Express:

ENTITY Product_configuration;
  id : STRING;
  name : STRING;
  description : OPTIONAL STRING;
  item_context : Product_concept;
INVERSE
  corresponding_design : SET [0:1] OF Item_design_association FOR configuration;
END_ENTITY; 

ENTITY Product_specification
  SUBTYPE OF (Product_configuration);
  version_id : OPTIONAL STRING;
  SELF\Product_configuration.item_context : Product_class;
  defining_specifications : SET [0:?] OF Specification;
END_ENTITY; 

ENTITY Specification;
  id : STRING;
  version_id : OPTIONAL STRING;
  name : OPTIONAL STRING;
  description : OPTIONAL STRING;
  category : Specification_category;
  package : BOOLEAN;
END_ENTITY; 

ENTITY Specification_category;
  id : STRING;
  description : STRING;
  implicit_exclusive_condition : BOOLEAN;
END_ENTITY;

For the purpose of the technological validation we exclude Specification, Specification_category and all the extended specification logic as defined in module ISO/TS 10303-1103:2005 Product class.

IR/MIM-Express:

ENTITY configuration_item;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  item_concept : product_concept;
  purpose : OPTIONAL label;
END_ENTITY;

ENTITY product_identification
  SUBTYPE OF (configuration_item, characterized_object);
  SELF\configuration_item.item_concept : product_class;
WHERE
  WR1: SIZEOF(QUERY (cd <* USEDIN ( SELF,
     'CONFIGURATION_MANAGEMENT_SCHEMA.CONFIGURATION_DESIGN.CONFIGURATION' ) 
     ( 'PRODUCT_DEFINITION_SCHEMA.'+ 'PRODUCT_DEFINITION_FORMATION' 
     IN  TYPEOF( cd.design ) )  AND 
     ( SIZEOF ( QUERY ( prpc <* USEDIN(cd. design\product_definition_formation.of_product,
     'PRODUCT_DEFINITION_SCHEMA.PRODUCT_RELATED_PRODUCT_CATEGORY.PRODUCTS') | 
     prpc. name IN ['part' , 'raw material' , 'tool'] ) ) >0 ) ) ) <=1;
  WR2: NOT ( 'CONFIGURATION_MANAGEMENT_SCHEMA.'+ 'CONFIGURABLE_ITEM' IN  TYPEOF( SELF  ) ) 
            XOR ( 'SPECIFIED_PRODUCT_MIM.'+ 'PRODUCT_SPECIFICATION' IN TYPEOF ( SELF ) );
END_ENTITY; 

ENTITY configurable_item
  SUBTYPE OF (configuration_item);
  item_concept_feature : SET [1:?] OF product_concept_feature_association;
END_ENTITY;

ENTITY product_specification
 SUBTYPE OF (product_identification, configurable_item);
END_ENTITY;

ENTITY product_concept_feature_association;
  name : label;
  description : OPTIONAL text;
  concept : product_concept;
  feature : product_concept_feature;
END_ENTITY;

ENTITY product_concept_feature;
  id : identifier;
  name : label;
  description : OPTIONAL text;
END_ENTITY;

For the mapping to OWL we combine the ARM entities Product_configuration and Product_specification into a single class called Product_specification. On the IR/MIM this is equivalent to the combination of configuration_item, product_identification, configurable_item and product_specification:

<Class_of_class_of_physical_object rdf:ID="Product_specification">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
      <owl:allValuesFrom rdf:resource="#Product_class"/>
    </owl:Restriction>
  </rdfs:subClassOf>
  <owl:disjointWith rdf:resource="#Product_class"/>
</Class_of_class_of_physical_object>

All individuals of type Product_specification must also be sub-classes of a class that is of type Product_class. This covers the ARM relation

Product_configuration.item_context -> Product_concept
Product_specification.item_context -> Product_class

Example:

#220=CONFIGURATION_ITEM('pi1','VW Beetle \X2\2013\X0\ S_101',
                        '1200cc, sunroof, red paint, leather seats',#203,$);

<step:Product_specification rdf:about="#_220">
  <rdfs:subClassOf rdf:resource="#_203"/>
  <step:id rdf:datatype="&xsd;string">pi1</step:id>
  <step:name rdf:datatype="&xsd;string">VW Beetle / S_101</step:name>
  <step:description rdf:datatype="&xsd;string">1200cc, sunroof, red paint, leather seats</step:description>
</step:Product_specification>

Here the AIM/IR instance of type configuration_item is converted into an OWL individual of type Product_specification. When converting this data back from OWL to STEP this may result in an instance of type product_specification. We consider this as being equivalent for the given example.

Part

ARM-Express:

ENTITY Product;
  id : STRING;
  name : OPTIONAL STRING;
  description : OPTIONAL STRING;
END_ENTITY

ENTITY Part
  SUBTYPE OF (Product);
WHERE
  WR1: SIZEOF(['part', 'raw material', 'tool']*types_of_product(SELF))=1;
END_ENTITY;

IR/MIM-Express:

ENTITY product_context
  SUBTYPE OF (application_context_element);
  discipline_type : label;
END_ENTITY;

ENTITY product;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  frame_of_reference : SET [1:?] OF product_context;
END_ENTITY;

ENTITY product_category;
  name : label;
  description : OPTIONAL text;
DERIVE
  id : identifier := get_id_value (SELF);
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'ID_ATTRIBUTE.IDENTIFIED_ITEM')) <= 1;
END_ENTITY; 

ENTITY product_related_product_category
  SUBTYPE OF (product_category);
  products : SET [1:?] OF product;
END_ENTITY; 

ARM-Mapping: Every instance of Part (ARM) becomes an individual of class step:Part and vice versa. In the case that a product_related_product_category with the name raw_material or tool is present that the subclass step:Raw_material respectively step:Tool is to be used.

The attributes id, name and description maps to corresponding datatype properties

The fact that a Part is a subtype of Product is not available in OWL.

MIM/IR mapping: On the MIM Part maps to product. The product attribute "frame_of_reference : SET [1:?] OF product_context" is not mapped to OWL and consequently product_context, its supertype application_context_element, the referenced application_context and the referring application_protocol_definition are not mapped to OWL.

<Class_of_class_of_physical_object rdf:ID="Part">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
</Class_of_class_of_physical_object>

Example:

#300=APPLICATION_PROTOCOL_DEFINITION(,'automotive_design',2007,#301);
#301=APPLICATION_CONTEXT('mechanical design');
#302=PRODUCT_CONTEXT(' ',#301,' ');
#308=PRODUCT_RELATED_PRODUCT_CATEGORY('part',$,(#310,...));
#310=PRODUCT('A0001','VW Beetle \X2\2013\X0\ P_101',' ',(#302));

<step:Part rdf:ID="_310">
  <step:id rdf:datatype="&xsd;string">A0001</step:id>
  <step:name rdf:datatype="&xsd;string">VW Beetle / P_101</step:name>
</step:Part>

Part_version

ARM-Express:

ENTITY Product_version;
  id : STRING;
  description : OPTIONAL STRING;
  of_product : Product;
END_ENTITY;

ENTITY Part_version
  SUBTYPE OF (Product_version);
  SELF\Product_version.of_product : Part;
END_ENTITY;

TYPE version_or_definition = SELECT (
  Product_version,
  Product_view_definition);
END_TYPE; 

ENTITY Item_design_association;
  configuration : Product_configuration;
  design : version_or_definition;
UNIQUE
  UR1 : configuration, design;
END_ENTITY; 

IR/MIM-Express:

ENTITY product_definition_formation;
  id : identifier;
  description : OPTIONAL text;
  of_product : product;
UNIQUE
  UR1 : id, of_product;
END_ENTITY;

TYPE configuration_design_item = SELECT (
  product_definition,
  product_definition_formation);
END_TYPE; 
 
ENTITY configuration_design;
  configuration : configuration_item;
  design : configuration_design_item;
DERIVE
  name : label := get_name_value (SELF);
  description : text := get_description_value (SELF);
UNIQUE
  UR1 : configuration, design;
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'NAME_ATTRIBUTE.NAMED_ITEM')) <= 1;
  WR2: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'DESCRIPTION_ATTRIBUTE.DESCRIBED_ITEM')) <= 1;
END_ENTITY;

ARM-mapping: Every instance of Part_version (ARM) becomes an individual of class step:Part_version and vice versa. The attributes id and description maps to corresponding datatype properties The attribute SELF\Product_version.of_product : Part; is turned into a Part_version-instance subTypeOf of Part-instance statement. The fact that a Part_version is a subtype of Product_version is not available in OWL.

The relation established by Item_design_association is converted into subClassOf statement, making an individual of type Part a subClassOf another individual of type Product_specification.

AIM-mapping: Nothing in additional.

Open question: What to do with the unique ur1 constraint'

Issue: AP214 requires in the mapping of the ARM entity Product_design the additional constraint "{configuration_design.name = 'product design'}". It is not clear why this is not required in the corresponding STEP-modules. This needs to be further investigated and may result in a SEDS.

<Class_of_class_of_physical_object rdf:ID="Part_version">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
  <rdfs:subClassOf>
   <owl:Restriction>
    <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
    <owl:allValuesFrom rdf:resource="#Part"/>
   </owl:Restriction>
  </rdfs:subClassOf>
</Class_of_class_of_physical_object>

Example:

#230=CONFIGURATION_DESIGN(#220,#311);
#231=NAME_ATTRIBUTE('product design',#230);
#311=PRODUCT_DEFINITION_FORMATION('1',$,#310);

<step:Part_version rdf:ID="_311">
  <rdfs:subClassOf rdf:resource="#_310"/>
  <rdfs:subClassOf rdf:resource="#_220"/>
  <step:id rdf:datatype="&xsd;string">1</step:id>
</step:Part_version>

Issue: What happen is the OWL data does not contain such a statement? <rdfs:subClassOf rdf:resource="#_1733"/>. Maybe we then have to create an artificial Part instance. And what happens if there are more than one such statements? - is it then a different part-instance for each? - duplicating of data.

Product_version_relationship

ARM-Express:

ENTITY Product_version_relationship;
  relation_type : OPTIONAL STRING;
  description : OPTIONAL STRING;
  relating_version : Product_version;
  related_version : Product_version;
WHERE
  WR1: relating_version :<>: related_version;
  WR2: EXISTS(relation_type) OR (TYPEOF(SELF\Product_version_relationship) <> TYPEOF(SELF));
END_ENTITY;

The following relation_types are pre-defined:

• 'derivation'
• 'hierarchy'
• 'sequence'

For the purpose of technological validation we will support only 'sequence'.

AIM-Express:

ENTITY product_definition_formation_relationship;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  relating_product_definition_formation : product_definition_formation;
  related_product_definition_formation : product_definition_formation;
END_ENTITY; 

ARM-MIM mapping: The mapping is straightforward 1:1. There is nothing special to consider.

ARM-OWL mapping: In STEP the relation between product version is made an instance by its own so that it is possible to assign attributes. In practise however this is not really needed and so this entity will map to an ObjectProperty. Because we decided to not support the supertype Product_version but only specific subtypes such as part_version the ObjectProperty will be between Part_versions only. In the case of the relation type 'sequence' the property is transitive and we can also define an inverse relation:

<owl:ObjectProperty rdf:ID='part_version_predecessor'>
  <rdf:type rdf:resource="&owl;TransitiveProperty" />
  <rdfs:domain rdf:resource='#Part_version'/>
  <rdfs:range rdf:resource='#Part_version'/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID='part_version_successor'>
  <owl:inverseOf rdf:resource='#part_version_predecessor'/>
  <rdfs:domain rdf:resource='#Part_version'/>
  <rdfs:range rdf:resource='#Part_version'/>
</owl:ObjectProperty>

Example: In this example the Part #320 has the two versions "1" and "A". Version "A" is the more recent one.

#320=PRODUCT('A0002','Engine-4/50KW-BX',,(#302));
#321=PRODUCT_DEFINITION_FORMATION('1',$,#320);
#323=PRODUCT_DEFINITION_FORMATION('A',$,#320);
#325=PRODUCT_DEFINITION_FORMATION_RELATIONSHIP(,'sequence',$,#321,#323);

<step:Part_version rdf:about="#_321">
  ...
</step:Part_version>
<step:Part_version rdf:about="#_323">
  <step:part_version_successor rdf:resource="#_321"/>
  ...
</step:Part_version>

Part_view_definition

ARM Express:

ENTITY Product_view_definition;
  id : OPTIONAL STRING;
  name : OPTIONAL STRING;
  additional_characterization : OPTIONAL STRING;
  initial_context : View_definition_context;
  additional_contexts : SET [0:?] OF View_definition_context;
  defined_version : Product_version;
WHERE
  WR1: NOT (initial_context IN additional_contexts);
  WR2: EXISTS(id) OR (TYPEOF(SELF\Product_view_definition) <> TYPEOF(SELF));
END_ENTITY;

ENTITY Part_view_definition
  SUBTYPE OF (Product_view_definition);
  SELF\Product_view_definition.defined_version : Part_version;
END_ENTITY

AIM/IR Express:

ENTITY product_definition;
  id : identifier;
  description : OPTIONAL text;
  formation : product_definition_formation;
  frame_of_reference : product_definition_context;
DERIVE
  name : label := get_name_value (SELF);
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'NAME_ATTRIBUTE.NAMED_ITEM')) <= 1;
END_ENTITY;

ENTITY product_definition_context
  SUBTYPE OF (application_context_element);
  life_cycle_stage : label;
END_ENTITY;

The ARM to AIM mapping of Part_view_definition requires a string constraint

product_definition
{product_definition.frame_of_reference -> product_definition_context
 product_definition_context <= application_context_element
 application_context_element.name = 'part definition'}

ARM-OWL mapping: Every instance of Part_view_definition (ARM) becomes an individual of class step:Part_view_definition. However not every individual of class step:Part_view_definition becomes an instance of Part_view_definition. This is only the case for those individuals of class step:Part_view_definition for which explicit "Part_version-instance subTypeOf of Part_view_definition-instance" statements are defined.

The attributes id, name and additional_characterization maps to corresponding datatype properties if present. additional_characterization is taken as description.

TBD: Mapping of initial_context: View_definition_context and additional_contexts: SET [0:?] OF View_definition_context

The attribute "SELF\Product_view_definition.defined_version: Part_version" is turned into a "Part_version-instance subTypeOf of Part_view_definition-instance" statement. By this a Part_version becomes the intersection of all its Part_view_definitions.

The fact that a Part_view_definition is a subtype of Product_view_definition is not available in OWL.

<Class_of_class_of_physical_object rdf:ID="Part_view_definition">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
</Class_of_class_of_physical_object>

Example:

#303=PRODUCT_DEFINITION_CONTEXT('part definition',#301,'design');
#311=PRODUCT_DEFINITION_FORMATION('1',$,#310);
#312=PRODUCT_DEFINITION('1',$,#311,#303);
#314=PRODUCT_DEFINITION('2',$,#311,#303);

<step_Part_version rdf_about="#_311">
  <rdfs:subClassOf rdf:resource="#_312"/>
  <rdfs:subClassOf rdf:resource="#_314"/>
<step_Part_version>
<step:Part_view_definition rdf:ID="_312">
  <step:id rdf:datatype="&xsd;string">1</step:id>
  ...
</step:Part>
<step:Part_view_definition rdf:ID="_314">
  <step:id rdf:datatype="&xsd;string">2</step:id>
  ...
</step:Part>

Units, measure values and representation

We address this topic on the MIM/IR level only because the ARM level gives no further insight.

Here a typical example of a representation with measure with units values:

#500=(LENGTH_UNIT()NAMED_UNIT(*)SI_UNIT($,.METRE.));
#501=(MASS_UNIT()NAMED_UNIT(*)SI_UNIT(.KILO.,.GRAM.));

#514=REPRESENTATION_CONTEXT(' ',' ');
#515=REPRESENTATION(' ',(#516),#514);
#516=(LENGTH_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()
      MEASURE_WITH_UNIT(LENGTH_MEASURE(4.5),#500)REPRESENTATION_ITEM(' '));
 
#524=REPRESENTATION_CONTEXT(' ',' ');
#525=REPRESENTATION(' ',(#526),#524);
#526=(MASS_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()MEASURE_WITH_UNIT(
      MASS_MEASURE(750),#501)REPRESENTATION_ITEM(' '));

The meaning is as follows:

• First the units are defined in which the measurement is made, here it is meter (#500) and kilogram (#501).
• Then two representations are defined (#515 and #525), each with its own representation context (#514 and #524).
• Each representation contains a measure_representation_item. One for "4.5 m" (#516) and the other for "750 Kg" (#526).

This maps into this (almost) equivalent OWL representation:

<iso_31:Length rdf:about="#_516">
  <iso_1000:meter_scale>
    <iso:Real>
      <value rdf:datatype="&xsd;double">4.5</value>
    </iso:Real>
  </iso_1000:meter_scale>
</iso_31:Length>
  
<iso_31:Mass rdf:about="#_526">
  <iso_1000:kilogram_scale>
    <iso:Real>
      <value rdf:datatype="&xsd;double">750</value>
    </iso:Real>
  </iso_1000:kilogram_scale>
</iso_31:Mass>

Below we explain the details of the used express model and its mapping into OWL.

Units

• a unit is either a named_unit or a derived_unit. For D3.1 we address only named_unit.
• a named_unit refers to dimensional exponents all all the 7 base SI unit. The exponents are typically integer numbers. E.g. to represent acceleration (m**/s) the length_exponent = 2 and time_exponent = -1;
• a named_unit is either an si_unit or a conversion_based_unit or a context_dependent_unit. For D3.1 we consider only si_unit'
• an si_unit defines wraps up the pre-defined units defined in ISO 1000. These are the 7 base units and 21 selected derived_units.
• an si_unit may have one of the common si_prefix such as mega or milli.
• for the 7 base_units and plane angle, solid angle, area, volume and ration specific subtypes are defined in addition which have to be used.

TYPE unit = SELECT (
  derived_unit,
  named_unit);
END_TYPE;

ENTITY named_unit
  SUPERTYPE OF ((ONEOF (si_unit, conversion_based_unit, context_dependent_unit) ANDOR 
   ONEOF (length_unit, mass_unit, time_unit, electric_current_unit, 
     thermodynamic_temperature_unit, amount_of_substance_unit, luminous_intensity_unit, 
     plane_angle_unit, solid_angle_unit, area_unit, volume_unit, ratio_unit)));
  dimensions : dimensional_exponents;
END_ENTITY; 

ENTITY dimensional_exponents;
  length_exponent : REAL;
  mass_exponent : REAL;
  time_exponent : REAL;
  electric_current_exponent : REAL;
  thermodynamic_temperature_exponent : REAL;
  amount_of_substance_exponent : REAL;
  luminous_intensity_exponent : REAL;
END_ENTITY; 

TYPE si_prefix = ENUMERATION (
  exa, peta, tera, giga,
  mega, kilo, hecto, deca,
  deci, centi, milli, micro,
  nano, pico, femto, atto );
END_TYPE; 

ENTITY si_unit
  SUBTYPE OF (named_unit);
  prefix : OPTIONAL si_prefix;
  name : si_unit_name;
DERIVE
  SELF\named_unit.dimensions : dimensional_exponents := dimensions_for_si_unit(name);
END_ENTITY;
-- Note: the dimensional exponents are set by function dimensions_for_si_unit

ENTITY length_unit
  SUBTYPE OF (named_unit);
WHERE
  WR1: (SELF\named_unit.dimensions.length_exponent = 1.0) 
   AND (SELF\named_unit.dimensions.mass_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.time_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.electric_current_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.thermodynamic_temperature_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.amount_of_substance_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.luminous_intensity_exponent = 0.0);
END_ENTITY; 
 
ENTITY mass_unit
  SUBTYPE OF (named_unit);
WHERE
  WR1: (SELF\named_unit.dimensions.length_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.mass_exponent = 1.0) 
   AND (SELF\named_unit.dimensions.time_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.electric_current_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.thermodynamic_temperature_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.amount_of_substance_exponent = 0.0) 
   AND (SELF\named_unit.dimensions.luminous_intensity_exponent = 0.0);
END_ENTITY;

ARM to OWL mapping: The instances on units (#500 and #501) have a static characteristic. Therefore the corresponding OWL constructs will be defined only once in the is1000 ontology and can then be used many times. On further "application data" is needed to represent units.

In the ISO1000 ontology we have predefined functional properties for all units, e.g.:

<owl:FunctionalProperty rdf:about="#metre_scale">
  <rdfs:label xml:lang="en">metre</rdfs:label>
  <rdfs:comment>defined in ISO 1000:1992</rdfs:comment>
</owl:FunctionalProperty>
<owl:FunctionalProperty rdf:about="#kilogram_scale">
  <rdfs:label xml:lang="en">kilogram</rdfs:label>
  <rdfs:comment>defined in ISO 1000:1992</rdfs:comment>
</owl:FunctionalProperty>

Measurements

For any measurement three pieces of information have to be given:

• the value, in our examples 750 and 4.5
• the unit (see above)
• and the physical quantity

It is important to understand that more than one physical quantity can refer to the same unit. Examples are e.g. frequency and rotation speed which are both given as [1/s]. ISO 31 defines many physical quantities, however p41 of STEP has explicit support for only those 21 basic quantities which are mentioned in ISO 1000. For all the other physical quantities the STEP property mechanism has to be used (see below).

For the AIM express below we focus on length and mass quantities only and how to represent values of them:

TYPE mass_measure = REAL; END_TYPE; 
TYPE length_measure = REAL; END_TYPE; 
...
TYPE measure_value = SELECT (
  amount_of_substance_measure,
  area_measure,
  celsius_temperature_measure,
  context_dependent_measure,
  count_measure,
  descriptive_measure,
  electric_current_measure,
  length_measure,
  luminous_intensity_measure,
  mass_measure,
  numeric_measure,
  parameter_value,
  plane_angle_measure,
  positive_length_measure,
  positive_plane_angle_measure,
  positive_ratio_measure,
  ratio_measure,
  solid_angle_measure,
  thermodynamic_temperature_measure,
  time_measure,
  volume_measure);
END_TYPE; 

ENTITY measure_with_unit
  SUPERTYPE OF (ONEOF (length_measure_with_unit, mass_measure_with_unit, 
    time_measure_with_unit, electric_current_measure_with_unit, 
    thermodynamic_temperature_measure_with_unit, celsius_temperature_measure_with_unit, 
    amount_of_substance_measure_with_unit, luminous_intensity_measure_with_unit, 
    plane_angle_measure_with_unit, solid_angle_measure_with_unit, area_measure_with_unit, 
    volume_measure_with_unit, ratio_measure_with_unit));
  value_component : measure_value;
  unit_component : unit;
WHERE
  WR1: valid_units (SELF);
END_ENTITY;

ENTITY length_measure_with_unit
   SUBTYPE OF (measure_with_unit);
WHERE
  WR1: 'MEASURE_SCHEMA.LENGTH_UNIT' IN TYPEOF (SELF\measure_with_unit.unit_component);
END_ENTITY;

ENTITY mass_measure_with_unit
  SUBTYPE OF (measure_with_unit);
WHERE
  WR1: 'MEASURE_SCHEMA.MASS_UNIT' IN TYPEOF (SELF\measure_with_unit.unit_component);
END_ENTITY;

STEP to OWL mapping: In the ISO 31 a generic class for physical quantities is defined:

 <owl:Class rdf:ID="Physical_quantity_type">
  <rdfs:subClassOf rdf:resource="&owl;Class"/>
 </owl:Class>

Each particular physical quantity of ISO 31 becomes now an individual of the Physical_quantity_type class.

<Physical_quantity_type rdf:about="#Length"/>
<Physical_quantity_type rdf:about="#Mass"/>

For the representation of quantity values we use members of class Real:

 <owl:Class rdf:about="#Real"/>

Representation entities

ENTITY representation;
  name : label;
  items : SET [1:?] OF representation_item;
  context_of_items : representation_context;
  ...
END_ENTITY; 

ENTITY representation_context;
  context_identifier : identifier;
  context_type : text;
INVERSE
  representations_in_context : SET [1:?] OF representation FOR context_of_items;
END_ENTITY; 
 
ENTITY representation_item;
  name : label;
WHERE
  WR1: SIZEOF(using_representations(SELF)) > 0;
END_ENTITY; 

ENTITY measure_representation_item
 SUBTYPE OF (representation_item, measure_with_unit);
END_ENTITY;

ARM to OWL mapping: For simple property values the representation and representation_context carry no additional semantic values. Because of this these entities don't show up in OWL at all. We only chose the instance identifier of the representation for reference, see below.

Independent and assigned properties

ARM-Express:

ENTITY Assigned_property;
  id : OPTIONAL STRING;
  name : STRING;
  description : OPTIONAL STRING;
  described_element : property_assignment_select; -- leads to Product_view_definition and others
END_ENTITY;

ENTITY Applied_independent_property -- maps to property_definition
  SUBTYPE OF (Assigned_property);
  base_independent_property : Independent_property;
DERIVE
  SELF\Assigned_property.name : STRING := base_independent_property.property_type;
END_ENTITY;

ENTITY Independent_property;
  id : STRING;
  property_type : STRING;
  description : OPTIONAL STRING;
END_ENTITY;

ENTITY Property_definition_representation;
  ABSTRACT SUPERTYPE;
  description : OPTIONAL STRING;
  definition : represented_definition;
  rep : Representation;
  role : OPTIONAL STRING;
END_ENTITY;

ENTITY Property_representation
  SUBTYPE OF (Property_definition_representation);
  SELF\Property_definition_representation.definition RENAMED property : Assigned_property;
END_ENTITY;

Corresponding AIM-Express:

ENTITY general_property;
  id : identifier;
  name : label;
  description : OPTIONAL text;
END_ENTITY;

TYPE derived_property_select = SELECT (
  action_property,
  property_definition, -- we consider here only this one
  resource_property);
END_TYPE;
 
ENTITY general_property_association;
  name : label;
  description : OPTIONAL text;
  base_definition : general_property;
  derived_definition : derived_property_select;
WHERE
  WR1: SIZEOF( USEDIN( derived_definition, 'PRODUCT_PROPERTY_DEFINITION_SCHEMA.' +
                                           'GENERAL_PROPERTY_ASSOCIATION.' + 'DERIVED_DEFINITION')) = 1;
  WR2: derived_definition.name = base_definition.name;
END_ENTITY;

ENTITY property_definition;
  name : label;
  description : OPTIONAL text;
  definition : characterized_definition; -- nested select leads to product_definition and others
DERIVE
  id : identifier := get_id_value (SELF);
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'ID_ATTRIBUTE.IDENTIFIED_ITEM')) <= 1;
END_ENTITY;

ARM to OWL mapping: In STEP data sets we may find just Assigned_property for some Product_view_definition or we can find the subtype Applied_independent_property together with a referenced Independent_property. The latter one is the preferred and required one by AP214 but it is not always available. For the mapping to OWL we consider both cases as practically equivalent; this means the generated OWL statements are identical. We can do this because of Applied_independent_property enforces Assigned_property.name be identical to Independent_property.property_type.

For every Assigned_independent_property that refers to either a Part_view_definition or a Product_as_individual_view via a corresponding Assigned_independent_property an OWL ObjectProperty must be created which is of type Physical_property_of_product_as_individual.

<owl:Class rdf:about="#Physical_property_of_product_as_individual">
 <owl:equivalentClass>
  <owl:Class>
   <owl:intersectionOf rdf:parseType="Collection"/>
    <owl:Restriction>
     <owl:onProperty rdf:resource="&rdfs;domain"/>
     <owl:allValuesFrom>
      <owl:Restriction>
       <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
       <owl:hasValue rdf:resource="&step;Product_as_individual"/>
      </owl:Restriction>
     </owl:allValuesFrom>
    </owl:Restriction>
    <owl:Restriction>
     <owl:onProperty rdf:resource="&rdfs;range"/>
     <owl:allValuesFrom rdf:resource="&iso31;Physical_quantity_type"/>
    </owl:Restriction>
   </owl:intersectionOf>
  </owl:Class>
 </owl:equivalentClass>
</owl:Class> 

Example:

#314=PRODUCT_DEFINITION('2',$,#311,#303);

#510=GENERAL_PROPERTY('Overall length','Total length',$);
#511=GENERAL_PROPERTY_ASSOCIATION(' ',$,#510,#512);
#512=PROPERTY_DEFINITION('Overall length',$,#314);
#513=PROPERTY_DEFINITION_REPRESENTATION(#512,#515);
 
#520=GENERAL_PROPERTY('mass when empty','mass',$);
#521=GENERAL_PROPERTY_ASSOCIATION(' ',$,#520,#522);
#522=PROPERTY_DEFINITION('mass when empty',$,#314);
#523=PROPERTY_DEFINITION_REPRESENTATION(#522,#525);

The mapping to OWL for the Measure_representation_items together with their representations and units are sown above. Now we have to define OWL DataType properties for the STEP properties we are going to use. They correspond to the general_property instances #510 and #520 when available. In the case they are not available this has to be derived from the property_definition instances.

<owl:FunctionalProperty rdf:about="#_510">
 <rdf:type rdf:resource="#Physical_property_of_product_as_individual"/>
 <step:id rdf:datatype="&xsd;string">Overall length</step:id>
 <rdfs:range rdf:resource="&iso31;Length"/>
</owl:FunctionalProperty> 

<owl:FunctionalProperty rdf:about="#_520">
 <rdf:type rdf:resource="#Physical_property_of_product_as_individual"/>
 <step:id rdf:datatype="&xsd;string">mass when empty</step:id>
 <rdfs:range rdf:resource="&iso31;Mass"/>
</owl:FunctionalProperty> 

Next we define instance of the newly defined property types, using the identifiers of the property_definition instances #512 and #522.

<step:Property_definition rdf:about="#_512">
  <owl:equivalentClass>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#_510" />
      <owl:hasValue rdf:resource="#_516" />
    </owl:Restriction>
  </owl:equivalentClass>
</step:Property_definition>

<step:Property_definition rdf:about="#_522">
  <owl:equivalentClass>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#_520" />
      <owl:hasValue rdf:resource="#_526" />
    </owl:Restriction>
  </owl:equivalentClass>
</step:Property_definition>

And finally we have to link this with the Part_view_definition #314

<step:Part_view_definition rdf:about="#_314">
  <rdfs:subClassOf rdf:resource="#_512"/>
  <rdfs:subClassOf rdf:resource="#_522"/>
</step:Part_view_definition>

Assembly and Product_occurrence

In STEP we have two different ways to define assemblies, a simple one where one Part_view_definition goes directly into another one via a relationship entity and a more extended one where we first define an occurrence of a part and then only this occurrence is related into a higher level Part_view_definition. In the early days of STEP only the simple approach was available. It had a couple of disadvantages and so the occurrence concept was introduced for more complex cases. Having occurrence objects allow to directly relate them to other structures such as breakdowns, to re-use the occurrences for several versions of the same part or to allow different views of a part_version to share the same occurrence. This is the reason why for the STEP-OWL mapping we need to support the more complex assembly structure and fortunately it is upward compatible with the simple one.

ARM-Express: First a specific subtype of Part_view_definition has to be used to define an assembly:

ENTITY Assembly_definition
  SUBTYPE OF (Part_view_definition);
WHERE
  WR1: 'assembly' IN types_of_product(SELF\Product_view_definition.defined_version.of_product);
END_ENTITY; 

Next we need instances of Definition_based_part_occurrence:

ENTITY Product_occurrence
  ABSTRACT SUPERTYPE OF ((ONEOF (Definition_based_product_occurrence,
                                 Specification_based_product_occurrence) AND
                          ONEOF (Product_occurrence_with_quantity, Single_instance)))
  SUBTYPE OF (Product_view_definition);
INVERSE
  occurrence_contexts : SET [1:?] OF View_definition_relationship FOR related_view;
END_ENTITY;

ENTITY Definition_based_product_occurrence
  ABSTRACT SUPERTYPE
  SUBTYPE OF (Product_occurrence);
  derived_from : Product_view_definition;
WHERE
  WR1: SELF\Product_view_definition.defined_version = derived_from.defined_version;
END_ENTITY;

ENTITY Part_occurrence
  ABSTRACT SUPERTYPE
  SUBTYPE OF (Product_occurrence);
  SELF\Product_view_definition.defined_version : Part_version;
END_ENTITY; 

ENTITY Definition_based_part_occurrence
  SUBTYPE OF (Definition_based_product_occurrence, Part_occurrence);
  SELF\Definition_based_product_occurrence.derived_from : Part_view_definition;
END_ENTITY;

And finally the Definition_based_part_occurrence are related to the Assembly_definition with a Next_assembly_usage that is also an Assembled_part_association. Here the relevant sub-supertype tree:

ENTITY View_definition_relationship;
  id : OPTIONAL STRING;
  relation_type : OPTIONAL STRING;
  description : OPTIONAL STRING;
  relating_view : Product_view_definition;
  related_view : Product_view_definition;
END_ENTITY;

ENTITY View_definition_usage
  SUBTYPE OF (View_definition_relationship);
END_ENTITY; 

ENTITY Assembly_component_relationship
  ABSTRACT SUPERTYPE OF (ONEOF (Next_assembly_usage, Promissory_usage,
                                Component_upper_level_identification))
  SUBTYPE OF (View_definition_usage);
  quantity : OPTIONAL Value_with_unit;
  location_indicator : OPTIONAL STRING;
WHERE
  WR1: NOT(EXISTS(quantity)) OR ((NOT ('NUMBER' IN TYPEOF(quantity.value_component))) XOR
           (quantity.value_component > 0));
END_ENTITY;

ENTITY Next_assembly_usage
  SUBTYPE OF (Assembly_component_relationship);
END_ENTITY; 

ENTITY Part_occurrence_definition_relationship
  SUBTYPE OF (View_definition_relationship);
  SELF\View_definition_relationship.relating_view : Part_view_definition;
  SELF\View_definition_relationship.related_view : Part_occurrence;
DERIVE
  SELF\View_definition_relationship.id : STRING :=
    SELF\View_definition_relationship.related_view\Product_view_definition.id;
WHERE
  WR1: NOT (('ASSEMBLY_STRUCTURE_ARM.ASSEMBLY_COMPONENT_RELATIONSHIP' IN
            TYPEOF(SELF)) AND (EXISTS(SELF\Assembly_component_relationship.quantity)));
END_ENTITY; 

ENTITY Assembled_part_association
  SUBTYPE OF (Part_occurrence_definition_relationship, Assembly_component_relationship);
  SELF\View_definition_relationship.relating_view : Assembly_definition;
END_ENTITY;

MIM/IR-Express:

ENTITY product_definition_relationship;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  relating_product_definition : product_definition;
  related_product_definition : product_definition;
END_ENTITY;

ENTITY product_definition_usage
  SUPERTYPE OF (ONEOF (make_from_usage_option, assembly_component_usage))
  SUBTYPE OF (product_definition_relationship);
UNIQUE
  UR1 : id, relating_product_definition, related_product_definition;
WHERE
  WR1: acyclic_product_definition_relationship(SELF, 
      [SELF\product_definition_relationship.related_product_definition],
        'PRODUCT_STRUCTURE_SCHEMA.PRODUCT_DEFINITION_USAGE');
END_ENTITY;

ENTITY assembly_component_usage
  SUPERTYPE OF (ONEOF (next_assembly_usage_occurrence, specified_higher_usage_occurrence,
                       promissory_usage_occurrence))
  SUBTYPE OF (product_definition_usage);
  reference_designator : OPTIONAL identifier;
END_ENTITY;

ENTITY next_assembly_usage_occurrence
  SUBTYPE OF (assembly_component_usage);
END_ENTITY; 

ARM-MIM mapping: For the purpose of the technical evaluation we restrict assembly structures for the so called S3 mapping as defined in AP214 and omit the more complex and powerful S7 mapping. In this case the mapping simplifies to:

The complex of Assembly_definition and Next_assembly_usage and also the Definition_based_part_occurrence maps to a single next_assembly_usage_occurrence.

Mapping of Assembly_definition:

product_definition <- product_definition_context_association.definition 
product_definition_context_association 
{product_definition_context_association.role -> product_definition_context_role 
product_definition_context_role.name = 'part definition type'} 
product_definition_context_association.frame_of_reference -> product_definition_context 
product_definition_context <= application_context_element 
application_context_element.name = 'assembly definition' 

ARM-OWL mapping: The ARM entity Assembly_definition maps to a corresponding OWL class Assembly_definition:

<Class_of_class_of_physical_object rdf:ID="Assembly_definition">
  <rdfs:subClassOf rdf:resource="#Part_view_definition"/>
</Class_of_class_of_physical_object>

The ARM entity Definition_based_part_occurrence maps to an OWL class Part_occurrence with the additional restriction that members of it must have a subClassOf relationship to some part_version individual.

<Class_of_class_of_physical_object rdf:ID="Part_occurence">
  <rdfs:subClassOf rdf:resource="#Class_of_physical_object"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
      <owl:allValuesFrom rdf:resource="#Part_version"/>
    </owl:Restriction>
  </rdfs:subClassOf> 
</Class_of_class_of_physical_object>

Example:

-- Here the Part_view_definition (ARM) #312 is turned into an Assembly_definition
#304=PRODUCT_DEFINITION_CONTEXT('assembly definition',#301,);
#305=PRODUCT_DEFINITION_CONTEXT_ROLE('part definition type',$);
#311=PRODUCT_DEFINITION_FORMATION('1',$,#310);
#312=PRODUCT_DEFINITION('1',$,#311,#303);
#313=PRODUCT_DEFINITION_CONTEXT_ASSOCIATION(#312,#304,#305); 
...
-- and now #322 is brought into #312 as a component of the assembly by #400
#321=PRODUCT_DEFINITION_FORMATION('1',$,#320);
#322=PRODUCT_DEFINITION('1',$,#321,#303);
#400=NEXT_ASSEMBLY_USAGE_OCCURRENCE('SI0001',,$,#312,#322,$);

<step:Part_occurence rdf:about="#_400">
  <rdfs:subClassOf rdf:resource="#_321"/>
  <step:id rdf:datatype="&xsd;string">SI0001</step:id>
</step:Part_occurence>

<step:Next_assembly_usage_occurrence rdf:about="#_400x">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&step;nextAssemblyUsageOccurrenceDefinition" />
      <owl:hasValue rdf:resource="#_400" />
    </owl:Restriction>
  </rdfs:subClassOf>
</step:Next_assembly_usage_occurrence>

<step:Part_view_definition rdf:about="_312">
  <rdfs:subClassOf rdf:resource="#_400x"/>
</step:Part_view_definition>

Alternatively to avoid #_400x we better write:

<step:Part_occurence rdf:about="#_400">
  <rdfs:subClassOf rdf:resource="#_321"/>
  <step:id rdf:datatype="&xsd;string">SI0001</step:id>
</step:Part_occurence>

<step:Part_view_definition rdf:about="_312">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&step;nextAssemblyUsageOccurrenceDefinition" />
      <owl:hasValue rdf:resource="#_400" />
    </owl:Restriction>
  </rdfs:subClassOf>
</step:Part_view_definition>

Physically realized product

ARM-Express:

ENTITY Product_as_individual
  SUBTYPE OF (Product);
END_ENTITY; 

ENTITY Product_as_individual_version
  ABSTRACT SUPERTYPE OF (ONEOF (Product_as_planned, Product_as_realized))
  SUBTYPE OF (Product_version);
  SELF\Product_version.of_product : Product_as_individual;
END_ENTITY;

ENTITY Product_as_planned
  SUBTYPE OF (Product_as_individual_version);
END_ENTITY;

ENTITY Product_as_realized
  SUBTYPE OF (Product_as_individual_version);
END_ENTITY;

ENTITY Product_as_individual_view
  SUBTYPE OF (Product_view_definition);
  SELF\Product_view_definition.defined_version : Product_as_individual_version;
END_ENTITY; 

ENTITY Product_as_individual_view_realization;
  product_design : Part_view_definition;
  individual_product : Product_as_individual_view;
END_ENTITY;

ENTITY Physical_assembly_relationship;
  SUBTYPE OF (ASSEMBLY_component_relationship);
  ELF\View_definition_relationship.relating_view : Product_as_individual_view;
  ELF\View_definition_relationship.related_view : Product_as_individual_view;
END_ENTITY;

MIM/IR-Express: On the MIM/IR level we use the same entities as we used for Part and Part_version.

ARM-MIM mapping: The mapping of product_as_individual:

product_as_individual
product_as_individual <= product
{product <- product_related_product_category.products[i]
product_related_product_category <= product_category 
product_category.name='physically realized product'}

ARM-OWL mapping:

• Product_as_individual maps to an OWL individual of type Product_as_individual.
• Product_as_realized maps to an OWL individual of type Product_as_realized.
  • The relation Product_as_realized.of_product -> Product_as_individual maps to an OWl ObjectProperty temporal_part.
• Product_as_individual_view is not individually represented in OWL.
• Product_as_individual_view_realization maps to an OWL rdf:type statement. Instead of the Product_as_individual_view the referenced Product_as_realized is to be used.
• Physical_assembly_relationship maps to an OWl ObjectProperty physical_assembly_relationship.

 <Class_of_physical_object rdf:ID="Product_as_individual">
   <rdfs:subClassOf rdf:resource="#Physical_object"/>
 </Class_of_physical_object>

 <Class_of_physical_object rdf:ID="Product_as_individual_version">
   <rdfs:subClassOf rdf:resource="#Product_as_individual"/>
   <owl:unionOf rdf:parseType="Collection">
     <owl:Class rdf:about="#Product_as_planned" />
     <owl:Class rdf:about="#Product_as_realized" />
   </owl:unionOf>
 </Class_of_physical_object>
  
 <Class_of_physical_object rdf:ID="Product_as_planned">
   <rdfs:subClassOf rdf:resource="#Product_as_individual"/>
 </Class_of_physical_object>
 
 <Class_of_physical_object rdf:ID="Product_as_realized">
   <rdfs:subClassOf rdf:resource="#Product_as_individual"/>
   <owl:disjointWith rdf:resource="#Product_as_planned"/>
 </Class_of_physical_object>

Example:

/* Here the original state of my car as it was delivered with the original engine */
#710=PRODUCT('ABX123456789','my car',$,(#302));
#711=PRODUCT_DEFINITION_FORMATION('as-delivered',$,#710);
#712=PRODUCT_DEFINITION('1',$,#711,#701);
#713=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#312,#712);
#714=ASSEMBLY_COMPONENT_USAGE(' ','physical occurrence usage',$,#712,#782);
#715=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP(' ',$,#402,#714);

/* The state after my car got a new engine. Now it no longer fits with the original state */
#721=PRODUCT_DEFINITION_FORMATION('after engine replacement',$,#710);
#722=PRODUCT_DEFINITION('1',$,#721,#701);
#724=ASSEMBLY_COMPONENT_USAGE(' ','physical occurrence usage',$,#722,#792);
#725=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP(' ',$,#402,#724);

#780=PRODUCT('STU4567890123',' ',$,(#302));
#781=PRODUCT_DEFINITION_FORMATION('1',$,#780);
#782=PRODUCT_DEFINITION('1',$,#781,#701);
#783=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#322,#782);

#790=PRODUCT('XYZ987654321 ',' ',$,(#302));
#791=PRODUCT_DEFINITION_FORMATION('1',$,#790);
#792=PRODUCT_DEFINITION('1',$,#791,#701);
#793=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#324,#792);

<step:Product_as_individual rdf:about="#_710">
  <step:id rdf:datatype="&xsd;string">ABX123456789</step:id>
</step:Product_as_individual>
<step:Product_as_realized rdf:about="#_711">
  <step:temporal_part rdf:about="#_710"/>
  <step:id rdf:datatype="&xsd;string">as-delivered</step:id>
  <step:physical_assembly_relationship rdf:about="#_781"/>
  <rdf:type rdf:about="#_312"/>
</step:Product_as_realized>
<step:Product_as_realized rdf:about="#_721">
  <step:temporal_part rdf:about="#_710"/>
  <step:id rdf:datatype="&xsd;string">after engine replacement</step:id>
  <step:physical_assembly_relationship rdf:about="#_791"/>
</step:Product_as_realized>

<step:Product_as_individual rdf:about="#_780">
  <step:id rdf:datatype="&xsd;string">STU4567890123</step:id>
</step:Product_as_individual>
<step:Product_as_realized rdf:about="#_781">
  <step:temporal_part rdf:about="#_780"/>
  <step:id rdf:datatype="&xsd;string">1</step:id>
  <rdf:type rdf:about="#_322"/>
</step:Product_as_realized>
 
<step:Product_as_individual rdf:about="#_790">
  <step:id rdf:datatype="&xsd;string">XYZ987654321</step:id>
</step:Product_as_individual>
<step:Product_as_realized rdf:about="#_791">
  <step:temporal_part rdf:about="#_790"/>
  <step:id rdf:datatype="&xsd;string">1</step:id>
  <rdf:type rdf:about="#_342"/>
</step:Product_as_realized>

Properties for Physically Realized Products

The STEP data model to be used here is identical to the one introduced above in clause Independent and assigned properties. Also the mapping to OWL is quite similar with the exception that Product_as_individual_view is not visible in OWL and product_as_realized is becoming a direct individual of the generated property class. So no restriction class for Assigned_property is needed.

Example:

/* Property "mass when empty" */
#821=GENERAL_PROPERTY_ASSOCIATION(' ',$,#520,#822);
#822=PROPERTY_DEFINITION('mass when empty',$,#722);
#823=PROPERTY_DEFINITION_REPRESENTATION(#822,#825);
#824=REPRESENTATION_CONTEXT(' ',' ');
#825=REPRESENTATION(' ',(#826),#824);
#826=(MASS_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()
      MEASURE_WITH_UNIT(MASS_MEASURE(868),#501)REPRESENTATION_ITEM(' '));

<iso_31:Mass rdf:about="#_826">
  <iso_1000:kilogram_scale>
    <iso:Real>
      <value rdf:datatype="&xsd;double">868</value>
    </iso:Real>
  </iso_1000:kilogram_scale>
</iso_31:Mass>
<rdf:Thing rdf:about="#_721">
  <_520 rdf:resource="#_826"/>
</step:Part_view_definition>

Person & Organization

In this are the ARM and MIM/IR is almost identical with a 1:1 mapping. Because of this we address the MIM/IR level here only. MIM/IR Express:

ENTITY person;
  id : identifier;
  last_name : OPTIONAL label;
  first_name : OPTIONAL label;
  middle_names : OPTIONAL LIST [1:?] OF label;
  prefix_titles : OPTIONAL LIST [1:?] OF label;
  suffix_titles : OPTIONAL LIST [1:?] OF label;
WHERE
  WR1: EXISTS(last_name) OR EXISTS(first_name);
END_ENTITY;

ENTITY organization;
  id : OPTIONAL identifier;
  name : label;
  description : OPTIONAL text;
END_ENTITY;

ENTITY person_and_organization_role;
  name : label;
DERIVE
  description : text := get_description_value (SELF);
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'DESCRIPTION_ATTRIBUTE.DESCRIBED_ITEM')) <= 1;
END_ENTITY;

ENTITY person_and_organization;
  the_person : person;
  the_organization : organization;
DERIVE
  name : label := get_name_value (SELF);
  description : text := get_description_value(SELF);
WHERE
  WR1: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'NAME_ATTRIBUTE.NAMED_ITEM')) <= 1;
  WR2: SIZEOF (USEDIN (SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'DESCRIPTION_ATTRIBUTE.DESCRIBED_ITEM')) <= 1;
END_ENTITY; 

ENTITY person_and_organization_assignment;
  ABSTRACT SUPERTYPE;
  assigned_person_and_organization : person_and_organization;
  role : person_and_organization_role;
END_ENTITY;

ENTITY applied_person_and_organization_assignment
  SUBTYPE OF (person_and_organization_assignment);
  items : SET [1:?] OF person_and_organization_item;
END_ENTITY;

TYPE person_and_organization_item = EXTENSIBLE SELECT (
  -- in some extensions we find
  product,
  product_definition_formation);
END_TYPE;

AIM-OWL mapping: Both, Person and Organization are considered as sub-classes of physical objects.

<Class_of_physical_object rdf:ID="Person">
  <rdfs:subClassOf rdf:resource="#Physical_object"/>
</Class_of_physical_object>
<Class_of_physical_object rdf:ID="Organization">
  <rdfs:subClassOf rdf:resource="#Physical_object"/>
</Class_of_physical_object>

<owl:DatatypeProperty rdf:ID="last_name">
  <rdfs:subPropertyOf rdf:resource="#label"/>
  <rdfs:domain rdf:resource="#Person"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="first_name">
  <rdfs:subPropertyOf rdf:resource="#label"/>
  <rdfs:domain rdf:resource="#Person"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="middle_name">
  <rdfs:subPropertyOf rdf:resource="#label"/>
  <rdfs:domain rdf:resource="#Person"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="prefix_title">
  <rdfs:subPropertyOf rdf:resource="#label"/>
  <rdfs:domain rdf:resource="#Person"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="suffix_title">
  <rdfs:subPropertyOf rdf:resource="#label"/>
  <rdfs:domain rdf:resource="#Person"/>
</owl:DatatypeProperty>

Entity Person_and_organization is mapped one-to-one:

<Class_of_physical_object rdf:ID="Person_and_organization">
  <rdfs:subClassOf rdf:resource="#Physical_object"/>
</Class_of_physical_object>
<owl:ObjectProperty rdf:ID="the_person">
  <rdfs:domain rdf:resource="#Person_and_organization"/>
  <rdfs:range rdf:resource="#Person"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="the_organization">
  <rdfs:domain rdf:resource="#Person_and_organization"/>
  <rdfs:range rdf:resource="#Organization"/>
</owl:ObjectProperty>

Entity Applied_person_and_organization_assignment in the role of id_owner is mapped into a ObjectProperty step:id_owner_assignment:

<owl:ObjectProperty rdf:ID="id_owner_assignment">
  <rdfs:range rdf:resource="#Person_and_organization"/>
</owl:ObjectProperty>

Example:

#100=ORGANIZATION('VW','Volkswagen','company');
#101=PERSON('A0001','Doe','John',(),(),());
#102=PERSON_AND_ORGANIZATION(#101,#100);
#103=NAME_ATTRIBUTE('technical director',#102);
#104=APPLIED_ORGANIZATION_ASSIGNMENT(#100,#105,(#310,#320));
#105=ORGANIZATION_ROLE('id owner');

<step:Organization rdf:about="#_100"> 
  <step:id rdf:datatype="&xsd;string">A0001</step:id>
  <step:name rdf:datatype="&xsd;string">Volkswagen</step:name>
  <step:description rdf:datatype="&xsd;string">Volkswagen</step:name>
</step:Organization>
<step:Person rdf:about="#_101">
  <step:id rdf:datatype="&xsd;string">A0001</step:id>
  <step:last_name rdf:datatype="&xsd;string">Doe</step:last_name>
  <step:first_name rdf:datatype="&xsd;string">John</step:first_name>
</step:Person>
<step:Person_and_organization rdf:about="#_102"> 
  <step:the_organization rdf:resource="#_100"/> 
  <step:the_person rdf:resource="#_101"/> 
</step:Person_and_organization>
<step:Part rdf:about="#_310"> 
  <step:id_owner_assignment rdf:resource="#_102"/>
</step:Part>
<step:Part rdf:about="#_320"> 
  <step:id_owner_assignment rdf:resource="#_102"/>
</step:Part>