Hi!
Regarding annotations for GUI hints...
On Sun, Jan 2, 2011 at 20:41, Thomas Beale <
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 above) also covers the
"organisation sections" requirement mentioned by Sam?
Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110103/84f42c85/attachment.html>
