Templates - an introduction

latest update 2022-10-21


In ISO 15926-7 and -8 the concept of template has been defined. This paper gives an introduction in that concept.

We start with a "shallow" explanation and then a bit more in-depth. For a thorough explanation reading of ISO 15926-7 and of ISO 15926-8 is highly recommended. In this topic we may not violate the copyright owned by ISO. But we may discuss template matters nevertheless.

Some basic wisdom

Information is a set of relationships between two or more objects that are known by, or made known to, the recipient .

For example, when you hear that John Doe and Mary Bloggs are married, that is non-information unless you know these people.

So, in computer terms, we must "declare" the objects before we can represent any information about them. See here.

Shallow explanation

Assume that you want to represent the information that Pipe A is connected to Pump B. In the ISO 15926-2 data model we find a Relationship called ConnectionOfIndividual with two attributes called side1 and side2 :

Now we want to represent the fact that this connection is a Flanged Connection, so we classify the Relationship with a ClassOfRelationship:

This is still a simple little model, with five things, that we can use for all connections. There are two flavors: direct connection, as above, and indirect connections by means of some intermediary material, such as between a nozzle on a pipe or vessel at side1 and a pressure transmitter at side2, interconnected by means of tubing, or a connection between Amsterdam Airport and LaGuardia Airport in New York by means of air lanes.

These models can be extended in all directions, so we need to "package" them in what ISO 15926-7 calls "Templates", in order to enable re-use.

We put it in a small table in which we list the three objects that are the variables and give each of them a role in the represented information:

Role No Role Name Role Object Type
1 hasSide1 dm:PossibleIndividual
2 hasSide2 dm:PossibleIndividual
3 hasConnectionType dm:ClassOfDirectConnection

When we use that template for our example we get:

Role No Role Name Role Object Type
1 hasSide1 Pipe A
2 hasSide2 Pump B
3 hasConnectionType FLANGED CONNECTION

Before we can use Pipe A, Pump B, and "Flanged Connection" we must declare them (once, and simplified here, see Declaring a Tag, a Stream, and a Commodity Product, thereby using the entity types defined in ISO 15926-2:

	rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS6809993 ;
   	rdfs:label "Pipe A" ;
   	meta:valEffectiveDate "2016-09-21T16:51:00Z"^^xsd:dateTime .

   	rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS327239 ;
   	rdfs:label "Pump B" ;
   	meta:valEffectiveDate "2016-09-21T16:51:00Z"^^xsd:dateTime .

   	rdf:type dm:ClassOfDirectConnection ;
   	rdfs:subClassOf dm:DirectConnection ;
   	rdfs:label "FLANGED CONNECTION" ;
   	meta:valEffectiveDate "2016-08-16T00:00:00Z"^^xsd:dateTime .


  1. Prefixes : dm: , rdf: , rdfs: , tpl: , and meta: (and others) are local codes for the place where the item is (to be) stored or defined; these are "unfolded" in the "N-triple" format below;
  2. InanimatePhysicalObject is a specialization of PhysicalObject, so it is used legally in this template;
  3. That "FLANGED CONNECTION" has already been declared in the RDL (Reference Data Libary);

The template instance then is correctly completed as follows:

:60436c5c-edac-481a-88fe-0eaa82c7110c rdf:type tpl:ClassifiedDirectConnectionOfTwoIndividuals ;
	tpl:hasSide1 :b7b6dd66-6574-498b-92a6-cd35fffdf914 ;  # Pipe A"
	tpl:hasSide2 :9736e6dc-e617-43d9-989c-e733b908b02f ;  # Pump B
	tpl:hasDirectConnectionType rdl:RDS2229203 ; # FLANGED CONNECTION
	tpl:hasDirectConnection :8c864936-eb03-4ebd-95b8-117e3d2346f7 ; # see Note
	meta:valEffectiveDate "2016-09-21T16:51:00Z"^^xsd:dateTime .

This can easily be converted to a format, called N-triple, that is used for storage, a "triple store" :

All< objects have a URI (http:// address), not all of them are "dereferenceable" (i.e. in case a URI is being sent an information representation is returned).

When a declared object or template is no longer valid, e.g. when Pipe A and Pump B are no longer connected (in this example on the P&ID), the template is made invalid by adding one triple:

:60436c5c-edac-481a-88fe-0eaa82c7110c meta:valDeprecationDate "2017-06-21T14:37:00+00:00"^^xsd:dateTime .

All plant and plant component lifecycle information follows the same pattern of declared objects and templates.

Using the standard query language SPARQL all information valid now or at a given date-time can be fetched via the rdfs:label or via other information.
For example, if you don't know the label of the pipe, you can ask for the objects that are connected with Pump B. For components use subtags, such as "P-101-IMP" as tag for the impeller of Pump P-101.

Each object has an ID that is part of its URI, most objects have a label, sometimes more. Your SSN (Social Security Number) is your ID, your name is your label.

Using templates allows for finding the represented information valid at a given dateTime T by fetching the required template versions of which the valEffectiveDate is the latest before dateTime T

Further explanation

Template types

A template represents a complex n-ary relationship between independent objects. There are two types of template:

Lifted Templates

Lifted templates represent information in a manner that fully complies with ISO 15926-2. Lifted templates serve as a reference for the exact semantics of the lowered templates.

Lifted templates can be instantiated by applying the First Order Logic axiom, specified in the applicable Template Specification, to the instantiated lowered template.

Below is a the FOL axiom for above template:

ClassifiedDirectConnectionOfTwoIndividuals(hasSide1, hasSide2, hasDirectConnectionType,
	hasDirectConnection) <->
PossibleIndividual(hasSide1) &
PossibleIndividual(hasSide2) &
ClassOfDirectConnection(hasDirectConnectionType) &
exists u1 exists u2 exists u3 exists u4(
      TemporalWholePartTemplate(u1,hasSide1) &
      PossibleIndividual(u1) &
      TemporalWholePartTemplate(u2, hasSide2) &
      PossibleIndividual(u2) &
      ClassificationTemplate(hasDirectConnection, hasDirectConnectionType) &
      DirectConnectionTriple(hasDirectConnection, u1, u2) &
      BeginningTemplate(u3, u1) &
      BeginningTemplate(u3, u2) &
      PointInTime(u3) &
      ClassOfIdentificationTemplate(u4, u3) &
      RepresentationOfGregorianDateAndUtcTime(u4)) .

In practice that instantiation, and subsequent OWL reasoning, proofed to be (close to) impossible due to software limitations. The day-to-day implementation of these standards is therefore based on lowered templates in RDF, SHACL, and SPARQL

Lowered Templates

Lowered templates represent information in the form of an n-ary relationship, a collector of n unary relations with independent external things. These things also form the "leafs" of the companion lifted templategraph.

NOTE - By convention we mean Lowered Template when we say Template.


If we consider the template ClassOfParticipationDefinition we can show the Lifted and the Lowered Template:

Combined graph

Graph of Lifted Template

Graph of Lowered Template

In-depth explanation

The official in-depth explanation can only be found in the official ISO standards: