From Design To Reality

latest update: 2017-04-24    


This is a sequel to the topic "Functional Resource Model".

In this topic the relationships between a Requirements Class and a Product Class will be discussed.


The following model will be discussed.


This model can be covered with standard templates and, where the information is stable, instances of rdf:type or rdfs:subclassOf:

Where the model shows ClassOfArrangedIndividual that can in real life be a subtype thereof: ClassOfInanimatePhysicalObject, ClassOfOrganization, ClassOfPerson or even ClassOfOrganism (for 3D-printed organisms, although that will not happen soon).

Since it is important to fully grasp what this model intends to represent the explanantion below will be done by discussing each template separately.


This model may seem intimidating, but in fact it is a repetitive one. The top part, in brown color, has been discussed in the topic "Functional Resource Model".

Below this model will be explained in seven sections:


The following timeline is assumed for the various lifecycle activities and the entries in the lifecycle information. The dateTimes shown are used in the code examples.

Detailed Engineering

rev. 0 2014-11-10T00:00:00Z
rev. 1 2014-12-07T00:00:00Z
Plant Design (P&ID) 2014-11-15T00:00:00Z
Product Specifications PQR Inc. 2012-10-31T00:00:00Z
STR Inc. 2013-09-21T16:45:00Z
UVW Inc.


Product Quotation PQR Inc. 2015-01-14T14:42:00Z
STR Inc. 2015-01-12T15:50:00Z
UVW Inc. 2015-01-13-T16:15:00Z
Bid Evaluation & Procurement 2015-02-04T00:00:00Z
Manufacturing / Logistics 2015-03-19T00:00:00Z
Asset Management 2015-04-02T 11:23:00Z
Construction (Installation) 2015-04-18T12:10:00Z
Operations start P-101 2015-06-13T08:58:06Z
stop P-101 2015-09-26T23:42:39Z


The Requirements Side


Any thing that is or will be required shall be declared. In this example we declare the pump P-101 and its requirements class CO_P-101:

Represented in ISO 15926-8 code in Turtle:

:C33E1371D94EF4BCC948AC27FA9F49039 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS327239 ; # PUMP (select, for declarations, the least specialized class; will be specialized later)

      rdfs:label "CO_P-101" ;

      meta:valEffectiveDate "2014-11-10T00:00:00Z"^^xsd:dateTime .

:TF76578D8DDDC401DA90E00D24E25708C rdf:type dm:FunctionalPhysicalObject, dm:ArrangedIndividual, dm:WholeLifeIndividual,  :C33E1371D94EF4BCC948AC27FA9F49039 ; # Part 2 entity types and CO_P-101

      rdfs:label "P-101" ;

      meta:valEffectiveDate "2014-11-10T00:00:00Z"^^xsd:dateTime .

Creating temporal parts

For the Function Place Class one to many instances of the template ClassOfTemporalPartOfClassOfIndividual are created. The reason for that is that, where the Function Place Class is, by convention, immutable, it still is a Class and when the criteria for membership of a Class change we deal, in fact, with another Class. And that is not what we want. In the topic Life cycle of a Class the solution for this problem is explained.

In this case this template is used as follows:

Each red-lined object instance is defined by some technical specification in a revision, as outlined below.

In case the object is handling a Stream of some kind (fluid, signal, energy) then it possibly is also defined with a link to the information generated in the Functional Design phase (Process Design, Process Controls Design, Power Systems Design, etc).

If (and only IFF) the information changes such that the red-lined Class will have a different membership, then the next instance of this template shall be created and the existing one deprecated.

The code look like this:

# Initial instantiation

:T1F82C1E2795A474CB91A1F0A06538B96 rdf:type tpl:ClassOfTemporalPartOfClassOfIndividual ;

      tpl:hasClassOfWhole :C33E1371D94EF4BCC948AC27FA9F49039 ; # CO_P-101

      tpl:hasClassOfPart :CAA76ABD6B2F54CDF8456FE2A1C3F7CB7 ; # CO_P-101 rev.0

      meta:valEffectiveDate "2014-11-10T00:00:00Z"^^xsd:dateTime .

# then the definition of CO_P-101 rev. 0 changes to rev. 1

:CAA76ABD6B2F54CDF8456FE2A1C3F7CB7 meta:valDeprecationDate "2014-12-07T00:00:00Z"^^xsd:dateTime . # deprecation of CO_P-101 rev.0

# and as a consequence:

:T1F82C1E2795A474CB91A1F0A06538B96 meta:valDeprecationDate "2014-12-07T00:00:00Z"^^xsd:dateTime . # deprecation of template

# and a new template is instantiated:

:TDDBE7C6EA9164C8187CF3CD4B6323672 rdf:type tpl:ClassOfTemporalPartOfClassOfIndividual ;

      tpl:hasClassOfWhole :C33E1371D94EF4BCC948AC27FA9F49039 ; # CO_P-101

      tpl:hasClassOfPart :C8967C9C7587C4EAFB0E9BDDC532151E6 ; # CO_P-101 rev.1

      meta:valEffectiveDate "2014-12-07T00:00:00Z"^^xsd:dateTime .

Specialization of ClassOfArrangedIndividual with ParticipatingRoleAndDomain

If we look at the ClassOfInanimatePhysicalObject "PUMP", the question is how something that is an inanimate physical object becomes a pump. After all the members of ClassOfInanimatePhysicalObject are inanimate physical objects and nothing more. This is done by making it a specialization of the related instance of ParticipatingRoleAndDomain that is a specialization of the ClassOfFunctionalObject PUMPING FUNCTION and the Role of STREAM HANDLER. That PUMPING FUNCTION may be defined just with text, but it may also be "dressed up" with a transfer function, QH curves, etc. That makes a PUMP class of our inanimate physical object class.

Note that this template is only used when the applicable Functional Design is modeled and linked to the Detailed Engineering information.

The code for this template looks like this:

:TB1E85E01AD00473AAFCC6D7597FF3FB6 rdf:type tpl:SpecializationOfIndividual ;

      tpl:hasSubClass :CE2E3508888D44AB897B19A424FD79DD7 ; the ID of the applicable ParticipatingRoleAndDomain

      tpl:hasSuperClass :CAA76ABD6B2F54CDF8456FE2A1C3F7CB7 ; # CO_P-101 rev.0

      meta:valEffectiveDate "2014-11-10T00:00:00Z"^^xsd:dateTime .

# in case CO_P-101 goes to rev. 1, even for another reason (e.g. the technical specification changes revision):

:TB1E85E01AD00473AAFCC6D7597FF3FB6 meta:valDeprecationDate "2016-02-15T12:55:00Z"^^xsd:dateTime . # deprecation of above template

# and subsequently:

:T57C21A8F9D4140688E82C2BAEE301503 rdf:type tpl:SpecializationOfIndividual ;

      tpl:hasSubClass :CE2E3508888D44AB897B19A424FD79DD7 ; the ID of the applicable ParticipatingRoleAndDomain

      tpl:hasSuperClass :C8967C9C7587C4EAFB0E9BDDC532151E6 ; # CO_P-101 rev.1

      meta:valEffectiveDate "2014-12-07T00:00:00Z"^^xsd:dateTime .


Each class shall be defined. For Requirement Classes that is often done in technical specifications, for commodity items in standards published by governments or standardization bodies (e.g. ASME).

For, often one-off, specifications the most important part of their contents is, in addition, modeled with the document at the center (see for example the template RepresentationOfClassOfIndividualWithTemplateSet) and then refererence is made to that document via the above template. Note that a part of the template is not shown for space reasons (now represented with the shortcuts rdfs:subclassOf and rdf:type).

Next to the document ID (not the ducument number, but a GUID or UUID) reference shall be made to an RDL-listed ClassOfClassOfInformationRepresentation, defining the type of content, the natural language, and the representation form (here: Acryllic characters).

The code for this template looks like this:

:TA97144774BED48DCA30C66034ECBDB2A rdf:type tpl:DefinitionOfClassOfIndividualOnReferredDocument ;

      tpl:hasRepresented :C8967C9C7587C4EAFB0E9BDDC532151E6 ; # CO_P-101 rev.1

      tpl:hasRepresentationType rdl:RDS17986949 ; # API 610 PUMP DATA SHEET

      tpl:hasDocument :CA8A9653BF2D6481CA7151A5EBB865AEA ; #  Pump Data Sheet BN-5932 rev.1 (declared elsewhere)

      meta:valEffectiveDate "2014-12-07T00:00:00Z"^^xsd:dateTime .


The three above templates (plus others) define the Object Information Model of the Function Place Class at any time in history (which is everything, because one split second after entering something new it is in fact already history).


Plant Configuration

The Function Places (here one of them: P-101) are the objects with which Plant Design Systems and other CAD systems (e.g. for electrical schematics) work. This plant configuration involves composition, connections and, for 3D, location in a plant grid. Below an example of a connection is detailed:

This results in the following code:

:TB7FDF21C57934F0D9984051B86B38D8A rdf:type tpl:DirectConnectionOfTwoIndividuals ;

      tpl:hasSide1 :TF76578D8DDDC401DA90E00D24E25708C ; # P-101

      tpl:hasSide2 :T63FFBB4EE6C046CD9F980E08C590F1B7 ; # RZ-17801-h

      tpl:hasConnectionType rdl:RDS5983093 ; # FLANGED CONNECTION

      tpl:hasConnection :TB381DF78BD5D445EB5FDE1957587232D ; # input to template IndividualUsedInADirectConnection .

      meta:valEffectiveDate "2014-11-15T00:00:00Z"^^xsd:dateTime .


Streams are also involved in configurations, although this may be, for some software, are new development. You can't see them, but they play an important role, since they represent the "raison d'tre" of a plant. Most information that normally is attributed to a plant item (equipment, pipe, instrument) actually is stream information.

Streams are contained in those plant items and have a source and a destination. Below a Stream is declared and has, in this example, a Normal Flow of 15.7 m3/hr. Note that these stream data often have different values as compared with the corresponding stream data resulting from Process Design. This is because of rules and regulations, such as a rule that a 10% overcapacity must be taken into account.

:T6876820124A44E6B83A985041395342C rdf:type dm:Stream, dm:WholeLifeIndividual ;

      rdfs:label "P-101-S" ; # Stream through P-101

      meta:valEffectiveDate "2014-11-15T00:00:00Z"^^xsd:dateTime .

:T9D3C164A1FBC45CEBD81FCE03CE2AF93 rdf:type tpl:ContainmentOfAnIndividual ;

      tpl:hasContainer :TF76578D8DDDC401DA90E00D24E25708C ; # P-101

      tpl:hasContained :T6876820124A44E6B83A985041395342C ; # P-101-S

      meta:valEffectiveDate "2014-11-15T00:00:00Z"^^xsd:dateTime .

:T6876820124A44E6B83A985041395342C rdf:type tpl:IndividualHasIndirectPropertyWithValue ;

      tpl:hasPossessor :T6876820124A44E6B83A985041395342C ; # P-101-S

      tpl:hasIndirectPropertyType rdl:RDS7354451 ; # NORMAL VOLUME FLOW RATE

      tpl:valPropertyValue "15.7"^^xsd:decimal ;

      tpl:hasScale rdl:RDS1321064 ; # CUBIC METRE PER HOUR

      meta:valEffectiveDate "2014-11-15T00:00:00Z"^^xsd:dateTime .

Having done all this coding it should be noted that these stream data normally have already been defined for the Requirements Class CO_P-101 at Class level and since P-101 is a member it complies with the criteria for membership of CO_P-101 and hence the stream data of the latter apply.

The Product Side

At the Product Side, i.e. the products that are offered by suppliers or, for spare items in the warehouse, have been offered by suppliers in the past, the product design phase is not included in the model.

Product Model

We model the Product Classes with their options and versions. (Admin Note: that topic will be refreshed soon)

The Product Model and each member MaterializedPhysicalObject will have to be declared as we did above for the Function Place (Class). Let us first assume that the object "Detailed Product Model" does not exist, because the Product Model has no options and/or versions. Further assume we model a Product Model with the label HX-365-z supplied by ACME Ltd.

:C7EC0E3DD64F54D5DA3525A2B93E2D383 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS16765074 ; # AXIAL FLOW PUMP (select in this case what it is, because this is an end product)

      rdfs:label "HX-365-z" ;

      meta:valEffectiveDate "1995-04-13T00:00:00Z"^^xsd:dateTime .

When the Product Model has options and versions, the modeling is a bit more laborious, but not overly complex. Let us assume that Model HX-365-z has (to keep it simple) three sizes: 4", 6" and 10" and two materials of construction 316SS and 316SSL. That would give the following model:


For the green objects the code is given below. For the sizes the template ClassOfIndividualHasIndirectPropertyWithValue and for the material the template SpecializationByCompoundType :


:C8C1B20B2E407427BBC18B8AF86D6C3B0 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS16765074 ; # AXIAL FLOW PUMP (select in this case what it is, because this is an end product)

      rdfs:label "HX-365-z v0" ;

      meta:valEffectiveDate "1995-04-13T00:00:00Z"^^xsd:dateTime .

:C4FDA06A8F34749DA8C3A00C9AC19C334 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C8C1B20B2E407427BBC18B8AF86D6C3B0 ; # HX-365-z v0

      rdfs:label "HX-365-z v1" ;

      meta:valEffectiveDate "2000-02-10T00:00:00Z"^^xsd:dateTime .

:CB74A04002F4344F79306FC09EF44F95D rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C8C1B20B2E407427BBC18B8AF86D6C3B0 ; # HX-365-z v0

      rdfs:label "HX-365-z v2" ;

      meta:valEffectiveDate "2007-02-06T00:00:00Z"^^xsd:dateTime .

:CA0BF0F0174B6422D82CF0F5060E9B6E1 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C8C1B20B2E407427BBC18B8AF86D6C3B0 ; # HX-365-z v0

      rdfs:label "HX-365-z v3" ;

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:C35D844235D6840B2B9995A1A512A4774 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :CA0BF0F0174B6422D82CF0F5060E9B6E1 ; # HX-365-z v3

      rdfs:label "HX-365-z v3 size 6inch" ;

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:CB7C5BA660DAE40F7966C6BDDD6777F76 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :CA0BF0F0174B6422D82CF0F5060E9B6E1 ; # HX-365-z v3

      rdfs:label "HX-365-z v3 in 316SSL" ;

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:C19F0C7F93AF54E3C952F3074D7727A4B rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C35D844235D6840B2B9995A1A512A4774 , :CB7C5BA660DAE40F7966C6BDDD6777F76  ; # HX-365-z v3 size 6inch & HX-365-z v3 in 316SSL

      rdfs:label "HX-365-z v3, 6inch, in 316SSL" ;


:T058E0DCC16B441DD8ED96D15AC4B9BC4 rdf:type tpl:ClassOfIndividualHasIndirectPropertyWithValue ;

      tpl:hasPossessorType :C35D844235D6840B2B9995A1A512A4774 ; # HX-365-z v3 size 6inch

      tpl:hasIndirectPropertyType rdl:RDS366794 ; # NOMINAL DIAMETER

      tpl:valPropertyValue "6"^^xsd:decimal ;

      tpl:hasScale rdl:RDS1326959 ; # INCH

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:T5B7745B57BA34CD4BF5BA55070437945 rdf:type tpl:SpecializationByCompoundType ;

      tpl:hasSubClass :CB7C5BA660DAE40F7966C6BDDD6777F76 ; # HX-365-z v3 in 316SSL

      tpl:hasSuperClass rdl:RDS12837115 ; # AISI 316L

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

Product Specification

For the Product Specification the same approach as for the Technical Specification can be used. The information content will be different. The code could look like this:

:T70E2DD9B34BB44B08D6779466B16D955 rdf:type tpl:DefinitionOfClassOfIndividualOnReferredDocument ;

      tpl:hasRepresented :CA0BF0F0174B6422D82CF0F5060E9B6E1 ; # Model HX-365-z v3

      tpl:hasRepresentationType :R39854 ; # ACME Ltd Product Specification

      tpl:hasDocument :C0FF05C7B7851432CB6D32E425566C14F ; #  Product Specification for ACME Model HX-365-z v3 (declared elsewhere)

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

Intended Use of Product

Using the template ClassOfIntendedRoleAndDomainDefinition information about the functionality (purpose) of a product can be recorded (see dark green part in above diagram):

:TD2C22CD9CA1D46A183BE6452C820A14C rdf:type tpl:ClassOfIntendedRoleAndDomaonDefinition ;

      tpl:hasClassOfPlayer :C8C1B20B2E407427BBC18B8AF86D6C3B0 ; # HX-365-z v0

      tpl:hasPlayed rdl:RDS598302 ; # PUMPING FUNCTION & STREAM HANDLER (fake ID)

      tpl:hasCardinalityOfPlayer rdl:RDS3984398 ; # ONE TO ONE

      tpl:hasCardinalityOfPlayed rdl:RDS3984398 ; # ONE TO ONE

      meta:valEffectiveDate "1995-04-13T00:00:00Z"^^xsd:dateTime .


Assume that an RFQ (Request For Quotation) has been sent to three potential suppliers. The Technical Specification, defining the "criteria for membership" of CO_P-101, is part of this RFQ.

Assume that all three potential suppliers sent their quotations:

  1. PQR Inc. offering their model A;
  2. RST Inc. offering their model B;
  3. UVW Inc. offering their model C (NOTE The code shown above applies here).

The quotation of PQR Inc. was rejected for some reason, the other to bids were technically compliant with the requirements for CO_P-101. Finally Model C of the UVW Inc. was accepted, the order placed. The pump, having its serial number arrived and its information entered in the Asset Management System. There its temporal part got its Asset Number.

This story is represented with the following graph:

Obviuosly the red and green objects are just placehoders for the actual bid information. The Model B, offered by the RST Inc. could remain "in portfolio" for later use, if so required. The instance of MaterializedPhysicalObject with its Asset Number can be installed, see next chapter.

The code for above graph is:

In the data store of the PQR Inc. (namespace pqr: )

:C6C365A449DD643DE8D05CCBFAEE44C7E rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS16765074 ; # AXIAL FLOW PUMP (select in this case what it is, because this is an end product)

      rdfs:label "Model A" ;

      meta:valEffectiveDate "2012-10-31T00:00:00Z"^^xsd:dateTime .

:C13D271EDB42F4B74A0A9FCB95D88DCBC rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C6C365A449DD643DE8D05CCBFAEE44C7E ; # Model A

      rdfs:label "Detailed Model A" ; # Defines selected options

      meta:valEffectiveDate "2012-10-31T00:00:00Z"^^xsd:dateTime .

:T538B13319B134414A2EC69586F510018 rdf:type tpl:ClassOfTemporalPartOfClassOfIndividual ;

      tpl:hasClassOfWhole :C13D271EDB42F4B74A0A9FCB95D88DCBC; # Detailed Model A

      tpl:hasClassOfPart :CCC06626073154433961A709BB016C4A6 ; # Offered Detailed Model A (with price)

      meta:valEffectiveDate "2015-01-14T14:42:00Z"^^xsd:dateTime .

In the data store of the STR Inc. (namespace str: )

:C34797E45152F4BE6A1B175E53CC2FC59 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS16765074 ; # AXIAL FLOW PUMP (select in this case what it is, because this is an end product)

      rdfs:label "Model B" ;

      meta:valEffectiveDate "2013-09-21T16:45:00Z"^^xsd:dateTime .

:CB4427CB723A94115AAB7FA387FA7320E rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :C34797E45152F4BE6A1B175E53CC2FC59 ; # Model B

      rdfs:label "Detailed Model B" ; # Defines selected options

      meta:valEffectiveDate "2013-09-21T16:45:00Z"^^xsd:dateTime .

:T01B1BC394F5343D092F3A7B8F42AF757 rdf:type tpl:ClassOfTemporalPartOfClassOfIndividual ;

      tpl:hasClassOfWhole :CB4427CB723A94115AAB7FA387FA7320E ; # Detailed Model B

      tpl:hasClassOfPart :CAAD0B4531C024474840007AC415C4450 ; # Offered Detailed Model B (with price)

      meta:valEffectiveDate "2015-01-12T15:50:00Z"^^xsd:dateTime .

In the data store of the UVW Inc. (namespace uvw: )

:CA0BF0F0174B6422D82CF0F5060E9B6E1 rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf rdl:RDS16765074 ; # AXIAL FLOW PUMP (select in this case what it is, because this is an end product)

      rdfs:label "HX-365-z v3" ;

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:CC148DA6A29944D3ABB791ED44CB50A8A rdf:type dm:ClassOfInanimatePhysicalObject ;

      rdfs:subclassOf :CA0BF0F0174B6422D82CF0F5060E9B6E1 ; # Model HX-365-z v3

      rdfs:label "HX-365-z v3, 6inch, in 316SSL" ;# Detailed Model HX-365-z v3, defines selected options

      meta:valEffectiveDate "2014-07-13T00:00:00Z"^^xsd:dateTime .

:TF9D50939155B4A58BF27C145A5AF4B39 rdf:type tpl:ClassOfTemporalPartOfClassOfIndividual ;

      tpl:hasClassOfWhole :CC148DA6A29944D3ABB791ED44CB50A8A ; # Detailed Model HX-365-z v3

      tpl:hasClassOfPart :CAB69B76E8C9B42698BDF777C66F37ED5 ; # Offered Detailed Model HX-365-z v3 (with price)

      meta:valEffectiveDate "2015-01-13-T16:15:00Z"^^xsd:dateTime .

Bid Evaluation results

:TB2E6B4D107CD4856BFDA6CA4C1E42E07 rdf:type tpl:ClassOfIndividualHasStatus ;

      tpl:hasPossessorType :CCC06626073154433961A709BB016C4A6 ; # the offer by PQR Inc

      tpl:hasStatus xyzrdl:R589300 ; # in local RDL extension: REJECTED

      meta:valEffectiveDate "2015-02-04T00:00:00Z"^^xsd:dateTime .

:TEB2387C9CE4C426F86DABA9A0F1A4209 rdf:type tpl:ClassOfIndividualHasStatus ;

      tpl:hasPossessorType :CAAD0B4531C024474840007AC415C4450 ; # the offer by STR Inc

      tpl:hasStatus xyzrdl:R589301 ; # in local RDL extension: ACCEPTED BUT NOT SELECTED

      meta:valEffectiveDate "2015-02-04T00:00:00Z"^^xsd:dateTime .

:TE20DD3C7547C4166BDA186FD04F5D9AE rdf:type tpl:ProductClassFulfilsClassOfFunctionPlace ;

      tpl:hasFunctionPlaceClass :C8967C9C7587C4EAFB0E9BDDC532151E6 ; # CO_P-101 rev.1

      tpl:hasProductClass :CAAD0B4531C024474840007AC415C4450 ; # Detailed Model B (with price) as offered by STR Inc.

      tpl:hasClassOfFulfilled :C04B3FFFFF08749B684DCEDB300FE9F0C ; # not purchased, kept in portfolio

      meta:valEffectiveDate "2015-02-04T00:00:00Z"^^xsd:dateTime .

:T85D72DB240A54395B8B8EC505EB58954 rdf:type tpl:ClassOfIndividualHasStatus ;

      tpl:hasPossessorType :CAB69B76E8C9B42698BDF777C66F37ED5 ; # the offer by UVW Inc

      tpl:hasStatus xyzrdl:R589302 ; # in local RDL extension: ACCEPTED AND SELECTED

      meta:valEffectiveDate "2015-02-04T00:00:00Z"^^xsd:dateTime .

:T4499BC39A1264BD189BB8C6964FB594B rdf:type tpl:ProductClassFulfilsClassOfFunctionPlace ;

      tpl:hasFunctionPlaceClass :C8967C9C7587C4EAFB0E9BDDC532151E6 ; # CO_P-101 rev.1

      tpl:hasProductClass :AB69B76E8C9B42698BDF777C66F37ED5 ; # Detailed Model HX-365-z v3 (with price) as offered by UVW Inc.

      tpl:hasClassOfFulfilled :CBC6A623031CC4121A6115A2E46455453 ; # one member will be purchased

      meta:valEffectiveDate "2015-02-04T00:00:00Z"^^xsd:dateTime .


After placing the order with the UVW Inc. it arrives with, amongst others, the following information:

uvw:TDBB60BB12A4048A7A87CA0DA5DC18B07 rdf:type dm:MaterializedPhysicalObject,



                                               dm;WholeLifeIndividual ,

                                               uvw:C19F0C7F93AF54E3C952F3074D7727A4B ; # Part 2 entity types and "HX-365-z v3, 6inch, in 316SSL"

      rdfs:label "5PB1643703" ; # the Serial Number

      meta:valEffectiveDate "2015-03-19T00:00:00Z"^^xsd:dateTime .

Asset Management

:T5861482AEA154668B28E31A642B7ADEF rdf:type tpl:BeginningOfTemporalPart ;

      tpl:hasTemporalWhole uvw:TDBB60BB12A4048A7A87CA0DA5DC18B07 ; # Product instance withSerial Number 5PB1643703

      tpl:hasTemporalPart :TE199C43B22E645D18F2E3784036A7708 ; # Asset Number AN439823

      meta:valEffectiveDate "2015-09-25T00:00:00Z"^^xsd:dateTime .


Now is the time that we install the newly acquired (or acquired at a much earlier date and stored in the warehouse) MaterializedPhysicalObject, with its Asset Number, in the Function Place P-101 rev. 1:


The TemporalWholePart relationship is transitive, which means that what applies to the whole also applies to the part. So the installed PhysicalObject inherits all information from P-101 rev.1 (i.e. that it is a member of the Requirements Class CO_P-101 rev. with all its information) and, via the MaterializedPhysicalObject with Asset Number, from the one with Serial Number, that is a member of the Detailed Product Model.

The code for above graph is:

:T83B5F29E91E742A0A06B1E487D815192 rdf:type tpl:BeginningOfTemporalPart ;

      tpl:hasTemporalWhole :TF76578D8DDDC401DA90E00D24E25708C ; # P-101

      tpl:hasTemporalPart :T3C5E98DEBC004E498CCACECFD799249F ; # P-101 rev.1

      meta:valEffectiveDate "2015-04-18T12:10:00Z"^^xsd:dateTime .

:T3C5E98DEBC004E498CCACECFD799249F rdf:type C8967C9C7587C4EAFB0E9BDDC532151E6 ; # newly created P-101 rev.1 is a CO_P-101 rev.1

      meta:valEffectiveDate "2015-04-18T12:10:00Z"^^xsd:dateTime .

:TEB255B6C7D794BA990A019164CACE54D rdf:type tpl:ProductInstalledInFunctionPlace ;

      tpl:hasFunctionPlace :T3C5E98DEBC004E498CCACECFD799249F ; # Function Place P-101 rev.1

      tpl:hasProduct :TE199C43B22E645D18F2E3784036A7708 ; # PhysicalObject with Asset Number AN439823

      tpl:hasInstalled :T275FA193A4394BEA93060195892DE90A ; # Installed PhysicalObject (ID generated here, will be used below)

      meta:valEffectiveDate "2015-04-18T12:10:00Z"^^xsd:dateTime .

NOTE - The declaration of P-101 rev.1 is, according ISO 15926-8, not really necessary, because the TemporalWholePart relationship inside the template BeginningOfTemporalPart is transitive. But for SPARQL queries this direct rdf:typing has advantages. This declaration shall automatically follow the declaration of the instance of the template BeginningOfTemporalPart.


The installed PhysicalObject participates in an individual Activity:

The code for this is:

# The pump is started (= the activity begins)

:T88BD51075EAB41C8B738E6568D36E296 rdf:type dm:Activity, dm:ActualIndividual, dm:ArrangedIndividual, dm:WholeLifeIndividual, rdl:RDS9657917 ; # PUMPING

      rdfs:label "ACT-P-101-20150926-2" ;

      meta:valEffectiveDate "2015-06-13T08:58:06Z"^^xsd:dateTime .

# The pump is stopped again (= the activity is stopped)

:T88BD51075EAB41C8B738E6568D36E296 meta:valDeprecationDate "2015-09-26T23:42:39Z"^^xsd:dateTime .

:TEA74724391704E7286D5F96E09BDC9AA rdf:type tpl:ParticipationOfIndividualInActivity ;

      tpl:hasActivity :T88BD51075EAB41C8B738E6568D36E296 ;

      tpl:hasParticipant :T275FA193A4394BEA93060195892DE90A ; # the installed PhysicalObject

      tpl:hasParticipantType :CBC817C0C82974E10BAF047419C6E611E ; # the ClassOfParticipation in previous Topic Functional Resource Model *)

      meta:valEffectiveDate "2015-09-25T00:00:00Z"^^xsd:dateTime .

*) or a standard instance of ClassOfParticipation in the RDL in case there is no Process Design information.

In an identical way the same Activity can be participated in by a Stream or Inlet Stream + Outlet Stream (see Streams and ports), and when required the shift, any events, etc.


As long as object are externally accessible they can be surrounded by all sorts of templates that represent information about them. A full list of standard templates can be found at .

The model discussed in this topic is to be seen as a backbone model that ties the various lifecycle stages together. Also see the topic Plant Lifecycle Model that is in essence the same model, be it that it gives more information and also addresses Maintenance.