Hi Thomas, 1. I think node_id rather than "meaning" for the name of this data would be clearer.
2. A compromise suggestion to address Dipak's issue (which I think is important) as well as reduce XML bloat: Change the datatype to just a string but introduce a new section at the start of the XML "package" which has a list of name/value pairs of form: <archetype references> <archetypeID> "atnnnn" <\archetypeID> <archetypeName> "An archetype formal name" <\archetypeName> </archetype references> one pair for each archetype referenced in the following XML "package". This would also be helpful for software to pre-locate all required archetypes (e.g. when XML is initially received) prior to further processing the XML. Regards Vince Dr Vincent McCauley McCauley Software Pty Ltd ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: "Openehr-Technical" <openehr-technical at openehr.org> Sent: Saturday, July 10, 2004 8:36 AM Subject: RFC CR-000024 - Revert "meaning" to String - ARB deadline 23 july 2004 > > Dear all, > > here is another important CR to consider in the next few weeks. > > CR-000024 - Revert "meaning" to String. See > <http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-000024 .txt>. > This CR is about the meaning attribute defined on the class LOCATABLE > (see Common Model, Archetype package, at > <http://www.openehr.org/repositories/spec/latest/publishing/architecture/ref erence_model/common/im/REV_HIST.html>). > This attribute is one of the most important in the whole reference model > - it is effectively the node id of every node in an archetype, and it is > what gets imprinted into data, so that the latter can be reconnected > with its archetypes. It also has a second purpose: it is coded in the > archetype, giving it a normalised meaning in multiple languages, e.g > "systolic pressure", whereas as the node name might have been set by the > user to "sys BP" or whatever. Currently, the attribute is of type > DV_TEXT, meaning it could be a DV_CODED_TEXT as well (see the data types > reference model for these types - > <http://www.openehr.org/repositories/spec/latest/publishing/architecture/ref erence_model/data_types/im/REV_HIST.html>). > Given that every single node in data will contain this item, it has been > proposed by Sam, and now more recently by the DSTC that it should be > reverted to just a String expressing the code (it must be an "at" code, > of the kind you see in the archetypes), because to use a DV_CODED_TEXT > means there is a DV_CODED_TEXT object, a CODE_PHRASE object, with the > latter containing 2 Strings. The DSTC have shown that in the XML of the > data, this causes quite a bit of bloat. Sam Heard has always contended > that we should just used the code as a String; the pracical consequence > of this is that you must have archetypes present to interpret the node > id. Dipak Kalra has always contended that it should be present as the > full coded term, so that the normalised meaning is available in the data > (well, in one language at least), without referring to the archetype. > > It is also important to realise that the expression of the 'meaning' > attribute as a simple string such as 'at0001', 'at0045.1' etc (codes > derived from the archetypes) provides an easy way to support path based > querying in XML data, using Xpath. A path of the form > .../events[@id=at0014]/... can find the node marked with the arhceytpe > node id (= meaning) 'at0014'; a concatenation of such patterns enables > nodes to found anywhere in large trees of XML data. > > It has also been argued that the name of the attribute - 'meaning' > should be changed to e.g. 'node_id', or even just 'id' - whcih would not > harm the comprehension of archetypes, and would be more obvious in data. > > reactions? > > - thomas beale > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
