Declaration Of Imaginary Individual With Requirements Class

latest update: 2017-10-23     



All things, that are involved in any information, shall first be declared and identified as "Ur" objects (see The idea can be explained using the pump P-101 as an example. This TIP is an extension of the TIP DeclarationOfImaginaryIndividual in that the Ur Requirements Class is being declared as well. This couple together is an "anchor" without attributed information, that exists as long as it is functionally required.

We start with declaring a PUMP, and identifying it with "P-101". This object will exist until it is ended (individuals) or deprecated (classes), and it will not have any information attributed to it other than through its 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.

NOTE - The fact that this anchor object is made a variable in all templates in which actually one of its temporal parts plays a role is because those 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.

It is like a car with a chassis number "1HG CM8263 3A004352" . Even when, during its lifetime, all parts have been replaced, that car remains "1HG CM8263 3A004352" , the anchor object, where these replacements are being attributed to temporal parts of that Ur object. The license plate number of that car, however, can be replaced with another one (in most countries).

In case the Ur object is deprecated, all its temporal parts are ended | deprecated (in case this wasn't already the case) and all templates in which these ended | deprecated 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.  

Next to the GUID many things get one or more user-memorizable identifiers, such as tag number, serial number, asset number, line number, equipment number, etc. These identifiers are, in the context of ISO 15926, of utmost importance, because they are the starting point of most queries. Therefore a consistent format of them is important.

The GUID can easily be fetched with a simple SPARQL query using an identifier as search criterium and hence doesn't have to be stored in the source system.

The "PhysicalObjectType"  calls for a selection from three possibilities:

  • PhysicalObject - to be used for the Ur physical object that is a WholeLifeIndividual *);

  • FunctionalPhysicalObject - to be used to define the functional characteristics;

  • MaterializedPhysicalObject - to be used to define the physical characteristics.

*) In cases where the object is being declared as a WholeLifeIndividual use the instance of ClassOfFunctionalObject "UNDEFINED FUNCTION" (rdl:RDS2220000). Example: A Person is not born as engineer. Add the functional aspect by declaring a temporal part with TIP "DeclarationOfTemporalFunctionalPartOfImaginaryIndividual". Exception to that rule are instances of lci:InanimatePhysicalObject, such as a PUMP, that exist for a functional reason.

The "Declaration Class" is important and shall be selected carefully. It is the class of which the declared designed Individual is a  member. It is the class that is ALWAYS valid as long as the declared object hasn't been deprecated. If the Declaration Class is changed the Individual 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 specialization or 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.




Role No

Role Variable

Description of Variable

Example of value


var_PhysicalObjectType Select from dm:PhysicalObject, dm:FunctionalPhysicalObject or dm:MaterializedPhysicalObject




ISO 15926 entity type of the declared imaginary (non-actual) Individual




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




Identifier, such as Tag Number, of the imaginary Individual that is being declared




Identifier suffix for the immutable "anchor" "Requirements Class", subtype of ClassOfIndividual, that co-exists with the imaginary Individual that is being declared




ISO 15926-2 entity type of the declared Requirements Class




The effectivity xsd:dateTime of the information represented here




For Role 2 refer to  or create a local subset.

For Role 3 refer to  or create a local subset.

For Role 6 refer to  or create a local subset.



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

:id(var_IdentifierValue)rdf:type <var_PhysicalObjectType>, <var_EntityType>, <var_ObjectTypeId>, dm:WholeLifeIndividual, :id({var_IdentifierValue}{var_ReqClassTagSuffix})  

    rdfs:label  "var_IdentifierValue" ;

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


:id({var_IdentifierValue}{var_ReqClassTagSuffix}) rdf:type <var_ReqClassEntityType> ;

    rdfs:label  "var_IdentifierValuevar_ReqClassTagSuffix" ;

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