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 620347088 gfrer 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment.html>
