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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100525/5ea3ceee/attachment.html>
