STEP Ontologies
Overview #
When talking about STEP data models we have to make clear on which particular level of data model we are talking about. There are:
- the Integrated Model (IM) based on the STEP Integrated Resources (IR: 40, 100 and 500 series) and the Application Integrated Model (AIM: 200) respectively the Modular Integrated Model (MIM: 400 and 1000 series). This model is used for data exchange in a STEP p21 file.
- The Application Reference Model (ARM: 200, 400 and 1000 series) that is not intended to be directly implemented (but had been in a few cases)
- The Core Model (part 4000) whose purpose is to better facilitate the mapping between the Domain Model and the ARM
- The Domain Model ( 4000 series except part 4000 itself) in SysML that is used for STEP XML data exchange.
All these model cover the same application area and are in fact similar; but because of different terminology and different levels of details mappings are needed. The following mappings are defined:
- from Domain Model to the Core Model
- from Core Model to the ARM
- from the ARM to the AIM/MIM
The STEP architecture indicated above is very different to the one used in SST. All SST Ontologies define together a single level integrated implementation data model that is directly used for data exchange such as Turtle, TriG, Json-LD and also within the SST Repositories.
For converting STEP data to SST the following ontologies defined earlier are used:
ssmeta:this defined directives for the generic convertion between STEP data and SST datalci:that contains generic concepts such as lci:Organization and lci:Personqau:that defines Quantities and Units replacing the STEP 10303-41 definitions of the measure_schema
The specific STEP ontologies are:
rep:based on the ISO 10303-43 Representation structures and all the extension of this for e.g. geometry, topology, kinematics, presentation and many more. The rep ontology is strictly derived from the Express models of the corresponding IM/IR parts.sso:for all other STEP definitions that are not covered by the rep ontology; this includes all Product Data Management (PDM), configuration control, assembly, breakdown and many more areas. The sso ontology is primarily based on the Domain Model, but also covers several MIM constructs as well.
General Concepts #
Simple Express entity that maps to an owl:Class
#
A typical Express entity, resp. SysML class maps to a corresponding OWL class, that is a specializations of one of the lci classes. Explcit entity attributes in STEP maps to OWL properties. Derived, redeclared-as-derived and inverse attributes are not mapped.
Example:
ENTITY cartesian_point
SUPERTYPE OF (ONEOF (cylindrical_point, polar_point, spherical_point))
SUBTYPE OF (point);
coordinates : LIST[1:3] OF length_measure;
END_ENTITY;The usage within a STEP p21 file looks like this
#1234=CARTESIAN_POINT('',(-65.3628370504986,-69.,-41.6407196468788));Entity cartesian_point maps to a corresponding owl:Class rep:CartesianPoint and the entity attribute coordinates to a corresponding owl property rep:coordinates. While the entity attribute coordinates is dependent on the enclosing entity cartesian_point (so a second class citensence) the corresponding owl property rep:coordinates ist defined independently and thus could be extended for a more general purpose (by extending the rdfs:domain)
rep:CartesianPoint
ssmeta:stepImEntityMap "cartesian_point" ;
a owl:Class , ssmeta:MainClass ;
rdfs:subClassOf rep:Point ;
ssmeta:stepImMapAttributeOrder ( :coordinates ) .
sh:closed true ;
sh:ignoredProperties (rdf:type) ;
sh:property [
sh:path :coordinates ;
sh:name "CartesianPoint.coordinates" ;
sh:minCount 1 ;
sh:maxCount 1 ] .
rep:coordinates
ssmeta:stepImAttributeMap "cartesian_point.coordinates" ;
a owl:ObjectProperty , owl:FunctionalProperty ;
rdfs:domain :CartesianPoint ;
rdfs:range :ListOfDouble . This is used within a Turtle file like this:
:uuid99 a rep:CartesianPoint ;
rep:coordinates ( -65.3628370504986 -69.0 -41.6407196468788 ) .Simple Express entity that maps to an owl property #
In STEP we can find many entities that are named xxx_relationship or xxx_assignment.
These entities have no semantic by themselves - they are just syntax - and are therefor