Just use archetypeID+nodeID, then you have a unique concept id for each node.
-- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: hugh.les...@oceaninformatics.com To: openehr-technical at lists.openehr.org; gfrer at luna.nl Date: Thu, 29 Aug 2013 00:13:29 +0200 Subject: Re: Polishing node identifier (at-codes) use cases. Hi Gerard, This is science, not religion. Can you please give reasons for your statements that archetype nodes must be unique concepts and must be uniquely identified? In openEHR and 13606, the archetype is the unique concept which means that nodes quite rightly can have unique meaning in the context of the archetype. This is like human language where the same word can have different meanings depending on the context used. I have never been given a scientific reason why every node in an archetype should be uniquely coded or have unique meaning outside the archetype itself. I have never found a use case that makes this necessary but would be interested if anyone can show me one. Regards Hugh ----- Original message ----- From:Gerard Freriks <gfrer at luna.nl> Date:28 August 2013 1:26:14 PM Subject:Re: Polishing node identifier (at-codes) use cases. To:For openEHR technical discussions <openehr-technical at lists.openehr.org> David, Can I summarise it for my understanding as:- ATxxxx codes are pointers to an 'ontology'.- ATxxxx codes can be considered symbols that represent a particular concept- The 'ontology' provides a name that will be used to display the name of a node (concept) in an archetype.- When a node is specialised the node name used will indicate a new concept (its meaning has changed)- When the archetype is specialised ideally the new concept in the specialisation is a subordinate concept.- When a Node is specialised the standard does not prescribe that the new concept is a sub-set of the previous one.- The question is: is each Node (and the concept it represents) unique or not.- The question is: is it obligatory that each node in the archetype carries a unique code of the form ATxxxx . My answers to both questions are:- Each archetype node is a unique concept that must have attached to it a unique identifier.- Archetype editors must support this. And I would like to add:- When specialising each specialised concept must be a subset of its previous one. Gerard Freriks+31 620347088gfrer at luna.nl On 28 aug. 2013, at 09:13, David Moner <damoca at gmail.com> wrote:I'll try to summarize the origin of the different views we have regarding this topic and maybe this can be also useful to see why this is not just a configuration problem of the tools. We can find the explanation of node identifiers in two places (I use the latest drafts, I think):- In AOM 1.5 specifications, page 47: "Semantic identifier of this node, used to distinguish sibling nodes of the same type. [Previously called ?meaning?]. Each node_id must be defined in the archetype ontology as a term code."- In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of the form [atNNNN] following a type name is used to identify an object node, i.e. a node constraint delimiting a set of instances of the type as defined by the reference model." and "A Node identifier is required for any object node that is intended to be addressable elsewhere in the same archetype, in a specialised child archetype, or in the runtime data and which would otherwise be ambiguous due to sibling object nodes" The definition in AOM is the one followed by the openEHR editor, i.e. a node identifier or atNNNN code is just a pointer to the ontology section and a mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the tool does not introduce that code in order not to dirty the ontology section. The first part of the definition in ADL is the one followed in LinkEHR and, in our opinion, more correct formally. When you introduce an archetype constraint for a C_OBJECT you are in fact creating a definition of a type (a sub-type of the more generic type defined by the reference model class) that will be used to create a subset of instances. We have to distinguish this sub-type from the RM type, and since the class name cannot be changed, the only solution is to use the atNNNN as type identifier. In other words, our interpretation is that atNNNN codes are unique identifiers of each type defined in the archetype, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/b1f51ef3/attachment-0001.html>
