Instantiating an instance of PossibleIndividual

(or one of its subtypes)

July 2010, rev. 9 Dec. 2010, rev. 10 May 2012


Introduction

In ISO 15926-2 we find the following schema for PossibleIndividual:

PossibleIndividual with subtypes

Please note that none of the subtyping graphs are ONEOF. This is not an oversight, but done on purpose. It means that the model allows for 'complex entity types', where combinations of two or more subtypes can be made.

Given the fact that, once instantiated, no instance may be changed, it is of imperative importance that all instances of PossibleIndividual are properly typed when instantiated.

Why is proper typing important?

In the course of time rules will be defined that apply for a certain entity type (or subtype thereof). One of those rules has already been incorporated in the data model: unless an individual is an ArrangeIndividual (see below) it cannot be the 'whole' in an ArrangementOfIndividual relationship, or of its subtypes AssemblyOfIndividual and FeatureWholePart.

An example of such a rule might be that an Activity cannot have a mass.

Combinations - 1

Obviously not all combinations are meaningful in the real world. The three subtypes at the righthand side are of the first diagram, in most cases, meaningful:

  • The definition for WholeLifeIndividual is: "A WholeLifeIndividual is a PossibleIndividual that is a member of a ClassOfIndividual, and is not a temporal part of any other PossibleIndividual that is also a member of the same ClassOfIndividual. A WholeLifeIndividual includes its past and future. ".

  • The definition for ActualIndividual is: "An ActualIndividual is a PossibleIndividual that is a part of the space-time continuum that we inhabit. It exists in the present, past, or future of our universe, as opposed to some imagined universe.".

  • The definition for ArrangedIndividual is: "An ArrangedIndividual is a PossibleIndividual that has parts that play distinct roles with respect to the whole. The qualities of an ArrangedIndividual are distinct from the qualities of its parts.".

In the diagram below the typing at time of declaration is shown.

WholeLifeIndividual

At some point in time in the engineering of a plant all its possible individuals start to exist. Often, but in no way always, this is when they start to appear on a P&ID (not on a PFD, because those items represent instances of Activity. If properly organized there is one discipline responsible for the instantiation of instances of PossibleIndividual that are also a WholeLifeIndividual.

ActualIndividual

Since the process industries are usually not existing in universes other than the one we inhabit, the instances of PossibleIndividual will always also be an ActualIndividual.

ArrangedIndividual

Since most individuals in a plant will, or may, have one or more 'features' (e.g. surface, thread), and since the relationship FeatureWholePart calls for a 'whole' that is an instance of ArrangedIndividual, it is wise to start assuming that any instance of PossibleIndividual will also be an ArrangedIndividual, unless specifically not so. Better safe than sorry at a later date.

Combinations - 2

Looking at the lefthand side of the first diagram above, we can think of the following combinations:

  • PhysicalObject + Activity

  • MaterializedPhysicalObject + Stream

There are, undoubtedly other combinations possible, but none comes to my mind, unless my proposal for a revision of Part 2 will be accepted.

PhysicalObject + Activity

A fire is a PhysicalObjectANDActivity.

MaterializedPhysicalObject + Stream

Where Part 2 states:

    EXAMPLE The naphtha flowing in a pipe between a crude distillation unit and a platformer is a Stream.

that should be, IMHO, a MaterializedPhysicalObjectANDStream (see RDF/XML listing below).

How is it done in RDF/XML?

Keep in mind that a whole-life individual can hardly have any information. If in doubt, try to visualize whether the information really will be valid during the entire lifetime of the object.

In order to help recognizing the object you may add a label and/or a comment, such as:

        <rdfs:label>Stream S45</rdfs:label>

        <rdfs:comment>

            The naphta stream S45 between the crude distillation unit and the platformer

        </rdfs:comment>

keeping in mind that that information may change in the lifetime of that stream.

This would then result in: