Cross posting form the SEC Slack to avoid missing the discussion.
While working on data validation openEHR conformance, I’ve found in the AOM there is a C_ATTRIBUTE.existence attribute that was not supported by the Archetype Editor or the Template Designer, that is actually mandatory in the AOM.
It appears in both AOM 1.4 and AOM 2.0
These are the definitions and descriptions of the existence. In the AOM 1.4 spec:
Definition of the existence attribute:
Constraint on every attribute, regardless of whether it is singular or of a container type, which indicates whether its target object exists or not (i.e. is mandatory or not).
For C_MULTIPLE_ATTRIBUTEs:
An existence constraint indicates whether an object will be found in a given attribute field, while a cardinality constraint indicates what the valid membership of a container object is. Cardinality is only required for container objects such as List<T> , Set<T> and so on, whereas existence is always required. If both are used, the meaning is as follows: the existence constraint says whether the container object will be there (at all), while the cardinality constraint says how many items must be in the container, and whether it acts logically as a list, set or bag.
BTW I guess the existence could be used when there is a 0…1 attribute in the RM to make it 1…1, BUT! it is not clear what the 0…1 in the RM means, because that is a 0…1 from UML which is the “multiplicity” (UML Multiplicity and Collections - defining and using multiplicity and collections in UML - lower and upper bounds, cardinality, order, unique.). UML multiplicity can be related to AOM existence or AOM cardinality, since sometimes multiplicity applies to collection attributes. I think we need to clarify meanings of UML n…m vs. AOM cardinality, existence and occurrences.
From comments in Slack and the current specs:
- existence signals the nullability of an attribute (if the value of the attribute can be null or not).
- existence applies to single and multiple attributes since it’s defined in C_ATTRIBUTE.
- AOM existence can’t violate the RM existence of an attribute (this not might be missing from the current specs).
- Though the existence in the RM is not clear, IMO due to the use of UML semantics in the RM, in UML we have “multiplicity” associated with attributes (UML Multiplicity and Collections - defining and using multiplicity and collections in UML - lower and upper bounds, cardinality, order, unique.) we might need to add clarification on what is the relationship between RM (UML) multiplicity and AOM existence, since 3 and 7 depend on that definition
- existence could be defined over any attribute of the RM inside an archetype, considering 3.
- the Archetype Editor doesn’t allow to change it and doesn’t generate existence in the ADL, neither the template designer could set existence on attributes, still need to check LinkEHR as Diego commented existence is supported.
- the default value for existence of each attribute in AOM should be the existence of the attribute in the RM (this not it seems also missing from the spec).
- couldn’t find a relationship between C_ATTRIBUTE.existence and C_OBJECT.occurrences, it seems there should be some relationship (e.g. does ELEMENT.value existence = 1…1 imply the object at ELEMENT.value should have occurrence.lower = 1? or occurrence.lower = 1 in the child is compatible with existence = 0…1 in the parent attribute?).
BTW I think there is a wrong description in the spec “Existence constraints say whether an attribute value must exist, and are indicated by 0..1 or 1 markers at line ends in UML diagrams” the existence mentioned here is after an attribute name not at the end of a line. Archetype Definition Language 1.4 (ADL1.4)
Then in the same ADL spec, there is the correct place mentioned “An existence constraint may be used --directly after any attribute identifier–, and indicates whether the object to which the attribute refers is mandatory or optional in the data.”
A related issue is: different vendors might be using/interpreting existence in different ways. We might need to formalize the items above then harmonize implementations, maybe at the conformance level.
Hope this helps.