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:
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:
(21) is 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-RC (21) 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 CO-P-101-FRC (12) that is effective (and thus 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, with a SPARQL query, all template instances in which the selected Object-Of-Interest is involved, where necessary combined with other criteria (e.g. being represented on a particular document). Depending on the expected number of templates then select an opt-in or an opt-out mode.
In case of an opt-in mode the ClassOfAssertion in all instances of the template InformationSetPicklist that result from that SPARQL query must be set at 'False' and for those templates that must be in the information set that is subsequently changed to 'True'. The reverse applies for an opt-out mode.
Technically this means that an instance of this template, where 'True' is is changed to 'False', or the other way around, actually is being deprecated and a new instance is automatically being generated with the new value.