Introduction

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.

Definition

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 visit Stanford Encyclopedia of Philosophy - Temporal Parts

Discussion

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 depicted in the, somewhat colorful, 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 an actual 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 actual pump. We don't buy a particular pump with its serial number, but a member of the ClassOfPhysicalObject 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 Declaring a Tag, a Stream, and a Commodity Product.

Beginning a temporal-part Individual

In most cases the temporal part is hidden inside a template for a practical reason: the vast majority of COTS applications doesn't explicitly support the concept of temporal parts. So when mapping their data pretends that the information applies to the temporal whole. In the definition of the templates, though, it is clear that it applies to the temporal part.

In the topic Plant Life-cycle Model the situations, where explicit temporal part Individuals and Classes (see below) must be declared, are given. The diagram below is showing those situations with red-colored temporalPartOf and coTemporalPartOf predicates.

In other situations 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 above plant life-cycle model gives most of such situations. Declare that temporal part (see Declaring a Tag, a Stream, and a Commodity Product), so that you can attribute templates to that temporal part as if it were a WholeLifeIndividual (whilst it isn't).

The template IndividualHasTemporalPart can be used, after you have declared that temporal part.

Alternatively the template BeginningOfIndividualAtEvent can be used in case you want to put on record which Event caused the need to begin that temporal part (e.g. a pump failure).

Or use the template ActivityCausesBegunIndividual in case you want to put on record which Activity caused the need to begin that temporal part (e.g. the installation activity 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. Deprecate that temporal part (see Declaring a Tag, a Stream, and a Commodity Product), so that you can no longer attribute templates to that temporal part.

The template EndingOfIndividualAtEventcan be used in case you want to put on record which Event caused the need to end that temporal part (e.g. the pump is reported successfully maintained, OR the pump has been started by level swicth LSL-101.)

Or use the template ActivityCausesEndedIndividual in case you want to put on record which Activity caused the need to end that temporal part (e.g. the uninstallation activity of a pump).

When a temporal part has been ended, all relationships that are about that temporal part have become history (these records are maintained in store as long as being of interest for historical reasons).

ClassOfTemporalWholePart

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.

ClassOfTemporalWholePart is very useful to keep a record of developments in Engineering and Design, which produce records of Classes (with the exception of the topological design of a plant).

The story of the diagram below is, that between Jan. 6th 2018 and May 14th 2018 the requirement was that members of the yellow ClassOfPhysicalObject shall have a size of 2 inch. So any individual PhysicalObject that was deemed to be a member could only be a member in case it had a size of 2 inch.

From May 14th 2018 onwards, until today, the requirement was that members of the blue ClassOfPhysicalObject shall have a size of 3 inch. The blue individual PhysicalObject that is shown to be a member can only be such iff it has a size of 3 inch.

The essence of this story is that, although Classes are eternal they are not always relevant in a certain context. They may be relevant at a time and irrelevant later due to a design change. In this way we can put the history of the developments on record.

Speaking about records, a document is a Class as well, with individuals, such as today's newspaper in your mailbox, as members. We have a "whole life" document class as the 'classOfWhole' in the diagram with no revision, and with revision 0, rev. 1, etc as 'classOfPart' document classes. CFIHOS calls these DOCUMENT MASTER and DOCUMENT REVISION.

Beginning of class-of-temporal-part Class

After declaring a Class or a class-of-temporal-part thereof, use the template ClassOfTemporalWholePartDefinition.
In case you need to put on record which Activity caused that, use ActivityCausesEffectiveClassOfIndividual.

Ending of class-of-temporal-part Class

Since you can't end a Class, including a ClassOfTemporalWholePart, you have to deprecate it, i.e. render it irrelevant in your context. See the topic Declaring a Tag, a Stream, and a Commodity Product.
In case you need to put on record which Activity caused that deprecation use the template ActivityCausesDeprecatedClassOfIndividual.