In Part 8 subclause 7.2 we find:
7.2 Template model
A template instance is member of a specialized template, by the rdf:type relationship
A specialized template is a subclass of a specialized template or a core template, by the rdfs:subclassOf relationship.
A core template is a subclass of a template class, by the rdfs:subclassOf relationship.
A template class is a subclass of the Multidimensional Object class, by the rdfs:subclassOf relationship.
A template class is a subclass of the Information Representation class, by the rdfs:subclassOf relationship.
The Multidimensional Object class is of entity data type class of multidimensional object.
How it all fits together is shown in a series of examples (see Annex H).(which is only very partly true)
Careful examination of the above, of Annex H, and of the tm listing leads to the conclusion that there is room for improvement. This paper describes a proposal for that.
A known problem is an incompatibility between Part 2 and OWL with respect to the OWL representation of the Part 2 rule-ridden construct of ClassOfMultidimensionalObject plus its member MultidimensionalObject.
For this incompatibility a workaround has been created in Part 8. The proposal hereunder gives an OWL-compliant solution.
In steps the path from the 'roles' + dm:RoleAndDomain of ClassOfMultidimensionalObject and 'elements' + dm:Thing to a template signature is being detailed below.
As an example, ClassOfInvolvementByReferenceDefinition, is detailed below.
A picture says more that a thousand words.
Note that some names used in Part 8 have been adapted in order to be in line with the Part 8 naming conventions for Part 2 entity types:
- p7tm:Template is now tm:ClassOfTemplate;
- p7tm:TemplateStatement is now tm:Template.
The RDF code for a generic instance of this template is as follows:
:UUID_CL-ACTIV-300 rdf:type tpl:ClassOfInvolvementByReferenceDefinition ; tpl:hasActivityType "ID"^^dm:ClassOfActivity ; tpl:hasInvolvedType "ID"^^dm:Class ; tpl:hasInvolvementRole "ID"^^dm:Role ; tpl:hasDefined "ID"^^dm:ClassOfInvolvementByReference ; # auto-generated tpl:hasCardinalityOfActivity "ID"^^dm:Cardinality ; tpl:hasCardinalityOfInvolved "ID"^^dm:Cardinality ; meta:valEffectiveDate "yyyy-mm-ddThh:mm:ss.sZ"^^xsd:dateTime .where, typically, "ID"^^dm:ClassOfActivity stands for 'the ID of an instance of dm:ClassOfActivity".
EXAMPLE - API standard 1104 is involved by reference in xyz-company defined activity class 'Welding to API 1104' in the role of 'APPLICABLE STANDARD'.
ex:494ce008-7d3f-4cf5-89b7-7591e200d214 rdf:type tpl:ClassOfInvolvementByReferenceDefinition ; tpl:hasActivityType xyz:R475854 ; # Welding to API 1104 tpl:hasInvolvedType api:RDS2229952 ; # API 1104 tpl:hasInvolvementRole rdl:RDS2229953 ; # APPLICABLE STANDARD tpl:hasDefined ex:193d07f9-21ec-442e-9f11-5b9ffdfdd66b ; # auto-generated, can be used to classify an instance of InvolvementByReference tpl:hasCardinalityOfActivity rdl:RDS222625 ; # ONE TO ONE tpl:hasCardinalityOfInvolved rdl:RDS222625 ; # ONE TO ONE meta:valEffectiveDate "2021-07-17T16:34:00Z"^^xsd:dateTime .telling that welding on projects of the xyz company shall be done according API 1104. An actual welding Activity can be classified with xyz:R475854, as defined in their RDL extension.