latest update: 2017-10-19    



All things, that are involved in any information, shall first be declared and identified as "Ur" objects (see The idea can be explained using a Requirements Class for pump P-101 as an example.

We start with declaring the Requirements Class for pump P-101 with an instance of ClassOfInanimatePhysicalObject that is a subClassOf the instance of ClassOfFunctionalObject PUMP, and identifying it with "CO-P-101". This Class will be relevant in our context until it is deprecated, and it will not have any information attributed to it other than through its class-of-temporal-parts. It can be qualified as an immutable "anchor".  The identifier may, at a later time, be changed, although this is an exception. The procedure for that is described here [later].

NOTE - The fact that this anchor class is made a variable in all templates in which actually one of its class-of-temporal-parts plays a role is because those class-of-temporal-parts are being hidden in the internals of the templates. The reason for that is that commercial software doesn't know of temporal parts. These temporal parts can only be made explicit by means of a "lifted" template, as defined in Part 12.

In case the Ur Class is deprecated, all its class-of-temporal-parts are deprecated (in case this wasn't already the case) and hence all templates in which these deprecated class-of-temporal-parts play a role are being deprecated (in case this wasn't already the case).

All objects, including the Ur objects, shall have an immutable ID that always stays with that object. It is advisable to use GUIDs for that, because these are globally unique, with a neglecible chance of duplication, even more so because they are used inside a, guaranteed unique, namespace.

There are many flavors of UUID/GUID. A GUID without hyphens has an advantage of being accepted as bookmark in HTML applications.

The GUID can easily be fetched with a simple SPARQL ASK query using an identifier as search criterium and hence doesn't have to be stored in the source system.  NOTE - In the above example the tag of the Requirements Class was CO_P-101. It is also possible to use P-101, but then this SPARQL ASK query must include the Part 2 entity type.

The "Declaration Class" is important and shall be selected carefully. It is the class of which P-101 is a member. It is the class that is ALWAYS valid as long as P-101 hasn't been deprecated. If the Declaration Class "PUMP" is changed P-101 is no longer valid and all information is frozen. So use PUMP and not CENTRIFUGAL PUMP, because it may change to POSITIVE DISPLACEMENT PUMP. Granted, it isn't likely to happen, but better safe than sorry. Later the classification with CENTRIFUGAL PUMP can be done with a template which can, when necessary, be deprecated and changed to POSITIVE DISPLACEMENT PUMP with a new template. The anchor remains PUMP then.

In the RDL (Reference Data Library) a set of generic identification types has been defined as instances of ClassOfFunctionalObject.




Role No

Role Variable

Description of Variable

Example of value



ISO 15926-2 entity type of the declared ClassOfIndividual




"Declaration Class" that represents the function (not the role) of the ClassOfIndividual




Unique identifier of the ClassOfIndividual that is being declared




The effectivity xsd:dateTime of the information represented here



For Role1 refer to or create a local subset.

For Role2 refer to or create a local subset.


# DECLARED OBJECTS (check existence and if label not existing: declare)


# Declaration of identified class of individual


:id(var_IdentifierValue) rdf:type <var_EntityType> ; # from Picklist

    rdfs:subClassOf <var_ObjectTypeId ; # from Picklist

    rdfs:label  "var_IdentifierValue" ;

    meta:valEffectiveDate "var_dateTime"^^xsd:dateTime .