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 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 (see under Instantiation). Each of the blocks inside contains instances of TemporalWholePart that are classified with the same instance of ClassOfTemporalWholePart (the 'context').
Such a hierarchy shall be kept in mind when implementing this concept for all temporal parts that can exist in parallel. If not so, for example John Doe's successive ranks in XYZ Ltd, or in another context, for equipment that is either in operation or not, that information better be stored in one slot in order to avoid contradicting information about a piece of equipment being in operation and being out of operation.
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 will be dealt with an another topic.
Although it is tempting to create a numbering system for all individuals, that reflects the number of the temporal whole AND the context AND the date-time, it is advisable not to do this. A rule of proper modeling is that no logic shall be applied to identifiers. So, the advice is to use random numbers for the temporal parts. Advised is to use UUIDs.
Ending a temporal part
There comes a time that a temporal part ends. This requires some careful programming, because that temporal part needs to be found on the basis of the template signature that began that temporal part. Then we apply the template EndingOfTemporalPart to that temporal part:
When a temporal part has been ended, all relationships that involve that temporal part are no longer valid. For that reason it is wise not to attach more than one information chunk to a temporal part, because when one "sub-chunk" would no longer be valid, you can only make that invalid by ending the temporal part. That will make all other "sub-chunks" invalid as well. So keep the granularity as fine as possible.