Effectivity & Deprecation

latest update: 2016-10-25    


One of the key concepts of ISO 15926 is the use of "temporal parts" of PossibleIndividuals and similarly the use of "class of temporal parts" of Classes.

As such this concept is very elegant, but in an RDF + SPARQL implementation it has its drawbacks. This is explained in this document and a change in the set-up of templates is proposed.

Initial situation

Any information about an instance of PossibleIndividual that is NOT a WholeLifeIndividual is attributed to a temporal part of that instance of PossibleIndividual. For example:

If, later, this description is no longer valid we have to "end" the temporal part PossibleIndividual (x2).

That has to be done with the template EndingOfTemporalPart:

This is proper modeling, but very elaborate for any SPARQL query, because no template instance can be trusted as is without checking whether or not it is still valid by searching for such an EndingOfTemporalPart template instance with the same x1 and x2.

For templates for classes a similar situation applies, with some differences. If we consider the similar template:

In case an instance of this template is no longer valid in this context we must deprecate x2.

For SPARQL queries the same problem occurs as that described for templates for temporal part. It is always required to validate whether or not x2 has been deprecated.

New situation

The validity of information is represented by using two owl:AnnotationProperties:

  1. meta:valEffectiveDate - the dateTime that the information represented by a template becomes effective.
  2. meta:valDeprecationDate - the dateTime that the information represented by a template is deprecated, i.e. no longer valid in this context.

The two templates now look like this:

and for ClassOfIndividual:

In cases where lifting of the templates is required, these annotation properties can easily be transformed into template instances. This is described in the topic Mapping of Provenance Data.

Effectivity and deprecation of template instances:

A template for individual:

:T9B10ED9CE6784F31BB49521D79041A71 rdf:type tpl:ClassifiedDescriptionOfIndividual ;

    tpl:hasDescribed :TE9E4DFD3981E47B885A932177A3AD6D7 ;

    tpl:valDescriptor "Boiler Feedwater to E-103" ;

    tpl:hasDescriptionType rdl:RDS2229180 ; # DESCRIPTION WITH SERVICE DESCRIPTION

    meta:valEffectiveDate "2013-02-15T13:29:00Z"^^xsd:dateTime .

becomes, after deprecation:

:T9B10ED9CE6784F31BB49521D79041A71 rdf:type tpl:ClassifiedDescriptionOfIndividual ;

    tpl:hasDescribed :TE9E4DFD3981E47B885A932177A3AD6D7 ;

    tpl:valDescriptor "Boiler Feedwater to E-103" ;

    tpl:hasDescriptionType rdl:RDS2229180 ; # DESCRIPTION WITH SERVICE DESCRIPTION

    meta:valEffectiveDate "2013-02-15T13:29:00Z"^^xsd:dateTime ;

    meta:valDeprecationDate "2013-04-26T14:18:00Z"^^xsd:dateTime .

by simply adding one triple to the triple store:

:T9B10ED9CE6784F31BB49521D79041A71 meta:valDeprecationDate "2013-04-26T14:18:00Z"^^xsd:dateTime .

Effectivity and deprection of declared objects

For Part 2 Classes the code after declaration looks like this:

:C7DE22CB10E4144E88922B79E75467448 rdf:type dm:ClassOfInanimatePhysicalObject ;

    rdfs:subClassOf rdl:RDS5785737 ;

    meta:valEffectiveDate "2011-09-04T13:45:00Z"^^xsd:dateTime .

at deprecation time the following triple is added:

:C7DE22CB10E4144E88922B79E75467448 meta:valDeprecationDate "2011-11-25T16:25:00Z"^^xsd:dateTime .

which simply is added in the triple store:



<http://data.15926.org/dm/ClassOfInanimatePhysicalObject> .



<http://data.15926.org/rdl/RDS5785737> .



"2011-09-04T13:45:00+00:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .



"2011-11-25T16:25:00+00:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .


See further the topic Declaring an Object.


A SPARQL query, using the valEffectiveDate and valDeprecationDate to find the templates about above-mentioned instance of dm:PossibleIndividual, looks like this*:

# Find all template UUIDs about a given object UUID that are valid at a given dateTime

PREFIX : <http://www.p1234.xyz-corp.com/>

PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

PREFIX meta: <http://data.poscaesar.org/meta>

SELECT ?object_UUID ?template_UUID ?effective_date


 ?template_UUID ?p ?object_UUID . #

 FILTER (?object_UUID = :C7DE22CB10E4144E88922B79E75467448 ) . # input, selecting all rdf:subjects where the rdf:object is :C7DE22CB10E4144E88922B79E75467448

 ?template_UUID meta:valEffectiveDate ?effective_date .

 OPTIONAL { ?template_UUID meta:valDeprecationDate ?deprecation_date } . # include template_UUIDs that do not have a deprecation date

 FILTER ( xsd:dateTime(?effective_date) <= "2011-10-21T00:00:00Z"^^xsd:dateTime ) . # input, selecting all template_UUIDs that became effecive on or before

 FILTER ( xsd:dateTime(?deprecation_date) > "2011-10-21T00:00:00Z"^^xsd:dateTime || NOT EXISTS {?template_UUID meta:valDeprecationDate ?deprecation_date }) . # input, selecting all template_UUIDs that have either no deprecation date or a deprecation data after 2011-10-21T00:00:00Z


In above case it will give as result:







In case a date later than 2011-11-25T16:25:00Z would have been made input the second column would have been empty.

* The quality of above SPARQL query may not be optimal, suggestions for improvement are welcome.

Semantic consequences

For OWL reasoning the proposal has no, or hardly any, consequences since:

  • a "domain of discourse" must be selected first with SPARQL;
  • a mapping of the project data from RDF to OWL2 must be made anyway, see here;
  • during that mapping topic Mapping Provenance Data should be taken into account.