In ISO 15926 the definition of cardinalities is exactly the opposite of the customary definition.
This topic explains why and how, and how this is solved in templates.
Cardinalities - customary
Let us take the relationship between a CENTRIFUGAL PUMP and IMPELLER.
Normally a Cardinality defines the minimum and maximum number of occurrences of one entity for a single occurrence of a related entity.
So a CENTRIFUGAL PUMP in general has one to many IMPELLERs, and when we specialize that to a TWO-STAGE CENTRIFUGAL PUMP it has two IMPELLERs.
In these diagrams a relation is shown.
Cardinalities - ISO 15926
In ISO 15926 relationships are understood to be classes themselves that HAVE, not ARE, relations:
Let's focus on one such (ClassOf)Relationship: ClassOfAssemblyOfIndividual:
This diagram shows that myPump shall be involved in exactly two member Relationships at any point in time and myImpeller#1 may be or may be not part of myPump, the same holds for myImpeller#2.
ClassOfRelationship, and all its specializations, has an end1Cardinality and an end2Cardinality relation to dm:Cardinality.
So, here the cardinality is in fact attributed to the ClassOfRelationship and not to the related things.
In the blue part of above diagram is stated that
In any Template Specification this difference has been taken away, as will be explained below.
Take for instance the graph in the template around above ClassOfAssemblyOfIndividual, called ClassOfAssemblyDefinition:
As can be seen both Cardinalities have been swapped. The 'hasCardinalityOfWhole' refers to 'end1Cardinality' and that is the cardinality of the 'classOfPart' (end1 always, by convention, refers to the relation with a name that is the lowest in alphanumerial order).
In this way the cardinalities in the template signature are as they are normally used, whilst internally they comply with the logic of ISO 15926-2.