Declaration Of Actual Individual

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 the pump P-101 as an example.

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



ISO 15926-2 entity type of the declared Actual Individual




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




Identifier, such as serial number (not Tag Number), of the Actual Individual 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 OBJECT (check existence and if label not existing: declare)


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

    rdfs:label  "var_IdentifierValue" ;

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