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 relationship between two or more objects that are known by the recipient of that information representation.
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.
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 vesel and a pressure transmitter, interconnected by means of tubing).
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:
When we use that template for our example we get:
Before we can use Pipe A, Pump B, and "Flanged Connection" we must declare them (once), thereby using the entity types defined in ISO 15926-2:
The template instance then is correctly completed as follows:
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), except for the "Literals" (text strings, dateTimes, etc).
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:
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 "Pump B IMP".
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 placing the represented information in a period in time, between the valEffectiveDate and the valDeprecationDate., thus filling your Archive with integrated lifecycle information.
More in-depth explanation
A template represents a complex n-ary relationship between independent objects. There are four types of template:
Basically these are representing all ISO 15926-2 entity data types that have one or more attributes. These are listed in ISO 15926-7 Annex D. A typical example of a proto-template is the one for CompositionOfIndividual:
This means that the first role of the template is "hasPart" and instances of the first role must be instances of the entity type PossibleIndividual. The second role is "hasWhole" and instances of this role must also be instances of the entity type PossibleIndividual.
In the template language this is represented by:
CompositionOfIndividualTemplate(y, z) <-> exists u(CompositionOfIndividualTriple(u, y, z))
CompositionOfIndividualTriple(x, y, z) <-> CompositionOfIndividual(x) & hasPart(x, y) & hasWhole(x, z)
For the full ontology click here.
Orthogonally to the above two types of template are Lifted and Lowered 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. An instance of a lifted template can be used for:
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 template graph.
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:
Graph of Lifted Template
Graph of Lowered Template
For the above (lowered) template ClassOfParticipationDefinition the signature is:
Template signature of ClassOfParticipationDefinition
As we have seen above a template is defined as follows:
"A template is a set comprising of a first-order logic predicates for which a definition is stated as an axiom, a template signature and a template axiom expansion.".
The (reduced) set of symbols used in the template language are:
The definition of an axiom is: "An axiom is a self-consistent statement about the primitive terms that form the basis for discourse. A first-order theory consists of a set of axioms in a particular first-order signature. The set of axioms is often finite."
Below is the axiom for above template ClassOfParticipationDefinition:
ClassOfParticipationDefinition(x1, x2, x3, x4, x5, x6) <-> ClassOfActivity(x1) & ClassOfIndividual(x2) & Role(x3) & Cardinality(x5) & Cardinality(x6) & exists u1 exists u2 exists u3( ClassOfActivity(u1) & ClassOfTemporalWholePartTemplate(u1, x1) & ClassOfIndividual(u2) & ClassOfTemporalWholePartTemplate(u2, x2) & ParticipatingRoleAndDomain(u3) & SpecializationByDomainTemplate(u3, u2) & SpecializationByRoleTemplate(u3, x3) & ClassOfParticipationTriple(x4, u3, u1) & end1Cardinality(x4, x6) & end2Cardinality(x4, x5)) .
Representation and Storage in triple format
The representation of the above mentioned template ClassOfParticipationDefinition in triple format is shown below:
Example of storage of an instance of ClassOfParticipationDefinition in triple format
In this format all information is stored in an ISO 15926-9 (work in progress) compliant "triple store" called "Fašade".
The in-depth explanation can only be found in the official ISO standards: