One of the key concepts of ISO 15926 is that of "temporal parts", providing the means to place information about instances of PossibleIndividual in the time. It is the cornerstone of lifecycle information integration.
A quote from Wikipedia:
Temporal parts are sometimes used to account for change. The problem of change is just that if an object x and an object y have different properties, then by Leibniz's Law, one ought to conclude that they are different. For example, if a person changes from having long hair to short hair, then the temporal-parts theorist can say that change is the difference between the temporal parts of a temporally extended object (the person). So, the person changes by having a temporal part with long hair, and a temporal part with short hair; the temporal parts are different, which is consistent with Leibniz's Law.
Also google to: 'perdurantism'
This concept is best explained when applied to a person, say John Doe. If you collect all information that is know about John Doe, it quickly becomes clear that not all information falls in the same category. There may be information about his education, his work, his health, his membership of the tennis club, etc, etc.
And when we look at the information about, for example, his work, we see that he worked for different companies, and within each company he has different functions, labor grades, and salaries, and different projects he worked on, etc, etc. So we may have then a certain hierarchy of temporal parts, i.e. temporal parts of temporal parts.
This is, somewhat colorful, depicted in the picture below, where each colored square represents a different slot:
The top of the information hierarchy (orange) is about the whole-life John Doe, so starting at his birth date-time and ending at the date-time of his death. Each of the blocks inside contains information about a temporal part of John Doe.
Temporal parts can have temporal parts, see the examples in above diagram. Such a hierarchy shall be kept in mind when implementing this concept for all temporal parts that can exist in parallel.
Equipment lifecycle information
When we consider a "materialized" pump we may collect its lifecycle information under the following lifecycle contexts:
This list is not necessarily complete nor correct, but it serves to give you an idea.
Where is procurement? Well, what we procure is not yet our materialized pump. We don't buy a particular pump with its serial number, but a member of the ClassOfMaterializedPhysicalObject of the selected supplier, that shall comply with the requirements spelled out in the specification that classifies the function place for which we buy that pump. This is dealt with in another topic.
Beginning a temporal-part Individual
Begin a temporal part whenever you would, in a paper paradigm, create a new folder for a contiguous period in time and for information within one context. The core life-cycle model gives most of such situations. Use the template BeginningOfTemporalPart for that. Make sure that you declare that created temporal part, see Declaring an Object , so that you can attribute templates to that temporal part as if it is a WholeLifeIndividual (it isn't). Alternatively the template BeginningOfIndividualAtClassifiedEvent can be used in case you want to put on record which Event caused the need to begin that temporal part (e.g. installation of a pump).
Ending a temporal-part Individual
There comes a time that a temporal part ends, for example Pump with Asset Number 654321 is taken out of service P-101, so no further service P-101 related information (e.g. stream properties) shall be attributed to it any longer. Use the template EndingOfTemporalPart to mark that Event. Alternatively the template EndingOfIndividualAtClassifiedEvent can be used in case you want to put on record which Event caused the need to end that temporal part (e.g. the uninstalling of the pump).
When a temporal part has been ended, all relationships that are about that temporal part are no longer valid. For that reason it is wise not to end a temporal part unless you are 100% certain.
The same as above also applies to instances of ClassOfTemporalWholePart at Class level, with one exception: Part 2 does not have a ClassOfWholeLifeIndividual, because Classes are eternal, so all classes would be a ClassOfWholeLifeIndividual.
Now how should a class-of-temporal-part Class be looked at? That is a matter of relevancy. A class-of-temporal-part Class may be relevant at times and irrelevant at other times within the context of the information at hand. For example: a particular Pump Data Sheet rev. 0 is replaced with rev. 1. We deprecate rev. 0 and begin rev. 1 as a class-of-temporal-part of the Class that functions as the "ClassOfWholeLifeIndividual". (since a document presents a view, the templates that are valid at the effective date-time of the next revision are being presented).
Beginning of class-of-temporal-part Class
Use the template ClassOfTemporalPartOfClassOfIndividual and don't forget to declare that class-of-temporal-part Class.
Ending of class-of-temporal-part Class
Since you can't end a Class, you have to deprecate it, i.e. render it irrelevant. See the topic Declaring an Object.
Almost all templates contain (a) temporal part Individual(s) and/or a class-of-temporal-part Class(es). Those do not have to begin or end with above templates.
For practical, implementation, reasons a template instance:
and that covers the defining graph with its components, so inclusive of the temporal-part Individual or class-of-temporal-part Class.