Declaring an object

Latest update: 2020-01-06        


  

Introduction

In ISO 15926-8 Annex C we find:

C.8.1 Declaration

Where in OWL resources are normally not declared, this is mandatory in this part of ISO 15926.

The only exception is that any temporal part, being the rdf:object of a template property, shall not be explicitly declared.

(side note: now a classOf(Temporal)Part of an Class should be added, see also here).

This paper deals with that declaration requirement.

Discussion

Since information can be defined as: "A (yet) unknown set of relationships between things known, or made known, to the recipient", it is essential that the information about those things is accessible for each recipient so that the information can be put in a context. This is done by using Semantic Web technologies with their URI references. A logical consequence of that is that all such referred-to things need to be declared as instances of one or more ISO 15926-2 classes.

Solution

Classes

When an instance of a (Part 2) Class is declared the following information must be given:

  • the ID of the declared Class (usually a UUID);
  • typing with the applicable instance of a Part 2 entity type;  
  • the  instance(s) of ClassOfFunctionalObject in the RDL (the "Essential Type" e.g. VESSEL or PUMP) of which the Class is a subclass;
  • the label with the identifier valid at declaration time or, alternatively, a descriptive identification in that label (e.g. "Block valve upstream of P-101");
  • the "Lifecycle Activity", e.g DETAILED ENGINEERING, during which the Class has been declared ;
  • the dateTime this declaration became effective.

A typical example is the code for knock out drum class.

First it is declared as being a member of VESSEL, and then it is made a KNOCK OUT VESSEL, being a specialization of VESSEL. The reason for this two-step approach is that a template can easily be replaced with another one, but changing the type of a declared object is complicated and forbidden for an end-user.

The TIP signature for this declaration would be:

tip:C1601  -  DeclarationOfClassOfPhysicalObject

element no.

value

TIP variable

1

"CO_B14-V-101"

TIP_C1601_var_Label

2

ClassOfInanimatePhysicalObject

TIP_C1601_var_Label#EntityType

3

VESSEL

TIP_C1601_var_Label#EssentialType

4

DETAILED ENGINEERING

TIP_C1601_var_LifecycleActivity

5

"2004-11-24T14:57:00Z"

TIP_C1601_var_EffectiveDate

NOTE: Use an instance of ClassOfFunctionalObject unless that is not in the RDL, else the highest in the hierarchy of relevant instances of the applicable subclass of ClassOfPhysicalObject. 

:AECD286079EF4CB394554D4D2342CCD5 rdf:type dm:ClassOfInanimatePhysicalObject ;

    rdfs:subClassOf rdl:RDS414674 ; # VESSEL

    rdfs:label "CO_B14-V-101" ;

    meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

and later, e.g. based on P&ID information:

:8F109CBC01AC40E2A0A066B54A1218F6 rdf:type tpl:SpecializationOfClassOfIndividual ;

    tpl:hasSubClass :CAECD286079EF4CB394554D4D2342CCD5 ;

    tpl:hasSuperClass rdl:RDS43167567209 ; # KNOCK OUT VESSEL

    meta:hasLifecycleActivity rdl:RDS9709622 ; # DETAILED ENGINEERING

    meta:valEffectiveDate "2004-11-25T11:34:00Z"^^xsd:dateTime .

Assume that, for some reason (for example in case someone else gave a different ID to what appears the same thing), the ID is changed from AECD286079EF4CB394554D4D2342CCD5 to 926AC172CB4E48F7BA2FF9DA823D5DC0 at a later date, then the following happens:

:926AC172CB4E48F7BA2FF9DA823D5DC rdf:type dm:ClassOfInanimatePhysicalObject ;

    owl:sameAs :AECD286079EF4CB394554D4D2342CCD5 ;

    meta:hasLifecycleActivity rdl:RDS9709622 ; # DETAILED ENGINEERING

    meta:valEffectiveDate "2006-10-14T09:32:00Z"^^xsd:dateTime .

In cases where the new ID has been created independently, by error or else, and is not deprecating the old ID, both ID's can co-exist (for a while). owl:sameAs is transitive, so information about the one also applies to the other. Ultimately though, the sooner the better, one of both shall be deprecated and the still valid templates about it shall be referring to the remaining ID. This can be done with SPARQL Update DELETE/INSERT.

PREFIX p1234: <http://p1234.example.org/data#>

WITH <http://p1234.example.org/data#>

DELETE { ?s ?p p1234:AECD286079EF4CB394554D4D2342CCD5 }

INSERT { ?s ?p p1234:926AC172CB4E48F7BA2FF9DA823D5DC }

WHERE  { ?s ?p p1234:AECD286079EF4CB394554D4D2342CCD5 }

Declaring a class of temporal part of a Class

In cases described in the topic Temporal Parts a class-of-temporal-part Class has to be declared. This is done as follows:
  • declare that temporal part the same as the temporal whole, the entity type and essential type are inherited, but since RDF does not support that we have to do it ourselves
  • use the template ClassOfTemporalWholePartDefinition.

Deprecating a Class

In case the relevance of any instance of Part 2 ClassOfIndividual ends, this shall be recorded as follows:

:926AC172CB4E48F7BA2FF9DA823D5DC meta:valDeprecationDate "2014-02-15T12:55:00Z"^^xsd:dateTime ;

The validity of all templates in which this Class plays a role are, as a consequence, also ended, i.e. invalid as of the given valDeprecationDate. The software shall take care of that.


PhysicalObjects

When an instance of a (Part 2) PhysicalObject is declared the following information must be given:

  • the UUID of the declared PhysicalObject;
  • typing with one of the Entity Types (alphabetically):  lci:Feature, lci:InanimatePhysicalObject, lci:InformationObject, lci:Organism, lci:Organization, lci:Person, dm:SpatialLocation, or dm:Stream ;
  • the "essential type" of which the PhysicalObject is a member - in most cases this is an instance of dm:ClassOfFunctionalObject (see NOTE) ;
  • typing with either dm:ActualIndividual or lci:NonActualIndividual (see topic Possible Worlds)
  • typing with the Part 2 entity type dm:WholeLifeIndividual (not in cases of temporal parts being declared, see below);
  • a label with the identifier valid at declaration time (e.g. P-101) ;
  • the "Lifecycle Activity", e.g PLANT DESIGN, during which the Class has been declared ;
  • the dateTime this declaration became effective.

The TIP signature for this declaration would be:

tip:C1601  -  DeclarationOfClassOfPhysicalObject

element no.

value

TIP variable

1

"B14-V-101"

TIP_P1751_var_Label-1

2

InanimatePhysicalObject

TIP_P1751_var_Label-1#EntityType

3 *)

VESSEL

TIP_P1751_var_Label-1#EssentialType

4

NonActualIndividual

TIP_P1751_var_Label-1#WorldType

5 **)

dm:ClassOfInanimatePhysicalObject

TIP_P1751_var_Label-2#EntityType

6

PLANT DESIGN

TIP_P1751_var_LifecycleActivity

7

"2004-11-24T14:57:00Z"

TIP_P1751_var_EffectiveDate

*) NOTE - If that is not in the RDL, then use the highest in the hierarchy of relevant instances of ClassOfInanimatePhysicalObject.

**) Together with an instance of dm:PhysicalObject the matching 'Ur' Classes, one for the functional aspects and one for the physical aspects, shall be declared. See here. For compleness' sake these two classes are shown below as well.

A typical example is:

:E09170257F9541D48B5F2937A2A40920 rdf:type lci:InanimatePhysicalObject, lci:NonActualIndividual, dm:WholeLifeIndividual, rdl:RDS414674 ;

    rdfs:label "B14-V-101" ;

    meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

:143bb400-e5b5-439e-9bdc-4e9921fae755

    rdf:type lci:ClassOfFunctionalObject ;

    rdfs:subClassOf rdl:RDS414674 ; # VESSEL

    rdfs:label  "CO_B14-V-101-FO" ; # Functional Requirements Class of B14-V-101

    meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

:0edd1f18-b78d-4a38-9621-adf030ae4558

    rdf:type dm:ClassOfInanimatePhysicalObject ;

    rdfs:subClassOf rdl:RDS414674 ; # VESSEL

    rdfs:label  "CO_B14-V-101" ; # Product Requirements Class of B14-V-101 (by specialization this include

    meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

Now the vessel can be classified as being a member of KNOCK OUT DRUM and as being a member a "requirements class" as defined in a specification.

The TIP signature for this is:

tip:P1001  -  ClassificationOfIndividual

element no.

value

TIP variable

1

"B14-V-101"

TIP_P1001_var_Label-1

2

InanimatePhysicalObject

TIP_P1001_var_Label-1#EntityType

3

VESSEL

TIP_P1001_var_Label-1#EssentialType

4

NonActualIndividual

TIP_P1001_var_Label-1#WorldType

5

KNOCK OUT VESSEL

TIP_P1001_var_Label-2

6

ClassOfInanimatePhysicalObject

TIP_P1001_var_Label-2#EntityType

7

VESSEL

TIP_P1001_var_Label-2#EssentialType

8

PLANT DESIGN

TIP_P1001_var_LifecycleActivity

9

"2004-11-24T14:57:00Z"

TIP_P1001_var_EffectiveDate

resulting in:

:B17206B8D8BD48B6BDD991A836B9C461 rdf:type tpl:ClassificationOfIndividual ;

    rdfs:label "[VESSEL][B14-V-101] is a member of [VESSEL]class [KNOCK OUT VESSEL]" @en ;

    tpl:hasClassified :E09170257F9541D48B5F2937A2A40920 ;

    tpl:hasClassifier rdl:RDS43167567209 ; # KNOCK OUT VESSEL

    meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

Declaring a temporal part of an Individual

In cases described in the topic Temporal Parts a temporal part of an Individual has to be declared. This is done as follows:

  • declare that temporal part the same as the temporal whole, the entity type and essential type are inherited, but since RDF does not support that we have to do it ourselves
  • use the template IndividualHasTemporalPart.

Ending a PossibleIndividual

In case the existence of any instance of Part 2 PossibleIndividual ends, this shall be recorded as follows:

:E09170257F9541D48B5F2937A2A40920 meta:valDeprecationDate "2014-02-15T12:55:00Z"^^xsd:dateTime .

The validity of all templates in which this individual plays a role are, as a consequence, also ended, i.e. invalid as of the given valDeprecationDate, but kept for future reference.

Only when the need for reasoning with OWL-based tools arises, for example during the LIFE-CYCLE INVENTORY ANALYSING, this is to be mapped to an instance of the EndingOfIndividual template:

:2F918E7426514896BC8C50FF52AF677B rdf:type tpl:EndingOfIndividual ;

    tpl:hasIndividual :E09170257F9541D48B5F2937A2A40920 ;

    tpl:valEndTime "2014-02-15T12:55:00Z"^^xsd:dateTime ;

    meta:hasLifecycleActivity rdl:RDS14526342 ; # LIFE-CYCLE INVENTORY ANALYSING ;

    meta:valEffectiveDate "2014-02-15T12:55:00Z"^^xsd:dateTime .