Information Sets

latest update: 2018-06-12    


Templates are the smallest units of information. In this topic the grouping of templates in Information Sets, valid at a give dateTime, will be discussed.


All templates for one or more Individuals and/or one or more Classes are seemingly about those Individuals or Classes, but in fact they are about a temporal part of the mentioned Individual(s) or a class of temporal part of the mentioned Class(es). The temporal parts are hidden inside the templates. The reason for that is that COTS (Commercial Of The Shelve) software doesn't know about temporal parts.

Here is an (adapted) excerpt from the Plant Life-cycle Model, showing that an Asset is, in this example, involved in five templates:

There are the following situations related to the red-marked Physical Object that is the Asset:

  1. in the case of Logistics it is in the signature of the template BeginningOfTemporalPart as the 'part'
  2. in the case of Construction it in the signature of the template BeginningOfTemporalPart as the 'whole'
  3. in the three other cases (2x ClassificationOfIndividual and ParticipationInActivity) it is in the signature, but the information is in fact attributed to a temporal part hidden in the template.

In cases 1. and 2. where a temporal part is explicitly created and related to a temporal whole the temporal part can act as a temporal whole for other physical objects and thus information can be attributed to it. For example in case 2 (Construction) the installed asset can be involved in Operations (not always, for example a pipe rack is not).

Creating an Information Set

For this another excerpt from the Plant Life-cycle Model is used:



(22) and (21) are being declared simultaneously and linked with an rdf:type rather than with a ClassificationOfIndividual  template. The reason for that is that both are immutable "anchors" with information other than their typing, label, and effectivity dateTime. An rdf:type is much harder to delete than it is to deprecate a template, so inadvertent changes are as much as possible prevented.

All information about Requirements Class CO_P-101 (21), as long as it has not been deprecated, is represented with templates that have that class in their signature. So why does (19) exist? Now we get to the heart of this topic.

In general an Information Set, or a "view" if you like, is created for a specific purpose, such as input for a calculation, or in the above case the publication of a revision of the specification (20). So, the event of publishing a revision of the Specification shall trigger the formation of the applicable Information Set, and that set is attributed to a new instance of (19) that is also made an rdfs:subClassOf the ClassOfFunctionalObject (12) that is effective and not deprecated at that point in time.

For this we use one instance of the template RepresentationOfClassOfIndividualOnDocumentWithTemplateSet or RepresentationOfClassOfIndividualWithTemplateSet plus as many instances of the template InformationSetPicklist as there are template instances in the Information Set. NOTE - In this case (19) is in the signature of the first two template types.

It is suggested to fetch all template instances in which the selected Object Of Interest is involved, and depending on the expected number of templates select an opt-in or an opt-out mode. Once such an EnumeratedSetOfClass has been populated it can easily be changed by deprecating the templates that are no longer required and/or adding templates.