Introduction

In ISO 15926-2, further referred to as 'Part 2', the following statement can be found in Clause 4:
"4.1 Conceptual data model - The data model specified in clause 5 is a conceptual data model".
The term conceptual data model is based on the three-schema architecture as described in ISO/TR 9007.

In this topic the place of Part 2 in the architecture of ISO 15926, and the place of other Parts, is explained.

Explanation

Let's start with a diagram below, found on the website of the Business Rules Community. and adapted here

Figure 1 - Three-level architecture of ISO 15926

The role of the various Parts will be discussed.

The role of Part 2

A definition of a conceptual data model is:

A Conceptual Data Model is a high-level, abstract representation that defines the significant entities, their attributes, and the relationships among them within a business context. It captures essential concepts and vocabulary without delving into the technical details of data storage or implementation, fostering a shared understanding among stakeholders regarding the organization's data requirements.

Combine this with the fact that Part 2 also in an Upper Ontology. That gives the following consolidated definition:

ISO 15926-2 is an upper ontology that provides a high-level, abstract framework for representing the significant entities, attributes, and relationships relevant to the integration of life-cycle plant information across various domains.

It establishes general terms and concepts—such as "physical object," "property," and "relationship"—that support broad semantic interoperability among domain-specific ontologies.

By offering a common starting point for the formulation of definitions, ISO 15926-2 enables the creation of Conceptual Data Models that accurately capture the essential business concepts and their interrelations without delving into the technical specifics of data storage or implementation.

The function of Part 2 can also be seen in this quote from Part 2:

Data integration means combining information derived from several independent sources into one coherent set of data that represents what is known. Because the independent sources often have overlapping scopes, combining their data requires the common things to be recognized, duplicate information to be removed, and new information represented. To succeed in the role of integration, the data model must have a context that can include all the possible data that might be wanted or required.

The role of Part 4

Part 4, and its extension the 'RDL - Reference Data Library', are an extension of Part 2.

For example: Part 2 defines the concept of ClassOfInanimatePhysicalObject, Part 4 defines generic instances of that Class, such as COMPRESSOR, KNOCK-OUT DRUM, FLOW TRANSMITTER, BOLT, CABLE, etc. with, where still generic, specializations thereof, e.g. INTEGRALLY GEARED CENTRIFUGAL COMPRESSOR. Suppliers can further specialize these to their products in their RDL extension. There are extensions for standards-based classes, e.g. ASME, IEC, etc.

Neither Part 4 nor the derived RDL define ontologies for these generic Classes. Where required this should be done in local RDL extensions for the simple reason that it is almost impossible to come to an agreement globally. Many larger companies already invested in such ontologies and are not willing to donate these, nor willing to accept someone else's ontology. As such that shouldn't cause an interoperability problem IFF everybody sticks to the Part 2 grammar and give a recipient of their data access to their ontology.

The role of Part 6

Part 6 defines the rules for setting up an RDL (extension).

The role of Part 7

With Part 7 Templates can be designed or used from a vocabulary of some 200 Template Specifications.

A template consists of two parts:

• a model, using Part 2 entity types that defines the semantics of the template;
• an n-ary relationship that collects the variables of that model.

A template defines an elementary ontology, and a template instance represents an elementary piece of information.

Templates are 'first class objects' in RDF, an therefore autonomous. They can be collected and addressed in application-dependent 'views'.

The role of Part 8

Part 8 defines the mapping format from the source system dependent data formats to a standard Part 7 Template format, in two types:

• the format of declarations of the things involved in one or more template instances ;
• the format of template instances.

The role of Part 9

Part 9 still has to be formalized. In essence it will cover the definition of an API for any commercial triple store or quad store, thus making these uniform in the way they can be accessed , managed and federated.

The services of that API roughly cover: Part 8 file import and export, data caching, data hand-over, SPARQL query processing, federation, URI dereferencing, and security.

The role of Part 10

After data from a source application have been mapped to the Part 8 format, they need to be validated. This can be done with SHACL. Part 10 defines the procedure.

The target is to test all Part 8 exchange files before these are uploaded to a triple/quad store. That is essential, because these data may be shared immediately. There is no time available for cleansing.

The role of Part 11

Part 11 is an implementation Part, based on Trig and Named Graphs.