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:
".../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. 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. 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. 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. 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. =) /Rong > > > On 21/05/2010 10:08, Sebastian Garde wrote: > > Hi Thomas, > > A few concerns that come to my mind - I am not so sure that > removing/changing this rule is a good thing: > > - It puts an additional burden on tools to support both ways of > creating a specialised node wither with or without specialised at code. > - It puts an additional burden on users that need to decide whether a > specialised node should be created because the semantics have changed - I > don't think this decision is always that clear cut. > - What if the non-semantically specialised node is LATER redefined into > multiple children? Then a new version of the archetype is needed instead of > just a revison? > - With the stricter rule it a lot easier to recognize what has changed > from parent to child archetype (this may not apply to 1.5 source ADL, but > to > the flat files anyway) > - In general, I believe that these validity rules should be simple and > straightforward, rather than complex "if this and that and then this, you > need a specialised code"-statements. > > > Sebastian > > Thomas Beale wrote: > > > I am in the middle of ADL/AOM 1.5 testing. There is a validity rule I > defined in the current draft specficatich reads as fllows: > > VSONIR: specialised archetype object node redefinition: if it exists, the > node identifier of an object node in a specialised archetype must be > redefined into its specialised form if either reference model type or > occurrences of the immediate object constraint is redefined. > > Translation: change of occurrences or change of RM type (e.g. redefine into > descendant type) requires a specialised at-code, e.g. at0002 --> at0002.1 or > similar. > > In processing real archetypes and creating new templates, I am inclined to > remove this rule, and say that the at-code only has to be specialised if the > archetype author wishes to do so for semantic reasons OR if the parent node > is redefined into *multiple* children (e.g. a node at0013 meaning 'panel > item' gets specialised into at0013.1 (serum sodium), at0013.2, (serum > potassium), at0013.3, etc). > > I will experiment with removing this rule for the moment, and see if > anything bad happens, but as far as I can see, nothing will. If we throw it > away, it means that at-code specialisation really is only for semantic > reasons, which would be nice and clean. > > I am interested in any opinions on this. > > By way of news: I am very close to a working implementation of AOM/ADL 1.5, > and will release a new version of the ADL Workbench soon/ > > - thomas beale > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at > openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > -- > [image: Ocean Informatics] *Thomas Beale > Chief Technology Officer, Ocean Informatics<http://www.oceaninformatics.com/> > * > > Chair Architectural Review Board, *open*EHR > Foundation<http://www.openehr.org/> > Honorary Research Fellow, University College > London<http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS, British Computer > Society<http://www.bcs.org.uk/> > Health IT blog <http://www.wolandscat.net/> > * > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100524/ec9dbafa/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100524/ec9dbafa/attachment.jpg>
