Templates as ontologies

Introduction

In this topic the role of templates as ontologies is discussed.

Definitions of Ontology

The following two definitions seem applicable here:

Definition #1

In the context of computer and information sciences, an ontology defines a set of representational primitives with which to model a domain of knowledge or discourse. The representational primitives are typically classes (or sets), attributes (or properties), and relationships (or relations among class members). The definitions of the representational primitives include information about their meaning and constraints on their logically consistent application. In the context of database systems, ontology can be viewed as a level of abstraction of data models, analogous to hierarchical and relational models, but intended for modeling knowledge about individuals, their attributes, and their relationships to other individuals. Ontologies are typically specified in languages that allow abstraction away from data structures and implementation strategies; in practice, the languages of ontologies are closer in expressive power to first-order logic than languages used to model databases. [Gruber, 2007]

Definition #2

An ontology is a formal description of knowledge as a set of concepts within a domain and the relationships that hold between them. To enable such a description, we need to formally specify components such as individuals (instances of objects), classes, attributes and relations as well as restrictions, rules and axioms. As a result, ontologies do not only introduce a sharable and reusable knowledge representation but can also add new knowledge about the domain. [Ontotext USA, Web Home Page, Sept, 2019]

Application of definitions

Definition #1

The Upper Ontology of ISO 15926-2 actually defines that "set of representational primitives" used to model the domain of discourse of a template. Furthermore the language of the "lifted" templates is indeed first-order logic. The link between that abstraction of the "lifted" templates and the implementation strategy of using "lowered" templates is implemented by defining a "signature" for each lowered template in which only the variables are listed, whilst maintaining the link to that abstraction.

Definition #2

In the Template Specifications and the OWL representation of the "lowered templates" those "individuals (instances of objects), classes, attributes and relations as well as restrictions, rules and axioms" are formally specified for each template.

Instantiation

ISO 15926-7 templates are about ISO 15926-2 Classes and about PossibleIndividuals, where the former ones are metaclasses and the latter ones actually are classes that have real world individuals as members (see here for a further explanation).

An instance of a template has an instance of its signature with declared instances of the (rdf:)objects listed there. For example the template IndividualHasPropertyWithValue:

The graph, built from above "set of representational primitives", is:

This template has a FOL listing that builds on the entity types of ISO 15926-2 to define the semantics of this template/ontology:

IndividualHasPropertyWithValue(hasPropertyPossessor, hasPropertyType, valPropertyValue, hasScale) <->
PossibleIndividual(hasPropertyPossessor) &
ClassOfProperty(hasPropertyType) &
ClassOfExpressInformationRepresentation(valPropertyValue) &
Scale(hasScale) &
exists u1 exists u2 exists u3 exists u4 exists u5 exists u6(
      PossibleIndividual(u1) &
      TemporalWholePartTemplate(u1, hasPropertyPossessor) &
      Property(u2) &
      ClassificationTemplate(u1, u2 &
      ClassificationTemplate(u2, hasPropertyType) &
      PropertyQuantificationTriple(u3, u2, u4) &
      ClassificationTemplate(u3, hasScale) &
      ArithmeticNumber(u4) &
      ClassOfIdentificationTemplate(valPropertyValue, u4) &
      PointInTime(u5) &
      BeginningTemplate(u5, u1) &
      ClassOfIdentificationTemplate(u6, u5) &
      RepresentationOfGregorianDateAndUtcTime(u6)) .

and of the signature of its "lowered" template:

Implementation

The most difficult step in the implementation is the mapping, or more precisely: for one or a few particular data elements the applicable template has to be selected. See the applicable topic.

In each Template Specification a generic signature, like the following one for the template 'IndividualHasPropertyWithValue', is given:

:UUID_IN-PTYST-100
      rdf:type tpl:IndividualHasPropertyWithValue ;
      tpl:hasPropertyPossessor "ID"^^dm:PossibleIndividual ;
      tpl:hasPropertyType "ID"^^dm:ClassOfProperty ;
      tpl:valPropertyValue ""^^xsd:decimal ;
      tpl:hasScale "ID"^^dm:Scale ;
      meta:valEffectiveDate "yyyy-mm-ddThh:mm:ss.sZ"^^xsd:dateTime .

where "ID"^^dm:PossibleIndividual means: a URI identifier of a thing that is typed with 'PossibleIndividual' (or a specialization thereof) as defined in http://data.15926.org/dm/PossibleIndividual
Keep in mind that all non-Literal Role Objects shall have been declared first. In this example the instance of ClassOfProperty and of Scale must be selected from the RDL (Reference Data Library)

Assume that Vessel V-101 has a MASS of 30.57 METRIC TON. Then a SPARQL query reveals that their ID's are respectively:

:e8802675-6153-4e0e-9584-4fa2060efe05 (from the declaration code of V-101)
rdl:RDS353339 (already declared in the RDL)
rdl:RDS2229868 (already declared in the RDL)

which can be ETL-ed into above generic signature to arrive at:

ex:9c88e964-f7ac-4056-ac16-c4dc68b80212
      rdf:type tpl:IndividualHasPropertyWithValue ;
      tpl:hasPropertyPossessor ex:e8802675-6153-4e0e-9584-4fa2060efe05 ; # UUID of vessel V-101
      tpl:hasPropertyType rdl:RDS353339 ; # MASS
      tpl:valPropertyValue "30.57"^^xsd:decimal ;
      tpl:hasScale rdl:RDS2229868 ; # METRIC TON
      meta:valEffectiveDate "2022-04-25T15:38:00Z"^^xsd:dateTime .

The contents then are being validated with SHACL, to see whether these Role Objects are indeed instances of the Role Object Types of the template signature.

Note that this information can be, from a technical point of view, total nonsense. This is because the following statement in ISO 15926-2 subclause 4.1 applies:

"To enable integration of life-cycle process plant information the model excludes all information constraints that are appropriate only to particular applications within the scope."

This means that the source applications, from which data elements are being mapped to ISO 15926-7/8 templates, are assumed to deliver semantically and technically correct information.

Specialized Templates

In order to make life easier one can design specialized templates where one or more of the variables are predetermined. For example a specialization called Individual-has-mass-in-metric-ton. Needless to say that this may easily explode in far too many combinations:


tpl:IndividualHasMassInMetricTon rdfs:subClassOf tpl:IndividualHasPropertyWithValue .

:UUID
      rdf:type tpl:IndividualHasMassInMetricTon ;
      tpl:hasPropertyPossessor "ID"^^dm:PossibleIndividual ;
      tpl:hasPropertyType rdl:RDS353339 ; # MASS
      tpl:valPropertyValue ""^^xsd:decimal ;
      tpl:hasScale rdl:RDS2229868 ; # METRIC TON ;
      meta:valEffectiveDate "yyyy-mm-ddThh:mm:ss.sZ"^^xsd:dateTime .

EssentialType

That 'EssentialType' in the template label comes from the declaration code. It is the Class of which the Individual is a member or the Class is a subclass, and selected such that as long as that Individual exists or the Class is relevant that typing shall not change. Therefore in most cases an instance of ClassOfFunctionalObject, like VESSEL, is used, rather than HORIZONTAL VESSEL. During Engineering it may happen that it is deemed that a vessel shall be horizontal, but later that that must be changed to vertical. If we had declared that vessel as a horizontal that declaration, including all its attributed information, would have to be deprecated unvoluntarily. Declaring it with VESSEL avoids that.

As an aside: Given the nowadays' gender operations it is better to declare a human being as a Person and not as a MALE PERSON or FEMALE PERSON.

Storage

After conversion to N-triples, this code is uploaded to a triple store of (in this example) the Example Organization as:

Adapter

Once such a mapping has been defined for an application and coded in an adapter for that application, it will keep uploading templates following the rules for releasing and uploading as defined by the custodian of that application.