Declaring a Tag, a Stream, and a Commodity Product

latest update 2023-08-28  

Introduction

Referring to the topic Plant Life-cycle Model this topic here defines how a Tag, a Stream, and a Commodity Item can be declared, each different and in one blow by a standard piece of modeling.

Declaring a Tag

Tags are plant items and parts thereof, that get a tag number to uniquely identify it in the context of a plant. The question which parts qualify as 'tag' can only be answered by stating that a tagged item is necessary in case information is specific for that item and shall be recorded. If so, they need to be sub-tagged, e.g. B14-P101-IMP2 for the second impeller of two-stage centrifugal pump B14-P101

Tags exist in a non-actual design & engineering world, as opposed to the actual world around us. See also the topic
Possible Worlds

A Tag is often referred to as 'Functional Location'. The function of pump P101 fully depends on its location in a P&ID. If it is no longer required on that location in the P&ID topology, it ceases to exist.

A Tag can be (and usually is) implemented by an actual PhysicalObject in the real world, that has been installed in the actual Functional Location in the plant.

For a Tag certain functional and physical requirements shall be defined, in order to be able to purchase an actual PhysicalObject that fulfils these requirements.

The diagram

Let's have a look at a marked-up detail of the LSN, in which we see which items shall be declared. The standard code for that is given below.

Explanation

Before going into detail it the concept of 'anchor' must be explained. In ISO 15926 terms an individual anchor cannot have, ever, a temporal whole. Anchors only get the information that 100% certain will always be attributed to it. In practice that is almost zero.

The items that are to be declared together are:

The ClassOfFunctionalObject [43] is about, as the name suggests, functional information, for the most Stream information, but also information that influences proper functioning, such as site data (e.g. explosion hazard, available utilities, elevation, meteorological data, etc.).

The ClassOfInanimatePhysicalObject [50] is a subClassOf the above ClassOfFunctionalObject [40]. This means that the functional information is inherited by that ClassOfInanimatePhysicalObject. In practice we can see that on a specification/datasheet, where that specification not only defines the physical requirements, but also has a section about the stream that is supposed to be handled and a section with site data.

Documentation

The ClasOfFunctionalObject [40] is being represented on a Process Data Sheet [42], or the data from such a datasheet are mapped and uploaded to the Class. The way this is done is a matter of work process and related software. The ClassOfInanimatePhysicalObject [50] has a similar relation to a Technical Specification [52].

Code for declaration of a Tag

The typical code for this declaration is shown for pump B14-P101, its inlet and outlet port, and its casing:

####################################################################################
#
#  DECLARATION OF ANCHOR OF PUMP B14_P101 AND ITS REQUIREMENT CLASSES
#  Always declared together
#
####################################################################################

ex:2bfa83ae-19da-4135-9d30-ca606a1e8afa  rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, 
	lci:NonActualIndividual, ex:4d515eb6-0cea-4431-b26c-0b27bdfbe9a7 , ex:be6becd6-f599-4927-b913-74f3fc64d777 ; 
    rdfs:label "B14-P101" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . 

ex:4d515eb6-0cea-4431-b26c-0b27bdfbe9a7
    rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS
    rdfs:subClassOf  rdl:RDS414081061   ; # PUMP SYSTEM
    rdfs:label "CO_B14-P101-FO" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:be6becd6-f599-4927-b913-74f3fc64d777
    rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS
    rdfs:subClassOf  rdl:RDS414081061   ; # PUMP SYSTEM
    rdfs:label "CO_B14-P101" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

########################################################################################
#
#  DECLARATION OF B14_P101 BODY AND PROCESS NOZZLES AND THEIR REQUIREMENT CLASSES
#
########################################################################################

###### ANCHOR INLET NOZZLE AND CLASSES ######

ex:a3b5c4d8-63fc-45d1-b251-10d7af8e8ae6
    rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, 
	ex:2056a7df-281a-468b-806e-a19eeee6daa0, ex:7903d449-f284-44ea-93e9-0c45d2b52815  ;
    rdfs:label "B14-P101-IN" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . 

ex:2056a7df-281a-468b-806e-a19eeee6daa0
    rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS FOR INLET NOZZLE
    rdfs:subClassOf  rdl:RDS2195131601 ; # LIQUID INLET PORT
    rdfs:label "CO_B14-P101-IN-FO" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:7903d449-f284-44ea-93e9-0c45d2b52815
    rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS FOR INLET NOZZLE
    rdfs:subClassOf  rdl:RDS2195131601 ; # LIQUID INLET PORT
    rdfs:label "CO_B14-P101-IN" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

###### ANCHOR PUMP CASING INDIVIDUAL AND CLASSES ######

ex:89911063-3579-44c2-945c-3f06feeb544d
    rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, 
	ex:e3587ee8-3e98-44c3-b42c-f152fd719ac3, ex:1c6ae6e5-8e1c-487b-b70e-7695117b1aef  ;
    rdfs:label "B14-P101-CASE" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . 

ex:e3587ee8-3e98-44c3-b42c-f152fd719ac3
    rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS FOR PUMP CASING
    rdfs:subClassOf  rdl:RDS461204 ; # PUMP CASING
    rdfs:label "CO_B14-P101-CASE-FO" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:1c6ae6e5-8e1c-487b-b70e-7695117b1aef
    rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS FOR PUMP CASING
    rdfs:subClassOf  rdl:RDS461204 ; # PUMP CASING
    rdfs:label "CO_B14-P101-CASE" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

###### ANCHOR OUTLET NOZZLE AND CLASSES ######

ex:fb7d4bb2-c68a-4715-ac37-1869bd4128cf
    rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, 
	ex:d30fd6da-ccec-4515-9b66-118c8ea274e0  ; 
    rdfs:label "B14-P101-OUT" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . 

ex:6fbe3e97-6b49-44d5-bc58-a875f001233c
    rdf:type dm:ClassOfFunctionalObject ; # ANCHOR FUNCTIONAL REQUIREMENTS CLASS FOR OUTLET NOZZLE
    rdfs:subClassOf  rdl:RDS2195143051 ; # LIQUID OUTLET PORT
    rdfs:label "CO_B14-P101-OUT-FO" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:d30fd6da-ccec-4515-9b66-118c8ea274e0
    rdf:type dm:ClassOfInanimatePhysicalObject ; # ANCHOR ASSET REQUIREMENTS CLASS FOR OUTLET NOZZLE
    rdfs:subClassOf  rdl:RDS2195143051 ; # LIQUID OUTLET PORT
    rdfs:label "CO_B14-P101-OUT" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

Why class of temporal part?

The concept of temporal parts is explained here. Here they are being used as shown in the diagram below.

Note that the 'co' in 'coTemporalPartOf' stands for 'classOf', distinguishing it from temporalPartOf between instances of PossibleIndividual. This relation is to be implemented with the template ClassOfTemporalWholePartDefinition. It is deprecated when the next version has become effective, by adding the triple ex:uuid meta:valDeprecationDate "yyyy-mm-ddThh-mm-ssZ"^^xsd:dateTime .

This construct can be used as well for other Classes, predominantly for a ClassOfInformationObject (document) with revisions.
The reader is invited to think about the possibilities to capture the dynamics of, for example, a new revision in a Process Data Sheet that has not yet been causing a new revision of a Technical Specification for some time, and the consequences thereof. Anyway, situations like that can be captured and recorded.


Declaring a Stream

Normally Stream data are part of the data attributed to ClassOfFunctionalObject [40], where they are representing the functional requirement of being able to handle that Stream wiithin those limits. And normally there are no physical requirements related to Streams. So we have a hard-coded anchor ClassOfStream, of which ClassOfFunctionalObject [40] is a coTemporalPartOf.

The model of the Stream declaration is shown below.

Explanation

Stream [35] is contained in the Tag [36]. That Stream is typed with its ClassOfStream [41], where the latter has earlier-declared ClassOfFunctionalObject [43] as subclass. At first sight that may be incorrect modeling, but keep in mind that semantically this means that members of [43] shall be capable of handling members of that Stream class with those data.

Starting at the anchor Tag all information about the contained Stream, from Process Design (if available) and the design case defined by the Process Engineer, can be accessed even before a start has been made with specifying the Asset Requirements Class.

Code for declaration of a Stream

The typical code for this declaration is shown for stream B14-S-P101 flowing through pump B14-P101, with three stream segments in the inlet, the casing, and in the outlet:

#############################################
#
#  DECLARATION OF STREAMS AND STREAM CLASSES 
#
############################################# 

##### Declaration and definition of Stream B14-S-P101 #####

ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, 
	ex:ff7abb4e-1267-428d-a8a2-5b77b645b78b ; # ANCHOR STREAM
    rdfs:label "B14-S-P101" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:ff7abb4e-1267-428d-a8a2-5b77b645b78b
    rdf:type lci:ClassOfStream ;
    rdfs:subClassOf rdl:RDS2227031  ;  # LIQUID STREAM
    rdfs:label "CO_B14-S-P101" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:101d7314-6660-4e09-8e5e-ed0524ade1ce
    rdf:type tpl:ContainmentOfAnIndividual ; # B14-S-P101 is contained in B14-P101
    tpl:hasContainer ex:2bfa83ae-19da-4135-9d30-ca606a1e8afa; # B14-P101
    tpl:hasContained ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ; # B14-S-P101 ; 
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

##### Declaration and definition of stream segment at inlet B14-S-P101-IN #####

ex:360f7494-d12b-47aa-b770-482b9a8c7d07 rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, 
	ex:17bf66e6-efc3-4193-8607-f2a62d10dbb6 ;
    rdfs:label "B14-S-P101-IN" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:17bf66e6-efc3-4193-8607-f2a62d10dbb6 
    rdf:type rdl:RDS2229972 ; # STREAM SEGMENT
    rdfs:subClassOf  rdl:RDS2227031  ;  # LIQUID STREAM
    rdfs:label "CO_B14-S-P101-IN" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:26bf6322-a7d6-4240-ad5f-c7a776c0f406
      rdf:type tpl:CompositionOfAnIndividual ;
      tpl:hasWhole  ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ; # B14-S-P101
      tpl:hasPart  ex:360f7494-d12b-47aa-b770-482b9a8c7d07 ; # B14-S-P101-IN ; 
      meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:eedff784-09ca-4380-a3bd-e58f9f95ba09
    rdf:type tpl:ContainmentOfAnIndividual ;
    tpl:hasContainer ex:a3b5c4d8-63fc-45d1-b251-10d7af8e8ae6 ; # B14-P101-IN
    tpl:hasContained ex:360f7494-d12b-47aa-b770-482b9a8c7d07 ; # B14-S-P101-IN
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

##### Declaration and definition of stream segment at outlet B14-S-P101-OUT #####

ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:fd5b1537-8b3a-490c-970e-ab69f7fa14ae ;
    rdfs:label "B14-S-P101-OUT" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:fd5b1537-8b3a-490c-970e-ab69f7fa14ae  
    rdf:type rdl:RDS2229972 ; # STREAM SEGMENT
    rdfs:subClassOf rdl:RDS2227031  ;  # LIQUID STREAM
    rdfs:label "CO_B14-S-P101-OUT" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:a8819d44-1b2f-4f15-b85b-88974a1fbc27
      rdf:type tpl:CompositionOfAnIndividual ;
      tpl:hasWhole  ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ;  # B14-S-P101
      tpl:hasPart  ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 ;  # B14-S-P101-OUT
      meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:c752b426-d6e5-49bd-be11-435b21d9fd35
    rdf:type tpl:ContainmentOfAnIndividual ;
    tpl:hasContainer ex:fb7d4bb2-c68a-4715-ac37-1869bd4128cf ; # B14-P101-OUT 
    tpl:hasContained ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 ; # B14-S-P101-OUT
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .


Declaring a Commodity Product

A Commodity Product ('CP') is defined as: "A product is a commodity when all units of production are identical, regardless of who produces them."
We must be careful not to decide too hastily that something is a CP. For example, in an RDL is stated that a 24-PAIR CABLE is a CP, but that is not true in all cases. First of all through cables and pipes we transport electrical energy and fluids, and they are an integral part of the plant topology, and hence shall be categorized as tagged items.
It may become a CP when we add up the requirements in terms of counts (fittings) or lengths (pipes, tubes, cables).

The model of the Commodity Product declaration is shown below.

Explanation

Best is to enter all CPs for a project in the Project RDL Extension. The Requirements Class is a specialization of that RDL Class in that a certain quantity is listed as a requirement. That quantity can be calculated from the Requirements Classes of the tagged quasi-CPs (the dotted lines and nodes). Since presumably no functional information is required, only the asset requirements are taken into account

Code for declaration of a Quasi CP

The typical code for this declaration is shown for cable B14-ES463 :

############################################################################
#
#  DECLARATION OF ANCHOR OF CABLE B14_ES463 AND ITS ASSET REQUIREMENT CLASS
#
############################################################################

ex:fbbc18f9-c99f-4f12-a8a5-8d5bfccdfc99  rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, 
	lci:NonActualIndividual, rdl:RDS2220117  ;  # SIGNAL CABLE
    rdfs:label "B14-ES463" ;
    meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . 

ex:4511c8c9-7c69-437c-b057-015d8c7c5318
      rdf:type tpl:ClassificationOfIndividual ;
      tpl:hasClassified ex:fbbc18f9-c99f-4f12-a8a5-8d5bfccdfc99 ;
      tpl:hasClassifier ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33 ;
      meta:valEffectiveDate "yyyy-mm-ddThh:mm:ss.sZ"^^xsd:dateTime .

ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33
      rdf:type dm:ClassOfInanimatePhysicalObject ; 
      rdfs:subClassOf  rdl:RDS2220117  ;  # SIGNAL CABLE
      rdfs:label "CO_B14-ES463" ;
      meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:f0265d91-1016-482b-8d68-8c35f069e8d8
      rdf:type tpl:ClassOfTemporalWholePartDefinition ;
      tpl:hasClassOfTemporalWhole ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33 ; # CO_B14-ES463
      tpl:hasClassOfTemporalPart ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b ;
      meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .

ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b
      rdf:type dm:ClassOfInanimatePhysicalObject ;  # Requirements Class
      rdfs:subClassOf  exrdl:R68833 ; # the project standard Class for 24-pair signal cable
      rdfs:label "CO_B14-ES463-rev0" ;
      meta:valEffectiveDate "2022-06-17T14:23:00Z"^^xsd:dateTime .

###### LATER:

ex:8d4a1eb8-23aa-4d88-a966-4e11b2e4717c
      rdf:type tpl:ClassOfIndividualHasPropertyWithValue ;
      tpl:hasPossessorType ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b ;   
      tpl:hasPropertyType rdl:RDS373094  ; # LENGTH
      tpl:valPropertyValue "96"^^xsd:decimal ;
      tpl:hasScale rdl:RDS1332674 ;  # METRE