Hello, I totally agree. When we implemented the semantics of specialisation in LinkEHR-Ed we also took that decission. Since LinkEHR-Ed is mainly based on archetype specialisations, we always need to have identifiers for every node and for that reason we automatically complete every node with an internally generated [at-code]. In fact, we have never understood why the node_id attribute is mandatory in the C_OBJECT of the AOM but it is not in the ADL syntax.
2008/7/15 Thomas Beale <thomas.beale at oceaninformatics.com>: > > > In the current work I am engaged in to tighten up the semantics of > specialisation, we have the problem that if the above kind of constraint > were stated, and needed to be specialised in a child archetype, it is > difficult to achieve without [at-code] markers as we have on higher-level > nodes in archetypes. Currently, no at-codes are used on objects nodes > defining constraints on the ELEMENT.value attribute, becasuse none is needed > - it does not add anything useful, and would require pointless pollution of > the archetype ontology with obvious definitions like 'quantity constraint'. > However, in a very small number of cases, I believe that the above kind of > construction, using more than one alternative is actually used. To allow > specialised archetypes to redefine such constraints, we would need to > mandate the use of at-codes where such alternatives were created. > > If the impact was minimal, I would be tempted to propose that this rule be > added to ADL, to ensure that specialisation can always work unambiguously. > > any feedback on this idea welcome. > > - thomas beale > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20080715/6015f0bc/attachment.html>
