Heath, I suspect that the way forward is to do as you say, and remove name-uniqueness, and simply accept and document the fact that there could be multiple values at any given path. I am not sure if this deals with all aspects of the multi-value problem, I need to re-analyse that one.....
- thomas On 25/05/2010 01:45, Heath Frankel wrote: > > 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 at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100525/716c2639/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100525/716c2639/attachment.jpg>
