On 20/12/2010 12:05, Erik Sundvall wrote: > Hi! > > On Wed, Dec 15, 2010 at 00:30, Thomas Beale > <thomas.beale at oceaninformatics.com> wrote: >> On 10/12/2010 08:49, Erik Sundvall wrote: >>> If the already present annotation mechanism in templates is powerful enough >>> (Do you think it is, Koray, Pablo and others?) >> to be clear, do you mean the annotations documented in the ADL 1.5 draft >> document? I.e. the new annotations section? > Yes, I was then thinking of section 9.8 in > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf > > When looking closer at this for GUI hint experimentation, perhaps we > could instead use a combination of annotations and the assertion/rule > mechanisms in ADL/AOM? The already present logic in the assertions > mechanism is probably enough to define e.g. Boolean trigger variables. > Annotations could then be used to let GUIs know what to do/show/hide > based on those triggers.
I will have annotations implemented in the next few days, with some test archetypes. We will put a release up in hopefully < 10 days, and people can play. BTW: the current draft online is incorrect: it misses a language level in the annotations structure (i.e. annotations are linguistic entities so they need to be defined under a specified language just like terms on the ontology section). The structure I implement will also be put online. Then all requests for change will be considered ;-) I have to beef up the implementation of the invariant (now called rules) section; then we can try to implement this example below... - thomas > Discussion examples follow (with the risk of ADL errors that Tom's > brain-integrated ADL parser :-) will catch and he then can correct) > > In section 6.5.4 of > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf > a way of defining variables is specified. > Perhaps a (preferably Boolean) variable could be defined as an > archetype rule like... > > $smoker:BOOLEAN ::= > /data/items[at0003.7]/items[at0009.3]/value/defining_code matches > local::at0013 > > ...and an annotation on a tree structure that should be shown in GUIs > only when documenting smokers could be... > > annotations =< > ["/data/items[at0003.7]/items[at0010]"] =< > items =< > ["GUI-show-if"] =<"$smoker"> -- Other annotation name > examples: GUI-hide-if ... > ["some other annotation"] =<"whatever"> > > ...or perhaps... > > annotations =< > ["/data/items[at0003.7]/items[at0010]"] =< > items =< > ["GUI-trigger"] =<"$smoker"> > ["GUI-action"] =<"show"> -- Other annotation value examples: > hide, collapse, expand > ["some other annotation"] =<"whatever"> > > I guess the mess starts if such annotations are to be overridden in > yet a specialization generation of the GUI-annotated > template/archetype. That would have to be analyzed further, but maybe > some refined variant of the examples above could be a useful start in > the mean time? > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 >
