IntroductionIn this topic the role of templates as ontologies is discussed.
Definitions of OntologyThe following two definitions seem applicable here:
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]
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
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.
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.
ISO 15926-7 templates are about ISO 15926-2 Classes and, others, about PossibleIndividual's, where the latters 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 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:
and of the signature of its " lowered" template:IndividualHasPropertyWithValue(x1, x2, x3, x4) <->
An instance of this template could have the following semantics, as indicated in above graph: "V-101 has a Mass of 30.57 metric tons". This requires the following instances of the template type and its Role Object Types:
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 of 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.
ImplementationTemplates, with their signatures, are still cryptic for most users. To alleviate this Specialized Templates, called TIPs (Template of Information Pattern), have been designed. In these TIPs one or more Role Object Types are being instantiated pre-emptively, in certain cases by means of a selection from a pick-list of applicable/allowable class instances.
A TIP signature is being populated with label values because those are recognized by the users, and the mapping software sees to it that in cases where the labeled object has already been declared a duplication is avoided. If not declared, the software allows for automatic declaration or user-controlled declaration (the latter is safer).
A TIP version of above template could be:
Note that further specialization is possible, such as:
TIP software works with TIP signatures where the Role Object Types are instantiated with their label.
The signature for an tip:IND-has-Mass-in-metric-ton is:
where, for the template instance this topic started with, the values are:
which is understandable for an engineer.
The mapping from data elements to ISO 15926-8 template instances can, for the most, be done with an ETL (Extract, Transform and Load) tool, resulting in an instance of the base template:
Using the base template for the end result is done because the TIP information is dependent on the TIP software, but there are other ways to instantiate a template and using the base template for the end result guarantees a code that can be understood globally.
After conversion to N triples, this code is uploaded to the applicable triple store of (in this example) the XYZ Corp.Project P1234 as:
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.
Read further about the concept of that adapter here.