2013/8/27 Thomas Beale <thomas.beale at oceaninformatics.com> > > >> What is so wrong about having at-codes in every class of the archetype >> with no ontology definition for that code? >> > > interesting question - so far (10 years!) we have always treated an > at-code as something that is in the ontology. At the moment no tools at all > would handle the assumption that only some codes had definitions; it would > raise questions: how do you know which things need definitions and which > don't? My guess is that there would need to be a special definition that is > connected to the at-codes you want to have no definitions, which would > complicate the archetype ontology section structure. > > - thomas > >
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 -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/a5af394a/attachment.html>
