Hi Athanasios,
I would agree with Seref. Remember that we largely use templates to resolve
when and how slots are actually filled in real use. Even when slots are
left open and filled at run-time this is going to be for specific uses,
rather than some sort of algorithimic slot-filling.
There are rules about what slots are allowed, defined by the RM.
Compositions
-> Sections
-> Entries
Sections
-> Sections
-> Entries
Entries
-> Clusters
-> Elements
Clusters
-> Clusters
-> Elements
On 30 April 2012 17:32, Seref Arikan <serefarikan at
kurumsalteknoloji.com>wrote:
> Hi Athanasios,
> I have a feeling that you're facing a problem due to your particular
> implementation approach. I can't fully understand your problem, but it
> sounds like you're doing everything based on archetypes.
> Remember that you also have templates. Almost everybody instinctively
> writes code that walks archetypes and creates GUI during runtime, when they
> first start working with openEHR. It almost sounds like you're doing
> something like this.
>
> If you can explain the specifics of your problem with a little bit more
> detail, it would be easier to help.
>
> Kind regards
> Seref
>
>
> On Mon, Apr 30, 2012 at 4:51 PM, Athanasios Anastasiou <
> athanasios.anastasiou at plymouth.ac.uk> 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-**TemplatesandSpecialisedArchety**
>>> pes-Parsergrammars<http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars>
>>> >
>>> - fairly standard .y and .l files.
>>>
>>> - thomas
>>>
>>
>> ______________________________**_________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.**openehr.org<openEHR-technical at
>> lists.openehr.org>
>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/5ce60ae6/attachment-0001.html>
