Class of relationship with Cardinality

latest update 6 Jan. 2013


Introduction

In ISO 15926-2 you will find a number of subtypes of ClassOfRelationship. Where ClassOfRelationship has some interesting attributes and subtypes, these are inherited by its subtypes.

Cardinalities

As an example we work out the model of AssemblyOfIndividual and ClassOfAssemblyOfIndividual. Assume an instance of ClassOfInanimatePhysicalObject called TWO-STAGE CENTRIFUGAL PUMP, of which members shall have two impellers:

 

Two-stage centrifugal pump with two impellers

Cardinalities in ISO 15926-2 are somewhat longwindedly expressed, due to the normalized character of this model. The instance of ClassOfRelationship has two attributes, the classOfPart and the classOfWhole. And it has two other (optional) attributes, the end1Cardinality and end2Cardinality. The end1Cardinality  tells something about the classOfPart attribute, because that is the first in the alphabetical order.

The attribute end1Cardinality points at an instance of Cardinality called CAR1:1  that has a minimumCardinality attribute and a maximumCardinalty attribute with the value '1' . That means that any member (e.g. myImpeller#1) of the Class 'IMPELLER'  can play that 'part' role of one and only one member of that ClassOfRelationship.

 

Part 2 states for the Cardinality attributes:

maximum_cardinality : The maximum number of times a member of the domain can participate in the role specified. If no maximum_cardinality is specified, then there is no maximum constraint.

NOTE 1 Common values for maximum_cardinality are 1 and many. Many is the result of specifying no value.

minimum_cardinality : The minimum_cardinality is the minimum number of times a member of the domain class may participate in the role specified.

If no minimum_cardinality is specified the value shall be taken as zero.

NOTE 2 Common values for the minimum_cardinality are zero and one.

 

The attribute end2Cardinality points at an instance of Cardinality called CAR2:2  that has a minimumCardinality attribute and a maximumCardinalty attribute with the value '2' . That means that any member (e.g. myPump) of the Class 'TWO-STAGE CENTRIFUGAL PUMP'  can play that 'whole' role of two and only two members of that ClassOfRelationship (if there would be more or less, then it would no longer be a 'TWO-STAGE CENTRIFUGAL PUMP' class).

 

The definition of cardinality, as shown above, may seem somewhat counterintuitive, because it is a definition for the ClassOfRelationship, and not (as usual) on the objects being related. So it tells how many instances of that ClassOfRelationship may exist with that (rdf:)object. So, at first glance you might be reading that one impeller can be part of two centrifugal pumps, but here it is defined as the reverse.

A temporal part of a centrifugal pump has a temporal part of an impeller as a part

Note that the whole-life pump and its two whole-life impellers cannot have properties and other information attributed to them (such as composition), other than their ID and its essential class (here: 'TwoStageCentrifugalPump' and 'PumpImpeller'). The essence of WholeLifeIndividual is that it can be attributed only with information that will remain valid throughout its entire life. Only short-lived individuals, of which it is dead-certain that they will NEVER change, even not in location, might be attributed with all their information. I wouldn't bet on that to happen in a plant.

So any piece of information (read: template instance) should be attributed to a temporal part with a different ID and the same date-time as that of the whole-life parent.

In case you change a tyre of your car, that will result in a temporal part of your car, but in remains your car. Even if you change each and every part of your car, it will remain your car, unless you formally declare it "dead".