Unique Name Rule - RE: ADL 1.5 - relaxing a conformance rule - feedback
|
Thomas, the above kind of thing happens
(to my knowledge at least) only when multiple instances of a given node defined
in a system of archetypes and templates, are created at runtime. These are then
only distinguishable by name or some other attribute. The current rule in
openEHR is that the name field has to be made unique across children of an
attribute; this needs to be relaxed so that name only needs to be unique across
those siblings having the same at-code. Now, one of the big changes in ADL 1.5
is that anything you change in a template (+/- the discussion we are now having
about occurrences etc) forces a new at-code specialisation, just like in an
archetype, whereas in the current de facto template standard, it doesn't - a
lot of overriding of the name field is done in current templates. So a large
proportion of his problem will go away with ADL 1.5. [HKF: ] I
would suggest that this unique name constraint is relaxed altogether. It
is a relatively undocumented constraint that is not formally expressed in the
RM, it is alluded to in one place in the COMMON Directory package. This
constraint is an artificial constraint enforced by the RM, which no other
information model has, purely to ensure unique data paths. Although this
reasoning is valid, I do not believe that enforcing this in the reference model
is reasonable and is overly restrictive. It requires either the
system or user to provide a unique name on every multiple occurrence of a
node. In the case of the user this is onerous and makes user interfaces
unfriendly. For systems to generate a unique name simply results in names
such as Blood Pressure #1, or complex algorithms such as a series of concatenated
data items to produce a unique name that may not conflict with another node,
which long and replicates data specified elsewhere and still doesn't guarantee
uniqueness, e.g. Blood Pressure 2010-05-35 08:55:30. My
biggest concern is the overloading of the responsibilities of the name attribute,
originally it was seen as the local name of archetyped concept, allowing data
to be rendered with captions using these local names. Auto generated
naming algorithms make these impossible to use for display purposes. I
think we have two choices: * if
an application context requires uniqueness then it is the responsibility of the
modellers and implementers to ensure there is some combination of attributes
that can be used to identify data nodes uniquely using the attributes that make
sense in that context. This may be name, uid, event time, an archetyped
node. *
provide a real identifier attribute designed for the purpose that can
optionally be used when uniqueness is required. The benefit
of allowing non-unique paths is that we have a solution for the multi-value
problem without any need to change the existing reference model (except for
removing this informal unique name rule), allowing us to use a non-unique path
to retrieve all answers for a multi-value question. Regards Heath |
_______________________________________________ openEHR-technical mailing list openEHR-technical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical