Hi! Ok, if implementation experience says it is better to have separate sections for human readable annotations and machine-targeted "program directives" then I guess that is a good approach. Are there any tools that support this now?
If going for an RDF-like URI based approach for "program directives" or "implementation_directives" then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.) I assume "program directives" will include both pass_through and more purely GUI-oriented directives. Will they contain everything annotation/directive-like that is intended to be machine processable and human language independent? Is that a correct and shared view of the purpose? Are both "annotations" and "program directives" supposed to be attributes of the class AUTHORED_RESOURCE? I don't find them in the current http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdfbut I guess that might be a matter of time constraints - or are they going to be only a part of AOM/ADL itself? I just want to check what the future thoughts are. Is "program directives" the best name? "Annotations" is very a very generic and useful name, but that word is already taken for the human readable stuff. Could anything from the following list inspire somebody with a more native feel for English to come up with alternate name suggestions? - directives (shorter and more general than "program directives"). - instructions - notes - meta...something - commands - processing... - triples - links - extensions - ... Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Tue, Jan 31, 2012 at 00:07, Heath Frankel < heath.frankel at oceaninformatics.com> wrote: > Hi Erik, > No problem with your RDF approach but I agree with Thomas that the purpuse > of view directives. (or more generally, program directives) is very > different from annotations. XML Schema separates these two concepts. > Ocean has reused annotations in the template designer for these kind of > directives for some time as well as the hard coded hide-on-form, and it is > from this experience that we have proposed this separate section. > Heath > On 31/01/2012 8:12 AM, "Erik Sundvall" <erik.sundvall at liu.se> wrote: > >> Please rewind to >> http://www.openehr.org/mailarchives/openehr-technical/msg05530.html and >> the followup messages in that thread. >> >> Using an RDF like URI-based approach still seems to be an option. No >> registering hassle or new sections in adl, just alternate use of the >> existing annotation section. >> >> // Erik >> Den 30 jan 2012 14:31 skrev "Thomas Beale" < >> thomas.beale at oceaninformatics.com>: >> >>> On 30/01/2012 03:16, Heath Frankel wrote: >>> >>> Hi Pablo,**** >>> >>> ** ** >>> >>> If I understand correctly, the pass_through attribute is only for data >>> displaying on a screen (as you mention the use for data grouping or >>> collapsing). If that's right, I don't think that should be part of the >>> generic template structure, because templates are meant to represent other >>> elements than data views/GUI, like messages, reports, etc.**** >>> >>> ** ** >>> >>> No, that is not what I are saying. I are saying it can be used for more >>> than display purposes such as data views, messages, reports etc.**** >>> >>> ** ** >>> >>> As you mention " screen layout and binding are consistent with the XML >>> schema or class it will bind to" I feel maybe this is a little attached >>> to Oceans implementation, e.g. in our implementaition we don't have binding >>> with XML Schemas .**** >>> >>> ** ** >>> >>> Ocean doesn?t bind to XML schema either, I used this as an example of >>> why you may want to ensure your presentation view is consistent with a data >>> view derived from the same template artefact.**** >>> >>> ** ** >>> >>> The use of the annotation-like structure for view directives allows us >>> to separate these kind of directives from true annotations and the data >>> definition itself whilst providing flexibility for specifying a set of >>> directives that we know of now but may improve on later such as >>> pass_through, add to in the future, and also use in local environments. We >>> need to remember that templates where inteded for local use cases but are >>> now also becoming important at jurisdictional levels for shared use. >>> >>> >>> Heath, >>> >>> the options for passthrough today (ADL/AOM 1.5) seem to be the following: >>> >>> - leave it where it is today, specified on C_COMPLEX_OBJECT >>> - move it to be an annotation within the new annotations section of >>> ADL 1.5 archetypes, with a key such as 'view_directive' >>> - create an entirely new section, structured the same (?) as the >>> annotations section, within the archetype for view / other directives >>> >>> The potential problems with including a new view-directives section >>> within archetypes include: >>> >>> - it makes the archetype dependent on those directives. They would >>> need to be limited to universal directives, because most UI/presentation, >>> as well as other implementation directives are locally specific, and >>> there >>> can clearly be more than one, for a given archetype. >>> - we don't yet know what structure such a directives section should >>> really take >>> >>> Potential benefits: >>> >>> - the section can be specified within the AOM & ADL docs, i.e. no >>> new specs required >>> - making a new section in archetypes & templates means that we >>> don't need any new tools to process these directives - the main archetype >>> compiler would do it >>> - we could make it so that *applying more local directives was done >>> by defining correct inheritance rules for the implementation-directives >>> section* - i.e. use inheritance >>> >>> As I think about this, I am starting to be persuaded that continuing to >>> use inheritance to achieve local additions and overrides is a good thing - >>> it works for the rest of the archetype. If we commit to this path, the >>> remaining question is: is the current annotations section structure >>> sophisticated enough to contain implementation directives? An example of >>> the annotations section from a current test archetype is as follows: >>> >>> annotations >>> items = < >>> ["en"] = < >>> items = < >>> ["/data[at0001]/items[at0.8]"] = < >>> items = < >>> ["design note"] = <"this is a design note on >>> allergic reaction"> >>> ["requirements note"] = <"this is a requirements >>> note on allergic reaction"> >>> ["medline ref"] = <"this is a medline ref on >>> allergic reaction"> >>> > >>> > >>> ["/data[at0001]/items[at0.10]"] = < >>> items = < >>> ["design note"] = <"this is a design note on >>> intelerance"> >>> ["requirements note"] = <"this is a requirements >>> note on intolerance"> >>> ["national data dictionary"] = <"NDD ref for >>> intolerance"> >>> > >>> > >>> ["/data[at0001]/items[at0002]"] = < >>> items = < >>> ["design note"] = <"this is a SPECIALISED design >>> note on Statement"> >>> ["NEW TAG"] = <"this is a SPECIALISED design >>> note on Statement"> >>> > >>> > >>> > >>> > >>> > >>> >>> So let's imagine that a new section could be of a similar structure. The >>> first thing to note is that it is path-based. Is this sufficient? For now, >>> I will assume it is. Secondly, do we need multiple languages? I would >>> assume not, since we are now talking about computable strings rather than >>> human-consumable strings. The tags will obviously be different. Here is a >>> possible example. >>> >>> *implementation_directives* >>> items = < >>> ["*/data[at0001]/items[at0.8]*"] = < >>> items = < >>> ["*presentation*"] = <"*pass_through*"> >>> ["*querying*"] = <"*something_else*"> >>> > >>> > >>> ["*/data[at0001]/items[at0.10]*"] = < >>> items = < >>> ["*presentation*"] = >>> <"*widget_type*=*smart_text_coded_selector >>> (args...)*"> >>> > >>> > >>> > >>> >>> The blue tags would have to be controlled somehow by agreement, and >>> would define the possible 'implementation directives' that could be stated. >>> The green values, or 'flags' could potentially also be controlled. The red >>> part in the last one illustrates an example whereby the value is a piece of >>> syntax (it could be a function call, or something like a Javascript >>> expression). If the value space for a given 'flag' is controlled (e.g. >>> 'widget_type' always = some javascript expression) then we have enabled >>> some formal computing elements to be used, as are likely to be required for >>> implementation. >>> >>> It seems clear to me at least that there would not be many of these >>> implementation directives on international archetypes, but national and >>> local archetypes, and particular templates would potentially have many. >>> >>> We would need to establish basic rules like: >>> >>> - tag names come from a) a central controlled vocabulary and >>> additionally b) local values being allowed >>> - this could be done by registering the vocabularies at different >>> jurisdictional levels. Initially, I think we could just work off a >>> central >>> wiki page, with perhaps a few key tags defined in the AOM spec itself >>> (if >>> we can figure them out in time) >>> - values could also potentially be defined in this controlled >>> vocabulary, i.e. in the form >>> - tag1 = value1 | value2 | value3 etc >>> - or in other ways, e.g. tag1 = string; javascript syntax >>> - specialised archetypes and templates could override the value of >>> an existing tag with another legal value for that tag >>> - but we probably need to allow locally defined values as well >>> for tags with a fixed value set >>> - specialised archetypes and templates can add directives containing >>> new (locally-defined) tags and values >>> - there may need to be a way to 'remove' a tag setting from an >>> archetype >>> >>> This is obviously pretty 'soft' computing, and therefore open to some >>> dangers, but if we manage it as a community in a sensible way, it could >>> bring a lot of value. The use of specialisation to add new directives I >>> think is the key to making it work properly with respect to localisation. >>> >>> thoughts? >>> >>> - thomas beale >>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/859cea49/attachment.html>
