Following this new sense for it, I think that the implications for a GUI or visual representation would depend on a decision of the implementers. If the screen space is reduced, they could opt for just showing the “clinically relevant” data and leave the rest for a second screen, a pop-up or something like that.
2012/1/25 Diego Boscá <yampeku@gmail.com>
but they won't show everything on a 'full' GUI either. Maybe what is
needed is not only a boolean but a way to tell exactly the criteria
with different values of a controlled vocabulary, such as 'mandatory',
'recommended', 'passable'/'skippable'...
In fact, the “emphasis” attribute of 13606 is a CV.
2012/1/26 Diego Boscá <yampeku@gmail.com>
2012/1/25 Thomas Beale <thomas.beale@oceaninformatics.com>
Maybe another way of understanding this flag is as ‘this node can be skipped without loss of meaning’. I would be very interested to know if we should make AQL queries sensitive to this flag. Has anyone thought about that?
In this sense I can see the reason for this attribute, since it can be understood as part of the documentation of the clinical model. But definitely it is not clearly described at the specs since there it seems to be linked to the presentation template only.
I fact, there is a similar attribute in EN13606 ITEM class, but used in an opposite sense. The attribute is “emphasis” and it is described as “A way of denoting that the composer wished to mark this ITEM as being of particular note (an unusual measurement value, an unexpected outcome, anything that might be considered necessary to highlight to a future reader).”
I remember many arguments about that one in CEN meetings. It was intended originally to be used on text items.
I have never thought about this. I don’t know if this kind of annotations (“this item is important or clinically relevant or not”) better fits as part of the RM or part of the AOM. In other words, if this marker is related to a specific data instance or to a data item definition in an archetype.
well I am always suspicious of subjective markers like ‘important’ and so on. At least ‘pass-through’ is a mechanistic kind of concept. I agree that it has not been analysed properly though, and I think that can only be done in the clinical realm. At the moment, I think we need to support it because it is already in use in the .oet templates. The question is whether it turns out to have some proper semantic basis or is indeed ‘just presentation’. We should ask why it is there at all: the reason is that it deals with information nodes that are not needed cognitively (i.e. for human understanding) but are an unavoidable artefact of information trees - but only sometimes… as far as I know there is no reliable algorithm for removing these nodes from presentation.
I know that sounds logical but that is not the way clinical people use
this attribute. They look at certain archetypes and simply decide to add
it, with out regard for which particular device it is displayed on. For
them it is not optional to remove it or keep it - in a given archetype.
In other archetypes it is not used at all. I will try to obtain some
examples...
- thomas
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 intended for local use cases but are now also becoming important at jurisdictional levels for shared use.
I don’t believe that pass_through should be hard coded into the AOM. It should be in a more generic framework such as that I proposed in my previous email.
Heath
David,
Pass_through has no relevance to this emphasis concept in any way. It has been a means to collapse container attributes such as items when the hierarchical structure inherited from the RM or Archetype is no longer desired or relevant in a template perhaps because sibling items in a cluster or multiplicity has been constrained.
Heath
Hi Pablo,
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
Hi Erik,
your examples are:
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”>
…
These look reasonable to me. As you can see from the below, they have a different structure from the annotations section - which contains linguistic strings and a language subdivision. This would not be needed as far as I can see with implementation directives.
I don’t see any great problem in having a different section, given the purpose is quite different, and the flattening rules will probably be different (with annotations, the rule that makes sense is that the annotation for a given tag is concatenation with the value for that tag in a parent, whereas here, it would be replacement, i.e. override).
Using the RDF approach, the registering problem doesn’t go away, it just gets moved to a different (arguably better) place - a schema or ontology. Fine by me also.
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
Hi Thomas,
I think you’re going too far with this controlled key and syntax approach. The important thing at this point is we get a structure that we can start using to get more experience with. Although my proposal was a simple property value bag, I think your idea of a triplet is good, but we should do this using attributes rather than syntax. So a directive type, an name/ID and value attributes seems like a pretty powerful structure, its similar the Claim class in an Identity Model for authorisation (claim type, right, resource).
I think the majority of view directive use will be in templates at the local level, but certainly some directives are likely at the jurisdictional level (e.g. pass_through). For this reason, I think that we should not restrict the values to only controlled values, controlled values are only necessary for shared use and it is these that certainly need to have a registry. Erik’s RDF suggestion seems like a reasonable approach to doing this rather than openEHR inventing a new scheme. We need to support innovation in this area and hence allow local groups to use local directive type/identifiers/values at will and when they have something to bring back to the community somewhere to register and align their local directives with shared directives. A consumer should only need to process the directives it is interested in, unless we provide something like a must-understand attribute.
With regard to inheritance of directives, I think this needs to be based on the directive type. In some cases we will want an override, in others we would want addition or constraint. Not sure yet whether this needs to be specified in the directive or not so that the compile can generate the appropriate result or always have the complete set and leave the responsibility to the consumer to interpret the set.
I don’t think we need to make this too complicated at first, the main thing is to get the containment structure right, we can always add attributes such as must_understand and override mode to the directive class later.
Regards
Heath
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.pdf but 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@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
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?
well not today, but if we decide to specify this concept, I can implement it with examples in the reference ADL compiler very quickly. The code for more dADL sections is easy. Others are working in getting the Java parser up to ADL 1.5. Changes like this don’t make that much difference because they are just straight dADL => objects transforms.
If we specifiy and implement the outer structure I proposed, but don’t say anything about the tag or values, we can accommodate the RDF approach just as easily as anything else.
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 would opt for “implementation_directives”, less ambiguous.
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?
that’s my understanding. I don’t think anyone has any more than an ad hoc knowledge so far of what these things are likely to be, much less a structured theory about what should be included.
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.pdf but 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.
you can see annotations in section 7.1 of that doc. ‘implementation_directives’ I think should go on the ARCHETYPE class for now.
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?
well I think ‘implementation_directives’ says what we mean here, but it is annoyingly long, that’s for sure. I am fine with ‘directives’, as long as we define what this means in the documentation and everyone understands its scope. ‘processing_directives’ or ‘processing_instructions’ seem like reasonable synonyms, but are also annoyingly long. Does ‘processing’ on its own make sense?
Hi Thomas,
I think you’re going too far with this controlled key and syntax approach. The important thing at this point is we get a structure that we can start using to get more experience with. Although my proposal was a simple property value bag, I think your idea of a triplet is good, but we should do this using attributes rather than syntax. So a directive type, an name/ID and value attributes seems like a pretty powerful structure, its similar the Claim class in an Identity Model for authorisation (claim type, right, resource).
I think the majority of view directive use will be in templates at the local level, but certainly some directives are likely at the jurisdictional level (e.g. pass_through). For this reason, I think that we should not restrict the values to only controlled values, controlled values are only necessary for shared use and it is these that certainly need to have a registry.
Hi!
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 would opt for “implementation_directives”, less ambiguous.
In that part of the mail I was thinking of shortening serialisations of things like…
[“http://schema.openehr.org/GUI-v0_1#view”] = <“http://schema.openehr.org/GUI-v0_1#pass_through”>
…to something like…
[“gui:view”] = <“gui:pass_through”>
…by somewhere in the file defining
gui:
…to mean…
http://schema.openehr.org/GUI-v0_1#
// Erik
Erik,
which file do you mean here? Where is this alias?
Erik,
I suspect the only tools using this are the Ocean Template Designer in its Operational Template XML output which extends the release 1.0.x AOM. This is only the second time I have presented this proposal, last time we had this same discussion it got no traction.
The CKM uses the Ocean OPT to generate HTML documentation of templates and uses the pass-through directive to collapse insignificant containers.
There are a couple applications that use the Ocean OPT extensions of the AOM for GUI generation but not sure if the use this directive.
Our implementation simply uses views, but my suggestion that we may want to extend the scope to all program directives seems to have been accepted.
XML uses processing_instructions, not sure we need to worry about length, we haven’t until now and it only needs to be specified once.
Heath
Erik,
which file do you mean here? Where is this alias?
Oh, never mind, it was just a sidetrack, focus on other things if you don’t get it. Let’s not spend more email electrons, CPU cycles and brainpower on this part of the thread.
What I meant was that a serialized archetype- or template-file that uses a lot of similarly prefixed URIs could use internal aliases (defined in that specific archetype- or template-file) for long URI prefixes. This is done by many other RDF and XML serialization approaches to increase readability. But let’s not do anything like that for ADL now. Maybe those of us that are interested in e.g. XML and YAML (that already have built-in prefix/namespace mechanisms) could look at this later.
Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
that’s what I wanted to check. I expect it would be useful in ADL archetypes - essential, if we are going to connect semantic net to archetypes - we just need a bit more solid theory on some of this stuff, to see how it should be done. I would guess at least that the AUTHORED_RESOURCE class should have some generic schema namespacing / alias capability, which is easy enough to do.