Ontologies

latest update 2023-08-27  

Introduction

First a W3C Definition:

An Ontology defines the concepts and relationships used to describe and represent an area of knowledge.
Ontologies are used to classify the terms used in a particular application, characterize possible relationships, and define possible constraints on using those rlationships.

The RDL (Reference Data Library) lists the concepts (Classes) in above definition in a taxonomy. That taxonomy has the entity types of the data model of ISO 15926-2 as the top. Below that are their specializations, as applicable to the Process Industries.

In this topic the (to-be-establisched) Reference Ontology, covering the "relationships" in above definition, is outlined. These relationships come in the form of ISO 15926-7/8 Template instances

Discussion

Before getting lost in the details it makes sense first to show how the classes are arranged in the ISO 15926-2 data model. For this the diagram from the topic "How does P101 fit in?" is used:

We can define ontologies in three levels plus two specializations of the third level:

  • the Upper Ontology ('UO') of metaclasses, as defined in ISO 15926-2 with its relationship classes, in dark blue part.
    The ISO 15926-7 "Templates for Classes" define "elementary ontologies" using metaclasses
  • the Upper Ontology of classes, as defined in ISO 15926-2 with their relationships, in the lightblue part.
    The ISO 15926-7 "Templates for Individuals" define "elementary ontologies" using classes *)
  • the Reference Ontology, with instances of ClassOfIndividual and its specializations, shown in the diagram as 'RDL core classes'.
    The ISO 15926-7 Templates define "elementary ontologies", and its specializations:
    • Unit Operations in Process Design, see here;
    • the Engineering & Design Class, defined for an Asset Requirements Class, properly modeled following its specification;
    • the Product Model of a manufacturer, properly modeled following the product specification and other documents (e.g. an 'exploded view').

*) As shown, PossibleIndividual, as entity type in ISO 15926-2 is typed as an owl:Class, hence the seeming contradiction.

This is shown in the diagram below, showing an example of a centrifugal pump and its impeller(s):

The rounded-off blocks are Relationships or ClassOfRelationships, where the latters define the semantics of the ontologies. Keep in mind that there are many different types of relationships.

Sticking to this example we can think of the following for the five ontologies:

  • The Metaclass Upper Ontology of ISO 15926-2 defines generically that any member of ClassOfAssemblyOfIndividual relates two members of ClassOfPhysicalObject in that members of the 'classOfPart' are the part in an assembly with members of 'classOfWhole' are the whole in that assembly.
  • The Class Upper Ontology of ISO 15926-2 defines generically that any member of AssemblyOfIndividual relates two members of PhysicalObject. It gives the following example: "The relation that indicates that a temporal part of an impeller is a part of an assembled pump can be represented by an instance of AssemblyOfIndividual, where that impeller and that pump are instances of PhysicalObject."
  • The Reference Ontology of ISO 15926-4 (to be) defines ontologies for Core Classes, as can be found in the Reference Data Library (RDL). For example: Any member of CENTRIFUGAL PUMP has zero to many members of IMPELLER, whereas any member of a specialization of that class, TWO STAGE CENTRIFUGAL PUMP, has exactly two impellers. NOTE - This ontology is still in the planning phase:
    • In Engineering & Design this applies to one particular Asset Requirements Class, as defined with a technical specification. It spells out what the required characteristics of that Class are, and can be used to verify the compliance of any occurring member of that class
    • A Product Model is made by the applicable manufacturer, as defined by his product specification, and spells out what the characteristics of any real-world member physical object shall be.

Exegesis

For any occurrence of PossibleIndividual the following information applies:

  1. It is a member of one of the specializations of PossibleIndividual (see here), including whether or not it is a WholeLifeIndividual, and whether it is a NonActualIndividual (design) or an ActualIndividual (real world)
  2. Any such individuals have relationships with other individuals, as modeled here for an assembly relationship
  3. When it is a NonActualIndividual:
    • its characteristics and relationships may (not must), in general, have been defined in a Reference Ontology, be it as a part of ISO-15926-4 or a proprietary one
    • it is a member of many classes that define its required characteristics (material of construction, properties, sizes, etc). The intersection of these required classes is called the Requirements Class of that NonActualIndividual
  4. When it is an ActualIndividual
    • its actual characteristics are, unless it is off-spec, as defined in the applicable Product Model, set forth in the applicable quotation of the seller.
    • when its actual characteristics are satisfying the requirements of the Asset Requirements Class, then it is a member of the latter Class as well (ideal situation)

Examples

The examples given below follow the diagram.

Metaclass upper ontology of ISO 15926-2

The ClassOfAssemblyOfIndividual 
ENTITY class_of_assembly_of_individual
    SUBTYPE OF (class_of_arrangement_of_individual);
END_ENTITY;

is a specialization of ClassOfArrangementOfIndividual

ENTITY class_of_arrangement_of_individual
      SUPERTYPE OF (ONEOF(class_of_feature_whole_part, class_of_assembly_of_individual, namespace))
      SUBTYPE OF (class_of_composition_of_individual);
      SELF\class_of_composition_of_individual.class_of_whole: class_of_arranged_individual;
END_ENTITY;

which is a specialization of ClassOfCompositionOfIndividual:

ENTITY class_of_composition_of_individual
      SUPERTYPE OF (ONEOF(class_of_arrangement_of_individual, class_of_temporal_whole_part, class_of_participation))
      SUBTYPE OF (class_of_relationship);
      class_of_part  :  class_of_individual;
      class_of_whole :  class_of_individual;
END_ENTITY;

It has two relations, classOfPart and classOfWhole, that both have an instance of ClassOfIndividual as rdfs:object (i.e. points at the URI of that instance).

This is ISO standard, cast in concrete.

Class upper ontology of ISO 15926-2

The AssemblyOfIndividual relationship

ENTITY assembly_of_individual
    SUBTYPE OF (arrangement_of_individual);
END_ENTITY;

is a specialization of ArrangementOfIndividual

ENTITY arrangement_of_individual
    SUPERTYPE OF (ONEOF(assembly_of_individual, feature_whole_part))
    SUBTYPE OF (composition_of_individual);
    SELF\composition_of_individual.whole  :  arranged_individual;
END_ENTITY;

which is a specialization of CompositionOfIndividual:

ENTITY composition_of_individual  
    SUPERTYPE OF (ONEOF(arrangement_of_individual, temporal_whole_part, participation, temporal_bounding))  
    SUBTYPE OF (relationship);  
    part    :   possible_individual;  
    whole   :   possible_individual;   
END_ENTITY;

It has two relations, part and whole, that both have an instance of PossibleIndividual as rdfs:object (i.e. points at the URI of that instance).

This is ISO standard as well, cast in concrete.

Reference Ontology of ISO 15926-4

The example shown in the diagram is that any member of the ClassOfInanimatePhysicalObject CENTRIFUGAL PUMP has one-to-many members of the ClassOfInanimatePhysicalObject IMPELLER.
This can be represented with the following specialization of the ISO 15926-7 Template ClassOfAssemblyDefinition 

ont:CentrifugalPumpAssembly-001 
	rdf:type lci:Template ;
	rdfs:subClassOf  tpl:ClassOfAssemblyDefinition ;
    	rdfs:label  "[ONE TO ONE] member(s) of [PUMP] class [CENTRIFUGAL PUMP] have [ONE TO MANY] member(s) of [IMPELLER] class [PUMP IMPELLER] as parts
                    in an assembly"@en ;
    	tpl:hasClassOfWhole rdl:RDS416834 ; # CENTRIFUGAL PUMP
    	tpl:hasClassOfPart  rdl:RDS816299 ; # PUMP IMPELLER
    	tpl:hasDefined :36fbed7d-21b3-4543-9402-d20c8e8ace79 ; # see note
    	tpl:hasCardinalityOfWhole rdl:RDS222625 ; # ONE TO ONE
    	tpl:hasCardinalityOfPart rdl:RDS999900701 ; # ONE TO MANY
    	meta:valEffectiveDate "2021-02-14T00:00:00Z"^^xsd:dateTime .

Some notes to this:

  1. This is not yet in existence in the RDL (under discussion)
  2. The rdfs:label is optional but recommended for human interaction (can be generated at a later point in time based on stored data)
  3. tpl:hasDefined is the UUID of the instance of ClassOfAssemblyOfIndividual that is hidden in the template model, and can be used classifiying the AssemblyOfIndividual relationship hidden in an instance of the template AssemblyOfAnIndividual
  4. The cardinalities in ISO 15926 relate to occurrences of the related objects (different from ISO 15926-2, see here for an explanation).
  5. A specialization of CENTRIFUGAL PUMP is a TWO-STAGE CENTRIFUGAL PUMP, where the tpl:hasCardinalityOfPart is TWO TO TWO (rdl:RDS222626) because the member pump has two instances of a member impeller.
  6. Such Reference Ontologies (a.k.a. Object Models) can be rather unwieldy, not because the standard is unwieldy but because it is so in reality. Take for instance the ontology for a CENTRIFUGAL PUMP SYSTEM that includes many parts, for which information can be defined. A possible composition of such a system is shown below:

Keep in mind that the pumped Stream class is not included above.

As can be understood, setting up ontologies like this for all equipment types requires a serious investment, but it will provide a far better communication between all parties involved in the industry. It will be an essential prerequisite for powerful engineering, bid evaluation, and inspection software.

Unit Operations

In the Process Design section of the Plant Life-cycle Model the three parts of the shown Activity Model can be predefined at Class level, when necessary precisely to process case level.

Engineering & Design

Each piece of information is a Class of which many Individuals can be a member. For example, the temperature of 37° C is 'possessed' by billions of people, and the material of construction 316SS applies to many artefacts. This means that an Individual that possesses a temperature of 37° C is a member of that Class. The rationale of the authors of ISO 15926-2 was, and is, that a property is a class of individuals possessing that property.

So, the instance of ClassOfInanimatePhysicalObject called CENTRIFUGAL PUMP is the intersection of all applicable characteristics Classes, as defined on a technical specification, like in this case the API 610 Data Sheet for Centrifugal Pump. This intersection can be modeled by making all template instances members of an instance of EnumeratedSetOfClass.

NOTE - In the context of CFIHOS this is a specialization of their Tag Class with Tag Class Properties.

Product Model

This is, for each product model of a manufacturer, similar to an Asset Requirements Class, be it for classes with a far larger membership. The Stream-related characteristics are different, because based on standard conditions.

For plant information a configured and specialized Product Model, marked with [70] in the Plant Lifecycle Model, is useful.

NOTE - In the context of CFIHOS this is about their 'Model Part' with 'Model Part Properties', and a specialization of their Equipment Class with Equipment Class Properties.