Introduction

Information is an often complex relationship between objects that are known, or made known, to the recipient of that information. As a consequence of that it is mandatory to delare everything that in involved in that information, or, of course, refer to an earlier made declaration. Declarations are to be made only once.

Declarations are to be made for:

• Instances of dm:PossibleInddividual ;
• Temporal parts of instances of dm:PossibleIndividual ;
• Instances of dm:Class ;
• Class-ofptemporal-parts of instances of dm:Class .

Instances of dm:PossibleIndividual

Additionally any PossibleIndividual:

• shall be typed with what it essentially is, by one of: ;
• lci:Feature ;
• lci:FunctionalObject (use in Process Design only) ;
• lci:InanimatePhysicalObject ;
• lci:InformationObject ;
• lci:InformationRepresentation ;
• lci:Organism ;
• lci:Organization ;
• lci:Person ;
• dm:PhysicalObject ;
• dm:SpatialLocation ;
• dm:Stream.
• shall be typed with dm:WholeLifeIndividual ;
• shall be typed with either lci:NonActualIndividual (e.g. pump P-101 on a P&ID) or dm:ActualIndividual (e.g. a pump installed in a plant) ;
• shall be typed with its "essential type", that is a reference class that is the highest senseful class in its hierarchy ;

Example

ex:112473e9-7642-45d2-ade2-c68a5ed47cf3
	rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, dm:ActualIndividual, rdl:RDS414081061 ; # PUMP SYSTEM 
	rdfs:label "B14-P-101" ; 
	meta:hasLifecycleActivity rdl:RDS2229995 ; # PLANT DESIGN (optional)
	meta:valEffectiveDate "2022-01-09T14:05:23Z"^^xsd:dateTime .

Note that any declaration of an instance of PossibleIndividual shall include the declaration of the anchor Classes of which it is a member. This is described in full detail here.

Temporal parts of instances of dm:PossibleIndividual

A temporal parts of an Individual inherits from its temporal whole. So it is not necessary to repeat the typing of that temporal whole. If a temporal part of a pump is pumping fluid, that pump is still installed, manufactired, etc.

In case the information is being represented with templates, the temporal parts are implied, and hidden inside those templates. Temporal that are required, see here, are then declared by using the template IndividualHasTemporalPart.

In case the TP+P Method is used, use the predicate pred:temporalPartOf. One word of warning: RDF doesn't support inheritance, so the software you use shall include that support.

Examples

Pump B14-P-101_2022-09-15T14:30:00Z is delivered at site and is registered as Asset. It gets an Asset Number, and inherits from its temporal whole B14-P-101 the Serial Number.

With a Template

ex:9b2cb8a4-e797-4c1d-9837-0734ceaeef05
      rdf:type tpl:IndividualHasTemporalPart ;
      rdfs:label "[PUMP] individual [B14-P-101] has an individual [B14-P-101_2022-09-15T14:30:00Z] as a temporal part"@en ;
      tpl:hasTemporalWhole  ex:e836d6a9-12d6-4481-9e33-17089c9ebe08 ; # B14-P-101
      tpl:hasTemporalPart  ex:be3287f1-ceac-41ff-944a-90fa8e3afcbe ; # B14-P-101_2022-09-15T14:30:00Z
      meta:valEffectiveDate "2022-09-15T14:30:00Z^^xsd:dateTime .

With the TP+P Method:

ex:be3287f1-ceac-41ff-944a-90fa8e3afcbe
       pred:temporalPartOf ex:112473e9-7642-45d2-ade2-c68a5ed47cf3 ;  # B14-P-101
       rdfs:label "B14-P-101_2022-09-15T14:30:00Z" ;
       meta:valEffectiveDate "2022-09-15T14:30:00Z"^^xsd:dateTime .

Instances of dm:Class

You can find Classes everywhere: in ISO 15926-2 as entity types, in ISO 15926-4 as reference data, with specialization in standardization organization vocabularies, requirement specifications, and supplier catalogs.
In an ISO 15926 triple store all classes are ultimately specializations of dm:Thing.

Each instance of (a subtype of) Class :

• shall be typed with one or more ISO 15926-2 metaclasses ;
• may be speciallized from another Class ;

Example

ex:4a13f181-9ced-48ff-b04f-c99e1dfb9886
	rdf:type dm:ClassOfInformationObject ;
	rdfs:subClassOf rdl:RDS222341 ; # TECHNICAL REQUIREMENTS SPECIFICATION
	rdfs:label "KC01-71-990-KW-T-YP-0002" ;
       meta:valEffectiveDate "2022-10-13T14:23:00Z"^^xsd:dateTime .

This could be the 'document master' of the technical requirements specification for pump B14-P-101. Note that the document title comes later, because titles my change.

Class-of-temporal-parts of instances of dm:Class

Similar to temporal parts of PossibleIndividuals we also have temporal parts of Classes. As such that sounds strange, because Classes are eternal, even an iPhone class existed right after the Big Bang, it just recently got members.

The example below is for revision 1 of above technical requirements specification.

With a Template

ex:455ca3c1-c625-4352-a5d7-0772e54c449a
      rdf:type tpl:ClassOfTemporalWholePartDefinition ;
      rdfs:label "KC01-71-990-KW-T-YP-0002-rev1" ;
      tpl:hasTemporalWhole ex:4a13f181-9ced-48ff-b04f-c99e1dfb9886 ; # KC01-71-990-KW-T-YP-0002
      tpl:hasTemporalPart ex:785fb9f9-7786-42d9-b942-2aebc6b4bb9d ;
      meta:valEffectiveDate "2022-11-03T09:39:00Z"^^xsd:dateTime .

With the TP+P Method:

ex:aa364f5b-5037-4f1a-b6b6-ff400752f195
    rdfs:label "KC01-71-990-KW-T-YP-0002-rev1";
    pred:coTemporalPartOf  ex:4a13f181-9ced-48ff-b04f-c99e1dfb9886 ; # KC01-71-990-KW-T-YP-0002
    meta:valEffectiveDate "2022-11-03T09:39:00Z"^^xsd:dateTime .

Declaring a NonActual PossibleIndividual with its two anchor Requirement Classes

When a NonActual PossibleIndividual is being declared it is highly recommended to do this together with declaring its anchor ClassOfFunctionalObject and its anchor ClassOfInanimatePhysicalObject. Note: This may also be done to other subtypes of PossibleIndividual, where a definition of a functional aspect is required Let's first have a look at the following graph:

The "anchors" are a fixed point of reference in an ever-changing design world, from being brought into existence (e.g. on an Equipment List or Instrument Index), via a more precisee generic classifiction, to various revisions of a defining data sheet. Apart from their declaration data there is no further information attibuted to an anchor (Think about what information applies to a human being from birth to death). All information is attributed to a temporal part (individuals) of class of temporal part (classes). So when when the pump casing is required to be made of 316SS, and later of Stainless steel minumum 13 CR, that is shown on twp different revisions of the data sheet, but is also information attributed to two diferent class of temporal parts of the applicable anchor instance of ClassOfInanimatePhysicalObject.
In rhis way we can create a complete audit trail, and always make information available in the context of the other information of that class of temporal part Class.

what to do with doubles and deprecations?