Hi all, Maybe this is OT but is related. I remembered a problem I had some time ago working with algorithms that traverses the archetype structure. For CObjects without nodeID, the path of the CObject is equal to the path of it's parent CAttribute, so when I want to get the node with that path using Archetype.node(path), only one of those nodes will be returned. Of course there are workarounds, like checking the type of the returned node, and if a CAttribute is returned but I want the CObject, I just get the node.children()[0]. But that only can be implemented if you know that the path you're using is a path to a CObject, so it depends on the context of your algorithm to expect CObject or CAttribute for a path you have (i.e. if you previously visit a CAttribute and you algorithm traverses from root to leaves, you'll expect next nodes to be CObjects). >From a developer point of view, having unique paths would solve a lot of >workarounds and ugly code. So having a nodeID for each CObject node is >something I would encourage on tooling. I really don't care of having more >terms in the ontology :)
-- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: dam...@gmail.com Date: Fri, 30 Aug 2013 08:27:39 +0200 Subject: Re: Polishing node identifier (at-codes) use cases. To: openehr-technical at lists.openehr.org 2013/8/29 Thomas Beale <thomas.beale at oceaninformatics.com> well the idea here has always been, and remains justified today: an archetype-local definition in words for the meaning of the node is needed, because this says _exactly_ what the designers intended those meanings are given by domain experts, and (with some review, QA process) will be as good as any linguistic definition in any ontology or terminology (probably better, because they are specific to the case at hand) if we are lucky enough to find some code that matches, or approximately describes the same thing in an ontology and/or SNOMED CT / LOINC etc, then we can add those bindings If we were only allowed to define nodes for which matching codes can be found in OBO, SNOMED or other supposedly reliable places, then we would have no chance of building anything but the most meagre archetypes, and no ability to build semantically enabled health information systems. I don't know of any facts that would contradict this long-standing position today... I'm not contradicting those positions, which I agree, I'm just saying that this is a very subjective topic, dependant on the context of use, the availability of some resources (e.g terminological codes) and many other factors. So, we can all do our best but it will be very difficult to have rules that guide which nodes of the archetype have to be identified just based on a structural matter (the rules you asked for). -- 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) _______________________________________________ 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/20130830/64b43b25/attachment.html>
