Declaring an object

Latest update: 2016-10-25        



In Part 8 Annex C we find:

C.8.1 Declaration

Where in OWL resources are normally not declared, this is mandatory in this part of ISO 15926.

The only exception is that any temporal part, being the rdf:object of a template property, shall not be explicitly declared.

(side note: now a classOf(Temporal)Part of an Class should be added, see also here).

This paper deals with that declaration requirement.


There was a dispute about declaration. Some members of the 15926 community were of the opinion that by using the ClassificationOfIndividual template that PossibleIndividual is well enough declared:

:T593F4EF8DAF9400D83327BFB6FFE8731 rdf:type tpl:ClassificationOfIndividual ;

      tpl:hasClassified :TC8A372E23B124B44AB32E32065507A85 ; # P-101

      tpl:hasClassifier rdl:RDS327239 ; # PUMP

      meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

This is not enough, because it does not define whether TC8A372E23B124B44AB32E32065507A85 is a FunctionalPhysicalObject or a MaterializedPhysicalObject, or wether or not it is a WholeLifeIndividual and/or ActualIndividual.

In ISO 15926 declaring objects means that the objects are typed with one or more applicable ISO 15926-2 entity types, thus firmly founding these objects. The dispute has been settled.



When an instance of a (Part 2) Class is declared the following information must be given:

  • the applicable instance of a Part 2 entity type;
  • the unique ID of the declared Class;
  • a given RDL Class of which the Class is a subclass.

A typical example is the code for knock out drum.

First it is declared as being a member of VESSEL, the highest in that class hierarchy, and then it is made a KNOCK OUT VESSEL, being a specialization of VESSEL. The reason for this two-step approach is that a template can easily be replaced with another one, but changing the type of a declared object is complicated.

:CAECD286079EF4CB394554D4D2342CCD5 rdf:type dm:ClassOfInanimatePhysicalObject ;

    rdfs:subClassOf rdl:RDS414674 ; # VESSEL

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

:T264C57E2915B4D2181EE628AFD3C2A8E rdf:type tpl:ClassifiedIdentificationOfClassOfIndividual ;

    tpl:hasIdentified :CAECD286079EF4CB394554D4D2342CCD5 ;

    tpl:valIdentifier "CO_B14-V-101" ; # a way to tag the requirements class of B14-V-101 (CO_ = ClassOf)

    tpl:hasIdentificationType rdl:RDS2221090 ; # IDENTIFICATION BY EQUIPMENT TAG

    meta:valEffectiveDate "2006-10-14T09:32:00Z"^^xsd:dateTime .

and later:

:T8F109CBC01AC40E2A0A066B54A1218F6 rdf:type tpl:SpecializationOfClassOfIndividual ;

    tpl:hasSubClass :CAECD286079EF4CB394554D4D2342CCD5 ;

    tpl:hasSuperClass rdl:RDS43167567209 ; # KNOCK OUT VESSEL

    meta:valEffectiveDate "2004-11-24T14:57:00Z"^^xsd:dateTime .

Assume that, for some reason, the IDis changed from CAECD286079EF4CB394554D4D2342CCD5 to C926AC172CB4E48F7BA2FF9DA823D5DC0 at a later date, then the following happens:

:C926AC172CB4E48F7BA2FF9DA823D5DC rdf:type dm:ClassOfInanimatePhysicalObject ;

    owl:sameAs :CAECD286079EF4CB394554D4D2342CCD5 ;

    meta:valEffectiveDate "2006-10-14T09:32:00Z"^^xsd:dateTime .

In cases where the new ID has been created independently, by error or else, and is not deprecating the old ID, both ID's can co-exist (for a while). owl:sameAs is transitive, so information about the one also applies to the other. Ultimately though, the sooner the better, one of both shall be deprecated and the still valid templates about it shall be referring to the remaining ID. This can be done with SPARQL Update DELETE/INSERT.

PREFIX p1234: <>


DELETE { ?s ?p p1234:CAECD286079EF4CB394554D4D2342CCD5 }

INSERT { ?s ?p p1234:C926AC172CB4E48F7BA2FF9DA823D5DC }

WHERE  { ?s ?p p1234:CAECD286079EF4CB394554D4D2342CCD5 }

Deprecating a Class

In case the relevance of any instance of Part 2 ClassOfIndividual ends, this shall be recorded as follows:

:C926AC172CB4E48F7BA2FF9DA823D5DC meta:valDeprecationDate "2014-02-15T12:55:00Z"^^xsd:dateTime .

The validity of all templates in which this Class plays a role are, as a consequence, also ended, i.e. invalid as of the given valDeprecationDate. The software shall take care of that.

Possible Individuals

When an instance of a (Part 2) PossibleIndividual is declared the following information must be given:

  • the Part 2 entity type is a dm:WholeLifeIndividual *) AND an applicable subtype(s) of PossibleIndividual (e.g. FunctionalPhysicalObject);
  • the unique ID of the declared WholeLifeIndividual;
  • a given RDL Class (highest in the applicable class hierarchy) of which the WholeLifeIndividual is a member.

*) Temporal parts of that WholeLifeIndividual can play the role 'temporal whole' again in other templates. These must not be declared, because the TemporalWholePart relationship is transitive.

A typical example is:

:TE09170257F9541D48B5F2937A2A40920 rdf:type dm:FunctionalPhysicalObject, dm:WholeLifeIndividual, dm:ArrangedIndividual, rdl:RDS414674 ;

    meta:valEffectiveDate "2005-10-14T13:00:00Z"^^xsd:dateTime .

:Ta9bc7570 rdf:type tpl:ClassifiedIdentificationOfIndividual ;

    tpl:hasIdentified :TE09170257F9541D48B5F2937A2A40920 ;

    tpl:valIdentifier "B14-V-101" ;

    tpl:hasIdentificationType rdl:RDS2221090 ; # IDENTIFICATION BY EQUIPMENT TAG

    meta:valEffectiveDate "2006-10-14T09:32:00Z"^^xsd:dateTime .

Now the vessel can be classified as being a member of KNOCK OUT DRUM and being a member a "requirements class" as defined in a specification.

:TB17206B8D8BD48B6BDD991A836B9C461 rdf:type tpl:ClassificationOfIndividual ;

    tpl:hasClassified :TE09170257F9541D48B5F2937A2A40920 ;

    tpl:hasClassifier rdl:RDS43167567209 ; # KNOCK OUT VESSEL

    meta:valEffectiveDate "2006-10-15T13:00:00Z"^^xsd:dateTime .

:T926AC172CB4E48F7BA2FF9DA823D5DC0 rdf:type tpl:ClassificationOfIndividual ;

    tpl:hasClassified :TE09170257F9541D48B5F2937A2A40920 ;

    tpl:hasClassifier :C926AC172CB4E48F7BA2FF9DA823D5DC ; # Requirements Class that is defined in a vessel specification

    meta:valEffectiveDate "2006-10-15T13:05:00Z"^^xsd:dateTime .

Ending a PossibleIndividual

In case the existence of any instance of Part 2 PossibleIndividual ends, this shall be recorded as follows:

:TE09170257F9541D48B5F2937A2A40920 meta:valDeprecationDate "2014-02-15T12:55:00Z"^^xsd:dateTime .

The validity of all templates in which this individual plays a role are, as a consequence, also ended, i.e. invalid as of the given valDeprecationDate.

When the need for reasoning with OWL-based tools arises, this is to be mapped to an instance of the EndingOfIndividual template:

:T2F918E7426514896BC8C50FF52AF677B rdf:type tpl:EndingOfIndividual ;

    tpl:hasIndividual :TE09170257F9541D48B5F2937A2A40920 ;

    tpl:valEndTime "2014-02-15T12:55:00Z"^^xsd:dateTime ;

    meta:valEffectiveDate "2014-02-15T12:55:00Z"^^xsd:dateTime .