Lesson 8

The introduction in 7 lessons served to place the modeling of life-cycle information in a context. In case that context would not be kept in mind, the modeling might be syntactically correct but wouldn't make much sense for ISO 15926, because the higher target is the integration of plant life-cycle information in an ISO standard manner.

That target calls for a permanent storage of each and every state change of everything that is in that plant life-cycle information.

The reason why we started with what is now ISO 15926 was, and is, that during the entire life of a plant there are many parties that all use their own, mostly task-oriented, software. These parties produce information and require information, and the produced information will, one day, perhaps after 20 years during a revamp project, be required by some other party with software based on Windows 23 or so and a programming language that had been invented in the meantime.

So, we need a Lingua Franca in a simple format that will exist for ever (well, at least for a very long time), that is convertable whenever required, and that is web-enabled: RDF(Resource Description Framework) with its simple basic graph, the 'triple':

such as 'John isFatherOf Pete', or 'IMPELLER isPartOf CENTRIFUGAL PUMP' (or its inverse: 'CENTRIFUGAL PUMP hasAsPart IMPELLER') .

The problem is that a triple can not be the subject of another triple without additional constructs, such as "reification" or "named graphs". That hurts, because it is the predicate that defines the information. So it means that we can't define meta data for a triple, such as:

when was it created? And when deprecated?
by whom has it been created?
what is its status?
who has read access?
etc.

Using the concept of Templates, as defined in ISO 15926-7 and made implementable in ISO 15926-8, we encapsulate a small piece of information in a Template instance.
A Template is a subtype of ClassOfInformationRepresentation and of MultidimensionalObject, and as such classes that can be a subject or object to which metadata can be attributed.

A typical example of a template is the one based on the Relationship 'DirectConnection':
A DirectConnection is a ConnectionOfIndividual that indicates that the side_1 and side_2 are directly connected via a common spatial boundary.":

In the center [4] is our Relationship 'DirectConnection', that is classified with an instance of ClassOfDirectConnection that is defined in the Reference Ontology as 'FLANGED CONNECTION'.
Here come the 'temporal parts' into play. A temporal part [6] of [1] is directly connected with a temporal part [8] of [2]. Both temporal parts begin their life at PointInTime [12] that is being indicated with an instance of RepresentationOfGregorianDateAndUtcTime [14].

This graph, called a 'lifted template' in Part 8, is being encapsulated in a template called ClassifiedDirectConnectionOfTwoIndividuals: 'ClassifiedDirectConnectionOfTwoIndividuals' that has four attributes/roles viz:

hasSide1 with as object a PossibleIndividual
hasSide2 with as object a PossibleIndividual
hasConnectionType with as object a ClassOfDirectConnection
hasConnection with as object a DirectConnection relationship (this UUID is used by a template about things that are used for that connection)

that point at the variables in the lifted template.

So we simplified the representation of the information by only referring to the variables, at the same time referring to the full graph of the lifted template in order to define the semantics in Part 2 terms.

The fact that [14] isn't captured by an attribute of the lowered template has a practical reason, in that lifted templates for metaclasses don't have a RepresentationOfGregorianDateAndUtcTime, simply because instances of the metaclasses are eternal. So the class iPhone existed already after the Big Bang, it just took some time before it was discovered.

What we did was that each template gets the metadata 'valEffectiveDate' that tells when a certain class became valid/relevant in the template context ('teenager' is, as such, a valid class, but not in the context of you, I guess :) ).

Whenever instances of lifted templates would be generated by converting lower templates, the RepresentationOfGregorianDateAndUtcTime in above template would get the dateTime of the meta:valEffectiveDate.

The fact that we didn't put [14] in the template signature is that it is easier for implementers to be able to treat templates for metaclasses and for classes in the same way, in particular in queries.

Each Template is in fact an elementary ontology that can be instantiated multiple times with a different set of data. You can directly connect a gazillion of physical objects, and the semantics remain clear.

Finally this: there are proponents to do away with Relationship and ClassOfRelationship and to replace them with relations a.k.a.Predicates. But that means denormalization and a combinatorial explosion. For example: a (Part 2) Property is related to an ArithmeticNumber by an instance of PropertyQuantification, where the latter is classified with a Scale. When that classification is abandoned (because you can't type a predicate), you get predicates like "quantifiedOnAMetreScale", "quantifiedOnAnInchScale", etc, etc. DON'T!

Declarations

As said before, information is a set of relationships between things that are known, or made known, to the recipient. That is done with declarations, that looks like this for the above template:

ex:287e30bb-8031-4515-8a70-c064ee17432d
      rdf:type  lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS43167562153, rdl:RDS43166360112 ; # INLET NOZZLE , FLANGED NOZZLE
      rdfs:label "Inlet flange of pump P-101" ;       
      meta:valEffectiveDate "2019-11-04T09:27:46Z"^^xsd:dateTime .

ex:fb363d94-3472-480d-912d-90b8cd8b33f9
      rdf:type  lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS429434 ; # FLANGED PIPE END
      rdfs:label "Flange at end of line RZ17801" ;
      meta:valEffectiveDate "2020-01-23T14:38:46Z"^^xsd:dateTime .

Then we declare an instance of template ClassifiedDirectConnectionOfTwoIndividuals, referring to above declared items:

ex:73998074-4c6b-44aa-bb40-9ee3be73d0fe
      rdf:type tpl:ClassifiedDirectConnectionOfTwoIndividuals ;
      tpl:hasSide1 ex:287e30bb-8031-4515-8a70-c064ee17432d  ; # Inlet flange of pump P-101
      tpl:hasSide2 ex:fb363d94-3472-480d-912d-90b8cd8b33f9 ; # Flange at end of line RZ17801
      tpl:hasConnectionType rdl:RDS2229203 ; # FLANGED CONNECTION
      tpl:hasDirectConnection ex:93939aeb-c39c-4da9-97d8-1f5c7efa65a3 ; # auto-generated, can be used for template IndividualTypeUsedInADirectConnection
      meta:valEffectiveDate "2006-08-11T00:00:00Z"^^xsd:dateTime .

All declarations shall be made only once. Templates with a different 'signature' (set of triples) are different classes and hence must be declared.

NOTES

Prefixes like ex: rdf:, etc are converted to full https addresses when this code is converted to triples, so here:

      @prefix ex:   <http://www.example.org/> .  # the example project triple store
      @prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .  # the XML Schema Recommendation of W3C (for Literals, such as decimal, dateTime)
      @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . # the RDF Recommendation of W3C
      @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . # the RDF Schema Recommendation of W3C
      @prefix dm:   <http://data.15926.org/dm/> . # ISO 15926-2
      @prefix lci:  <http://data.15926.org/lci/> . # store for future ISO 15926-2 extensions
      @prefix meta: <http://data.15926.org/meta/> . # store for meta data
      @prefix tpl:  <http://data.15926.org/tpl/> . # store for template specifications
      @prefix rdl:  <http://data.15926.org/rdl/> . # reference data library

rdf:type lci:InanimatePhysicalObject, rdl:RDS43167562153, rdl:RDS43166360112 ; means three rdf:type triples
rdfs:label "Inlet flange of pump P-101" ; it is better to assign subtags (e.g. P-101-IN), is easier when defining queries
The starting identifier is the rdf:subject for all triples; Each triple shall end with a semicolon ';' and the last one with a dot '.' .
Part 2 has EXPRESS (modeling language) literals, in the implementation we use their XML Schema equivalents.
Each Literal shall end with "xxxx"^^xsd:nameOfTheLiteralType, e.g. "15.83"^^xsd:decimal . Strings may be just "abc123", so without ^^xsd:string (but with it is correct as well)
It is advisable to use UUIDs, it prevents double identifiers, see here for a generator and an explanation. Exceptions are identifiers in ontologies, mainly by convention.

Temporal Parts

Quite by coincidence I saw in today's newspaper this (translated): The 'you' of five years ago consists of something completely different from the 'you' of now.
That's why we have a 'temporal whole' that exists from birth to death, and, when you think of it, has remarkably little information that remains valid all that time.

Most templates have temporal parts of the involved PossibleIndividual(s), or class-of-temporal-parts of the involved Class(es). Yet the Roles of a template signature point that the temporal whole.
The actual information, however, is about those temporal parts. So what is the rationale?

First of all there are hardly, if any, computer systems that explicitly support temporal parts. Besides that the temporal wholes form the grid of the information fabric, where the temporal parts are, well ....... temporal. The idea is that, from a practical point of view, we have to use what is there in the source systems (the systems that provide the information), from a semantics point of view we precisely define the semantical contents of a template.

The point in time that information that is valid for a PossibleIndividual or ClassOfIndividual is determined by the valEffectiveDate and, eventually, valDeprecationDate.

Example 1
On 2021-06-23T15:37:00Z John Doe steps on his weighing scale and notes that his weight is 78.6 kg. This is recorded as:

ex:8fad735c-b1bb-4328-b808-4cb8b58af6bb
      rdf:type tpl:IndividualHasPropertyWithValue ;
      tpl:hasPropertyPossessor ex:JohnDoe783 ;
      tpl:hasPropertyType rdl:RDS7285420 ; @ WEIGHT
      tpl:valPropertyValue "78.6"^^xsd:decimal ;
      tpl:hasScale  rdl:RDS1328669 ; # KILOGRAM
      meta:valEffectiveDate "2021-06-23T15:37:00Z"^^xsd:dateTime .

The next day again:

ex:b0d413b2-9b93-4557-a72c-1f61536d1c9d
      rdf:type tpl:IndividualHasPropertyWithValue ;
      tpl:hasPropertyPossessor ex:JohnDoe783 ;
      tpl:hasPropertyType rdl:RDS7285420 ;
      tpl:valPropertyValue "79.2"^^xsd:decimal ;
      tpl:hasScale  rdl:RDS1328669 ;
      meta:valEffectiveDate "2021-06-24T15:42:00Z"^^xsd:dateTime .

In this case,where we have quantified information, it is easy to teach the computer to conclude that the first template stopped being valid at the appearance of the second one, provided the determining data (in red) are the same. Of course the actual weight didn't change stepwise. If that is a problem, then the sample rate must be increased, or you have to capture time series, such as HDF5 (for JohnDoe783 that would be a bit impractical :)).

Example 2
When the information is binary, either false or true, like the earlier flanged connection, it is necessary to use a kind of 'undo' templates (e.g. connect vs disconnect).

ex:73998074-4c6b-44aa-bb40-9ee3be73d0fe
      rdf:type tpl:ClassifiedDirectConnectionOfTwoIndividuals ;
      tpl:hasSide1 ex:287e30bb-8031-4515-8a70-c064ee17432d  ; # Inlet flange of pump P-101
      tpl:hasSide2 ex:fb363d94-3472-480d-912d-90b8cd8b33f9 ; # Flange at end of line RZ17801
      tpl:hasConnectionType rdl:RDS2229203 ; # FLANGED CONNECTION
      tpl:hasDirectConnection ex:67e630d9-b7a1-40a6-bd71-e17b255fe73e ; # auto-generated, can be used for template IndividualTypeUsedInADirectConnection
      meta:valEffectiveDate "2021-08-11T00:00:00Z"^^xsd:dateTime .

and later, when they are disconnected:

ex:61782f11-6278-436c-bc6e-db9a66de506e
   rdf:type tpl:DisconnectionOfTwoIndividuals ;
   tpl:hasSide1 ex:287e30bb-8031-4515-8a70-c064ee17432d  ; # Inlet flange of pump P-101
   tpl:hasSide2 ex:fb363d94-3472-480d-912d-90b8cd8b33f9 ; # Flange at end of line RZ17801
   meta:valEffectiveDate "2022-11-23T17:54:00Z"^^xsd:dateTime .

In that case it may be useful to explicitly state that the first template is no longer valid, or 'deprecated' by generating one triple:

ex:73998074-4c6b-44aa-bb40-9ee3be73d0fe  meta:valDeprecationDate  "2022-11-23T17:54:00Z"^^xsd:dateTime .

because that saves CPU cycles when querying.

ISO 15926 TUTORIAL - LESSON 8 - Templates

Declarations

Temporal Parts