don't forget the organization responsible for that archetype ;D
2013/8/29 pablo pazos <pazospablo at hotmail.com> > Just use archetypeID+nodeID, then you have a unique concept id for each > node. > > > -- > Kind regards, > Eng. Pablo Pazos Guti?rrez > http://cabolabs.com <http://cabolabs.com/es/home><http://twitter.com/ppazos> > > ------------------------------ > From: hugh.leslie at 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 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 > > > > _______________________________________________ openEHR-technical mailing > list openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > 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/20130829/65aec12d/attachment.html>
