Declaration Of Imaginary Individual

latest update: 2017-11-03     



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.

We start with declaring a particular PUMP, and identifying it with "P-101". This object will exist until it is ended, 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 this 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 when neither the functional nor the physical characteristics are known or when both are irrelevant in the declaration context *);
  • FunctionalPhysicalObject - to be used when only the functional characteristics are known or relevant;
  • MaterializedPhysicalObject - to be used when only the physical characteristics are known or relevant;

*) 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 that exist for a functional reason.

The "Declaration Class" is important and shall be selected carefully. It is the class of which the declared imaginary 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




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.



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


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

    rdfs:label  "var_IdentifierValue" ;

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