The need to express things like the Barthel sum of scores, or other multi-attribute constraints is already part of ADL. It is not yet well supported in tools, but it is parsed in at least the ADL Workbench. As I said before the language of these expressions is pretty close to Xpath, partly based on work done by the Zilics guys in Sao Paulo. Xpath provides the first order predicate logic operators you need with paths to reference the model elements. ADL 1.5 is adding more power.
I thought we had more or less agreed that GUI hints / transformation logic etc would no be in archetypes per se, because it complicates things to make one artefact do 2 jobs (e.g. it would mean published archetypes had to be revisioned when some obscure element of a GUI mapping was changed). So we are still looking for the right formal way to achieve this job. This doesn't mean it should not be done - just that it needs its own artefacts. - thomas On 23/03/2011 11:33, gjb wrote: > On 23/03/2011 11:54, Diego Bosc? wrote: >> I was saying that because some of the conditions Thomas said are >> really clinical knowledge. I want to be able to express that one value >> should be always greater than another, or that a score value of a >> scale (norton, barthel...) is the addition of other parts of the >> archetype. That's what I think should be put on the archetype. >> >> I agree with you that GUI should not be on the archetype > For me an avenue of clinical knowledge discovery should also be the > ideas arriving from UI design - constraints revealed at the UI level > may sometimes generalise in unseen ways and so should be able to > inform the archetype at some time or another. > I share Diego's "disappointment" in that openEHR seems to > discourage the activity that many programmers adhere to: > looking for generalization in your code and treating them as > discovered knowledge about the domain. > > In practice, there is a natural barrier between archetype and code > since ADL is a declarative language unlike most C, Python, Java etc. > Trying to express complex co-occurence constraints in ADL is always > going to look ugly and be difficult for non-programmer humans to > parse/deal with. > > Nevertheless, for me, this meeting point between archetype and GUI > constraint asks to be a fertile area of research - HCI at its most > profound IMHO - not to be left to terminology services. > > [just my 2 cents] > Gavin Brelstaff - CRS4 > * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/7cf0c4e2/attachment.html>
