On 24/05/2010 10:01, Rong Chen wrote: > Hi Thomas, > > I like the idea to generate specialized at-code when occurrences is > changed. This is especially useful when an optional-multiple node > [0..*] from a parent archetype is specialized into several single > required nodes in a child archetype or a template. Without this rule, > the only way to reach these specialized nodes is by using a path with > a combination of the original at-code and a name predicate. Something > like the following:
as soon as a parent node is specialised into multiple children in a specialised archetype, all of the children have to carry specialised at-codes anyway, to satisfy the basic rule that all sibling nodes of the same reference class under a particular attribute must always be distinguishable on node id. > > ".../items[at0004 and name/value='specialized node one']" > ".../items[at0004 and name/value='specialized node two']" > > Note that this path is language-dependent thus not very useful if we > want to build queries that could be used independent of language > translations. the above kind of thing happens (to my knowledge at least) only when multiple instances of a given node defined in a system of archetypes and templates, are created at runtime. These are then only distinguishable by name or some other attribute. The current rule in openEHR is that the name field has to be made unique across children of an attribute; this needs to be relaxed so that name only needs to be unique across those siblings having the same at-code. Now, one of the big changes in ADL 1.5 is that anything you change in a template (+/- the discussion we are now having about occurrences etc) forces a new at-code specialisation, just like in an archetype, whereas in the current de facto template standard, it doesn't - a lot of overriding of the name field is done in current templates. So a large proportion of his problem will go away with ADL 1.5. > > With this rule of enforcing specialized at-code in the child > archetype, the same paths could look like these: > > ".../items[at0004.1]" > ".../items[at0004.2]" > > and they are not bound to any specific language, which means queries > built on these path will survive in different language translations. > > Besides, having specialized at-code in child archetypes and templates > can facilitate archetype/template comparison(as Sebastian rightly > pointed out) and archetype/template-based data validation based on our > implementation experiences. yes, this was one of the motivations to change the templates design to force at-code specialisation just as for archetypes. In ADL 1.5, a template really is a kind of archetype. > > In fact, I would like to go further on simplification of the rules > around at-codes - that is to separate the structural and semantical > roles of at-codes. Currently these node identifiers have two very > different tasks: 1) to differentiate nodes by unique at-codes so > archetype paths can be built unambiguously; 2) to serve as a handle > for semantic definition. Because of this mixture of two types of > concerns, the discussions on whether or not we need an at-code become > unclear and sometimes overloaded. > > If we could separate these two roles of at-codes, the considerations > could be simpler. Effectively what I am proposing here are 1) at-code > (plain or specialized) is required whenever a node needs to be > uniquely identified through a path without involving a > language-dependent label; 2) only if the node needs to be semantically > defined or re-defined, the same at-code could appear as part of the > term_definition in the archetype ontology. I started having similar radical thoughts over the last few weeks as well. I am not yet clear in my own mind how to define the criteria for when an at-code needs a definition in the ontology, so that tools could police it. But if we could come up with something here, it could be very useful indeed; under the current rules, all at-codes have to appear in the ontology. Actually, I am inclined to stick to this rule in the literal sense, since weakening it will break everyone's tools and certainly the reference compiler; instead maybe we could have a standard way of defining the 'text' and 'description' fields for 'non-semantic' at-codes (e.g. you could imagine having no 'description' at all for non-semantic at-codes). Now, just to take the devil's advocate position, an ontological analysis would probably find that 'everything is semantic' and has to be defined/redefined accordingly. Anyway, I am interested in more ideas on this issue, if anyone has them. > > If the proposed rules are followed, it becomes easier to decide on the > use case of specialized nodes. The same goes for whether or not to > introduce new at-code for multiple choice of different data types > defining a single RM attribute. In both cases, we do need extra > at-codes because we want to reach them by a path without > involve language-dependent text. yes, I agree - we need to minimise this. It will still happen a bit, but the other way to look at it is that with a single path (not containing any name/value='x') you might just get back >1 data node, which is not wrong either. > > Because of the proposed rule 2, the burden to define each every > at-codes in the ontology is gone. The concern over adding "superfluous > codes in the archetype ontology" is not relevant in the considerations > any more. A nice side-effect of this rule is that we can now remove > some of these meaningless codes about "tree/list/table" in the > archetype ontology and their translations. =) the latter are already removed automatically in the ADL 1.5 compiler - by removing the at-codes from the nodes completely, since they are not required, and they make paths longer and harder to understand. With respect to having some nodes with an at-code but nothing in the ontology, I would need to see some rules that can actually work for this. - thomas * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100524/78a7b2ab/attachment.html>
