Class of relationship with Cardinality
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.
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.
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".