Erik, that's two innovative ideas in one post - you must have had a great christmas ;-) 1. in the 'languages' space, allow formalisms as well - e.g. "rdf" 2. the annotation structure, simple as it is, is in fact sufficient (or close) to support representation of RDF-like triples.
I can't really comment on these ideas other than to say they look quite interesting - I had not thought of either before. The main decision for the ADL 1.5 spec and implementation is: whether to stick with annotations as a hash of Strings, with String keys, or to make the keys some kind of codes, defined elsewhere in the archetype. At the moment I am inclined to leave it as all Strings, let people experiment with it, and decide to enhance it once people have messed around with it. Maybe Koray and other implementers might want to work on some of their own ideas, plus Erik's, within some archetypes. The next ADL workbench beta (any day now) will support String-only annotations, arranged per language as shown in an earlier post. We don't have an XML version of this yet, and would rather hold off on the XML version until we are more slid with the ADL version. But - advice, disagreement from others is welcome (or even better if others want to mess around with the XML on their own and feed it back in here). I propose to get the next beta out as it is (~ 1 week), with some example archetypes containing annotations, and see where we go from there. - thomas On 03/01/2011 13:58, Erik Sundvall wrote: > Hi! > > Regarding annotations for GUI hints... > > On Sun, Jan 2, 2011 at 20:41, Thomas Beale > <thomas.beale at oceaninformatics.com > <mailto:thomas.beale at oceaninformatics.com>> wrote: > > I still think this requirement is best solved by a design pattern > that is > > defined and that tools can trust - one that fits with the current > reference > > model. > > What about a design pattern borrowed from RDF, where > 1. the annotated archetype node has the same role as a RDF subject, and > 2. URIs are used as predicate (relationship type - the left hand part > of the ADL annotation) and > 3. URIs or RDF data types (including strings, numbers, booleans etc) > are used as objects (targets/values - the right hand part of the ADL > annotation). > > Such annotations would be intended for (human language-independent) > machine processing, perhaps that is not really the current intention > behind the human language-dependent annotation sections in archetypes. > > Using RDF-like notations would make it fairly easy to start with just > plain string matching in tools and then extend tooling support by > using available RDF or OWL toolkits to check e.g. allowed range for > certain predicates against e.g. a small GUI ontology. > > Technically the approach would of course not be limited to GUI usage, > but could be used for many kinds of machine processable annotations > (see example further down). > > Would it be possible to extend the "language" annotation group > subdivisions to not only allow language codes, but also include a set > of additional codes for machine processable formalisms where e.g. > "RDF" could be one? > > Some may argue that the Term_binding and Constraint_binding are more > appropriate places for connecting to ontologies - the difference from > the annotation approach is that the current *_binding design only > allows specification of a value not an annotation/predicate type. > Using a design pattern for annotations won't introduce changes to the > underlying model. > > In the thread "GUI-directives/hints again" we had a hypothetical > example... > > annotations = < > ["/data/items[at0003.7]/items[at0010]"] = < > items = < > ["GUI-show-if"] = <"$smoker"> -- Other annotation name examples: > GUI-hide-if ... > ["some other annotation"] = <"whatever"> > > ...with RDF-like annotations, some additional examples (and a wildly > guessed language subsection syntax) it might turn out something like... > > annotations = < > language = < > ["RDF"] = < > ["/data/items[at0003.7]/items[at0010]"] = < > items = < > ["http://schema.openehr.org/GUI-v0_1#show-if";] = <"$smoker"> > ["/data/items[at0004.8]/items[at0011]"] = < > items = < > ["http://schema.openehr.org/GUI-v0_1#view";] = > <"http://schema.openehr.org/GUI-v0_1#pass_through";> > ["http://s.skl.se/qualreg/diab/ v-3_1#q10.2"] = <" > http://s.skl.se/qualreg/diab/v-3_1#daily";> > ... > > ["en-UK"] = < > ["/data/items[at0003.7]/items[at0010]"] = < > ["some other annotation"] = <"whatever"> > > Perhaps the distributed nature of URIs (e.g. s.skl.se > <http://s.skl.se> above) also covers the "organisation sections" > requirement mentioned by Sam? > > Best regards, > Erik Sundvall > erik.sundvall at liu.se <mailto:erik.sundvall at liu.se> > http://www.imt.liu.se/~erisu/ <http://www.imt.liu.se/%7Eerisu/> Tel: > +46-13-286733 > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- 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/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110103/e1307c8b/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/20110103/e1307c8b/attachment.jpg>
