On 28/08/2013 08:13, David Moner 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.
Does LinkEHR actually do this? I.e. only some at-codes are found in the ontology? Your statement above (bolded) is right in theory (or at least that's the way I see it), but then the obvious question is: if I mutate the type (say) ENTRY to ENTRY[at0123], what does ENTRY[at0123] mean? In general we want to equate that with a meaning of some kind (like 'ENTRY' has a meaning). Remember, we could have done something like 'ENTRY[admission]' or 'ENTRY[bp_measurement]' but we don't do that because we want the meanings to be multi-lingual (one day the 'ENTRY' bit should be as well...). So we use term codes. So if we agree that 'mostly' we want those meanings defined, then the question is: which places doesn't it matter? I would say: places where it's obvious, like ELEMENT.value: DV_TEXT. My view has always been that we would avoid at-codes in locations where the meaning is obvious (principally for single-valued attributes, where the archetype meaning is the same as the RM meaning). The other reason for that is to limit the length of paths for Xpath processing. Unnecessary codes can double the length of some paths. If we go the other way, then we are saying: at-codes are 100% mandatory everywhere, but definitions for them are optional. Then we need some rules on when it is optional and when mandatory. What rules would you propose for that? Remembering that a clinical modeller absolutely relies on those rules for understanding the archetype? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/52af4bf5/attachment-0001.html>
