TIPs - Templates of Information Pattern

latest update: 2018-12-22       



A TIP (Template of Information Pattern) is a statement with two or more variables that, when instantiated, expands into the declaration of zero to many things and/or the declaration of one or more specialized ISO 15926-7 template instances.


TIPs form a bridge between engineering language, often with its shortcuts, and the semantically equivalent set of ISO 15926-7/8 lowered template predicates.

The TIP "signature" is filled out and the mapping software does the rest.

Any TIP is the top of its iceberg. TIPs are there to provide a link between an engineer with his software that has a lot of implicit information, and the world of explicit integrated lifecycle information, which at times is rather verbose.

TIPs are usually applicable for individual data elements, but it is possible to build larger constructs.



Each TIP has a "signature" with "variables". The values of the variables are to be fetched from the source document or file.


After completion of the TIP signature and making a selection of the pick-list(s) an ISO 15926-7/8 compliant code listing in Turtle (N3) format is being generated and made output.



1-Information Model

The data analyst first composes a small information model, like this one:

This makes visible what the, often hidden, information structure is.

2-Declare missing objects

Normally information is, directly or indirectly, related to something that is already known to the observer (if not, the information may be rather meaningless). In this example the pressure rated artefact, such as a pressure vessel, is known, because the "test pressure" is information about it, be it indirectly as we can see from the information model.

So the activity HYDROSTATIC TESTING and the fluid used for that testing shall be declared here.

These declared objects get, in most cases, a subtag of the main object that was already known, unless the source application already has made them explicit.

3-Represent interrelations

Using the applicable templates, selected from here, the relations between the objects in the above information model are being represented.

Class or Individual

When writing the CONSTRUCT statement it is important to properly decide on the question whether this information applies to an Individual thing or to a Class of Individuals

Without implying that further study on this is unimportant, it is possible to give a few rules of thumb:

  1. All information related to Engineering & Design is at Class level, with the exception of topological information found on functional diagrams (e.g. P&IDs) or in 3D models
  2. All information related to Procurement, Manufacturing, Logistics, Construction, Operations and Maintenance is at (actual) Individual level, except for procedures, rules and regulations.

Typical TIPs

Given the fact that there are many thousands data fields passing by during the life of a plant, it isn't very wise to try to build a TIP for each and every such data. Due to the generic character of the ISO 15926 data model, a TIP can be re-used multiple times, with only one or a few variations in the input of the signature. That is why the name is about "information patterns".


At places in the TIP signature where multiple values are possible (and one has to be selected) use can be made of pick-lists. Constructing those, if so required company-defined, pick-lists also limit the chances of incorrect choices or misspellings.

TIP names

Tip names shall be informative for an engineer, and that applies as well to the names of the variables. The TIP name is the ID of that TIP type. For example:

   :710F6CC1777346C18230A7EBD3505655 rdf:type tip:DocumentRefersToClassOfIndividual ; # for example: pump specification BR-43805 rev. 2 is referred to on Purchase Order Xp-54043

For Individuals distinction shall be made between designed Individuals (those in a topology, see above) and actual Individuals (those who exist in the real world). One example for each:

   :A4BF55C8E36A406D976F6A49AAC619C3 rdf:type tip:DocumentRefersToDesignedIndividual ; # for example: pump P-101 is referred to on P&ID P12345-rev.1

   :74FBB77E5D38403AB618DC98B770F9E0 rdf:type tip:DocumentRefersToActualIndividual ; # for example: pump with serial number RU-43983 is referred to on Test Report T84427


TIP definitions are accessible here. NOTE - This is Work In Progress!! They can be freely copied, changed, and used.

"Old" TIPs

In recent years industry and software representatives in the USA and Great Britain have put together an extensive list of 406 TIPs. This list can be found here.

These "old" TIPs will be, over time, mapped to the TIPs defined in this topic.


Each output file starts with a heading like this one:

    @prefix : <> . # just a fantasy URI for project p1234 of the XYZ inc.

    @prefix xsd: <> . # defines Literals (text, dateTimes, numbers, etc)

    @prefix rdf: <> .

    @prefix rdfs: <> .

    @prefix owl: <> .

    @prefix skos: <> . # defines metadata

    @prefix meta: <> . # defines ISO 15926-specific metadata

    @prefix dm: <> . # defines the ISO 15926-2 data model

    @prefix edm: <> . # defines an extension of the ISO 15926-2 data model

    @prefix tpl: <> . # defines the ISO 15926-7 templates

    @prefix rdl: <> . # defines the ISO 15926-4 reference data

    @prefix xyzrdl: <> . # just a fantasy URI for an RDL extension of the XYZ inc. (if any)

The user-defined URIs can be inputted by the user.


As explained above, each TIP has, like the templates, a "signature", so a number of fields that have to be filled (the yellow part). By the way, there is also a TIP variant of each template.

Nowadays it is fashionable to have a "Data Lake", but in essence that is a collection of "data pools" in native format, one per application. It helps to make data access easier, often with SQL queries.

One can map the necessary data from, for example, a name in the data lake to an RDL Class in the signature, or a dateTime from an internal format to the XML Schema format used in the Semantic Web world.

As explained below, for each TIP a Generic Code is stored, in which the yellow fields, as shown in above diagram, are then populated. That results in a Part 8 file.

This file is passed through a SHACL validator (Part 10) and, if correct, uploaded to a triple store that stores the integrated life-cycle information of the plant or a part thereof.


In order to obtain application-specific reference data, one or more SPARQL queries can be fired to that triple store, and the query results are then imported, after mapping, into the application for which the query results were intended.

Every application that is used in the life cycle of the plant can, with the proper access rights, retrieve exactly the data that it needs, and when it needs it, through such queries.

Detailed description of a use case

Hydrostatic Test Fluid

In the normal work process first the type of fluid for hydrostatic testing is defined. This is represented with the TIP HydrostaticTestFluidOfClassOfInanimatePhysicalObject.





Hydrostatic Test Pressure

Then follows the definition of the test pressure, using the TIP HydrostaticTestPressureOfClassOfInanimatePhysicalObject