Latest update: 2019-11-30
IntroductionThis Portal gives an overview on ISO 15926 and then zooms in to places where detailed information about all (or most) aspects can be found.
ScopeThe scope of ISO 15926 is "Integration of life-cycle data for process plants, including oil and gas production facilities".
Of course that is not a goal in itself, but it serves two main purposes:
The various aspects, shown on this diagram, will be detailed in order of appearance:
The "Part 2 Upper Ontology" refers to the data model defined in ISO 15926-2, which will, in the next version of Part 2, be extended with entity types that detail PhysicalObject. This model is very generic and strongly typed. For example it defines PhysicalObject but not Pump, that comes later in the General concepts. All entity types defined here are specializations of Thing. And no matter how far we proceed in this Portal, that line of descent is maintained throughout.
A special feature of the Part 2 data model is that it has 129 generic Relationship classes that, together with 93 generic classes, for the basis of its value as Upper Ontology.
The above generic model is extended with, still generic, instances of the Part 2 entity types. For example CENTRIFUGAL PUMP is an instance of ClassOfInanimatePhysicalObject. And it has many specializations that together form a class hierarchy or taxonomy. All this is done in the RDL - Reference Data Library. Try the first set of specializations of PUMP here and all specializations here (this and others can be found at http://15926.org/RDL2/views/ .
Each of the 40,000 classes that are in the ISO 15926-4 RDL plus extensions has a URI, accessible via the internet, and is typed with a Part 2 entity type. Pumps and other items are generically defined, so supplier-, or standardization body-, or project-specific pumps (or other object classes) are not defined in the RDL, but in extensions thereof.
Visit http://15926.org/topics/reference-data/index.htm for futher details.
Such specialization can also be indirectly, as shown in the diagram here.
At the bottom of such a taxonomy, that stretches from Thing downwards, is a Requirements Class, usually defined with a technical specification, ans/or a Product Class, as defined by a product specification of a manufacturer/supplier, or a product class that has been further specialized by configuration and pricing in a quotation.
A specialization of a class inherits everything from all its superclasses, so keep that in mind when extending a taxonomy.
Integration model subset
All above classes are possible ingredients for Templates, as defined in ISO 15926-7 and implemented in line with ISO 15926-8. At present 228 templates have been specified in Template Specifications which can be found here.
Where Part 2 is the Upper Ontology, these Templates are Elementary Ontologies. Information, as represented by data elements in applications, can be mapped to instances of these Template classes. The template axiom defines whether such a mapping is valid. See SHACL below.
Since template signatures refer to objects, it is essential that these objects have been declared as an instance of the applicable Part 2 entity type(s). See here for more details.
The problem with mapping is that there is a shortage of data engineers. So the concept of TIPs has been introduced as a mapping technology. A TIP signature calls for strings and numbers as these appear in the mapping source data base or spreadsheet, making ETL easier in most cases. A wizard in under development in order to assist the mapping person.
TIPs can be specialized to make the selection of the proper TIP easier.
Once the processing unit for a data element has been made and tested, the actual mapping fetches the data element value, for example with an SQL query, and the template instance is generated.
shall be used. See also here.
RDF file in Turtle (preferred) or RDF/XML format. This file is converted to N-triples and stored in a Triple Store.
The query language for that is SPARQL. Most SPARQL implementations produce a query result in JSON format.
interoperability. So not only exporting generated data, but also importing data produced by another application, recently or perhaps twenty years ago and now required for a revamp project. The adapter must map particular query results to the internal format and naming of the required input data.
A possible configuration for a project could look like this one (note the integration of an EDMS):