Redefinition of the Template Model

latest update 2022-10-22 

Introduction

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.

Diagram

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:

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.