Dear All Thank you very much for your responses. Please see below:
Regarding this issue as being practical or theoretical: It emerged from a very practical need: 1) To do anything meaningful with Archetypes (or Templates) you have to parse the AM. Consider for example constructing a GUI from an Archetypes "definition" attribute. 2) If an Archetype references another Archetype (through the use of SLOTs), this reference would sooner or later have to be "followed" (to create the GUI or populate the SLOT "branch" of the data structure) Now, if during this process, there is a condition that can make a system unstable (the existence of cycles)...I would like to know :-). All the same, if the model designers have been "one step ahead", having acknowledged that it is possible to be "caught in a cyclic reference" but are prohibiting this condition...then i would also like to know :-D Please note, that it's not necessary that someone has "evil intentions" to do this. A cyclic reference, if it is allowed, could emerge purely by chance as archetype development proceeds independently by individual teams. This is what prompted me to examine the current library of archetypes for the existence of cycles (http://pastehtml.com/raw/bwlrjx8f3.html) @Seref: You are right, my starting point is the "Archetype", but the condition i describe can be realised with Templates as well (in fact, anything that can be described as an "ARCHETYPE_CONSTRAINT" (page 19 - AOM specs)). (Also, please see below) @Ian: The "rules about what slots are allowed, defined by the RM" is exactly what i had in mind as a "remedy" to this problem. I have indeed been focusing on the AM thinking that it reflects all the constraints of the RM. Having such rules in place is great! Because most of them imply that the RM is guaranteed to be a tree. I say most, because clearly the Sections(Sections, Entries) and Clusters(Clusters, Elements) can lead to cycles. Thanks for the reminder about Templates :-) . I have not been looking very hard into templates and these provide an extra layer of constraints i need to be aware as well. @Thomas: Your response covered me fully. As i said before, you don't have to be "highly automated" to run into this condition. To my understanding, if i define a SECTION once and attempt to re-use it through a SLOT, then there is a possibility that a cycle emerges. I am glad to see that ADL 1.5 will be much safer, although it means even more work on my side :-D All the best Athanasios Anastasiou On 30/04/2012 19:38, Thomas Beale wrote: > > Hi Athanasios, > > I have to admit, my initial reaction is that this a theoretical CS > problem that never occurs in practice, because the choosing methods for > slot fillers are normally clinically aware (assuming they are not > already prevented by RM type violations). This makes me think that you > are doing some highly automated potential slot-filling algorithm that > tries to guess all possible data paths allowed by the slot definitions. > When you get down to CLUSTERs, things could in theory become recursive, > leading to graph cycles. > > If this is the case, I think it is dangerous with the current slot > semantics. The slot semantics that are being defined for ADL/AOM 1.5 > <http://www.openehr.org/wiki/display/spec/Towards+a+definition+of+%27slot%27+semantics> > are much safer, being based on concept subsumptions rather than on > lexical matching. Therefore, for now, I would avoid any overly > mechanistic approach to trying to generate out possible data > constructions because the needed information is not in the current slot > definitions. > > - thomas > > On 30/04/2012 16:51, Athanasios Anastasiou wrote: >> Dear all >> >> I am coming back to this issue of interpreting and following Archetype >> Slots with a simple (i hope) question. >> >> How are we supposed to handle cyclic references created by Archetype >> Slots? >> >> There are quite a few places where cycles might come up, first of all, >> getting the RM from the AM, building the GUI and finally even up to >> the complex issue of creating and executing queries. >> >> As we clarified earlier there are mainly two flavours of slot binding: >> a) Formal, >> b) Recommendation >> >> My understanding of the "Formal" slot binding is that the slot would >> have to be filled explicitly by one of the archetypes that are >> determined by the include / exclude criteria. >> >> In most of the cases of the archetypes that are available through the >> CKM*, the formal binding does not lead to any cycle formation. >> >> However, it is much easier to create cycles with a "Recommendation" type. >> >> For example, i can specify something like this: >> A->B->A >> >> That is, [...an archetype (of some kind A) including a slot that >> accepts a generic archetype (of some kind B) including a slot that can >> accept...]* >> >> And that's the shortest cycle that would create a problem...It is of >> course possible that longer cycles could emerge unknowingly to authors >> as the archetype creation process proceeds by various teams >> independently. >> >> >> Therefore, what i would like to ask is the following: >> >> 1) Is there a recommendation for avoiding cycles? (For example, one >> could say that "you can't attach an archetype of the same or higher >> level (of datatype) to a slot". In this way, a CLUSTER would only be >> allowed to reference ELEMENTs. This is guaranteed to lead to a tree >> but reduces the flexibility of the model) >> >> 2) Is this kind of reference something to be expected when modelling >> clinical data? (In other words, it's actually a use case and you can't >> prohibit it, so you have to watch for it) >> >> 3) While creating the RM / GUI / other artifact, am i expected to >> follow all links exhaustively in order to create a Tree through which >> i would first detect cycles, resolve them and THEN create the final >> version of the RM? >> >> (Please note, "fudging" this, by resolving slots lazily is not an >> option :-). For example, i could create a GUI with all available >> information and a "Fill This Slot" button at the slot. Once you click >> the button another form is created which collects the data for the >> attached archetype. In this case, the algorithm did not hit a "loop" >> but the user eventually will because "new buttons" for filling in data >> will keep coming up in new forms.) >> >> Looking forward to hearing from you >> Athanasios Anastasiou >> >> *: My XML parser (built out of the openEHR XSDs) kept complaining >> about the structure of a few XML files downloaded from the CKM, >> therefore, it was not possible to include all of them to this "cycles" >> investigation. >> >> >> >> >> >> >> >> >> On 12/04/2012 17:44, Thomas Beale wrote: >>> On 12/04/2012 17:20, Athanasios Anastasiou wrote: >>>> >>>>> BTW, these lexical rules are historical, and will be obsoleted one >>>>> day - >>>>> I more or less had to construct them after 100s of archetypes that >>>>> actually assume these rules had been built! You will see further >>>>> down in >>>>> the ADL 1.5 text an indication of the future, but for today, we are >>>>> stuck with the above... >>>> Oh joy. (Yes, i did notice that part in the text, it will make the >>>> constraint more strict but inserts yet more parsing). >>>> >>>> Is there a single BNF description of ADL 1.5 available from somewhere? >>>> * >>>> * >>> >>> yep, they are here >>> <http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars> >>> >>> - fairly standard .y and .l files. >>> >>> - thomas >> > > > -- > 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/> > > > * > *
