On 01/02/2019 14:53, Pieter Bos wrote:
About the calculation:
Ah, I see, the assignment seems like a good solution. But why would I
need a function to calculate a score that is just a sum of a number of
values, instead of a few +-operators?
well you might want to re-use that function. More generally, some
functions are more interesting, e.g. MAP calculation, and it is
potentially better to a) name them, b) declare them in a more obvious
place and c) make them re-usable.
Multiplicities/data binding:
The there exists case is clear. However, what if I have four events,
all having four elements, each with dv_quantity as value. Say I want
the magnitude of the last of these quantities to be larger than the
sum of the first three. Before I could write something like:
for_all $event in /data/events[id3]
$event/data/items/element[id6]/value/magnitude >
$event/data/items/element[id4]/value/magnitude +
$event/data/items/element[id5]/value/magnitude +
$event/data/items/element[id6]/value/magnitude
Assuming you meant to put 'id7' as the first one, I don't understand
what this achieves beyond just:
/events[id2]/data/items/element[id7]/value/magnitude >
/events[id2]/data/items/element[id4]/value/magnitude +
/events[id2]/data/items/element[id5]/value/magnitude +
/events[id2]/data/items/element[id6]/value/magnitude
which says the same thing, for all events in the runtime data that
conform to the /events[id2] branch of the structure.
If we were to allow the expression for_all $event in /data/events[id3]
then we need to be clear on what it means: it actually refers to an
object of type List<EVENT>, but do the members consist of EVENT objects
found in data at the moment the expression is evaluated? Or just the
statically defined members in the archetype - which can also be
multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min events?
Normally we want the processing of 'rules' expressions in archetypes to
apply to the data when the archetype is being used in its normal role of
creation / semantic validation at data commit time. So it seems to me
that if we want to support expressions like the above, we need to be
able to do something like (don't worry about the concrete syntax too
much, could easily be TS or java-flavoured):
*use_model*
org.openehr.rm
*data_context*
$xxx_events: List<EVENT>
$item_aaa, $item_bbb, $item_ccc, $item_ddd: Real
*definition*
check for_all event in $xxx_events:
event/$item_aaa > event/$item_bbb + event/$item_ccc +
event/$item_ddd
*data_bindings* -- pseudo-code for now
$xxx_events -> /events[id2]
$item_aaa -> /data/items/element[id7]/value/magnitude
$item_bbb -> /data/items/element[id4]/value/magnitude
$item_ccc -> /data/items/element[id5]/value/magnitude
$item_ddd -> /data/items/element[id6]/value/magnitude
I don't know what this archetype is, so assume that $xxx_events,
$item_aaa etc are more meaningful names.
The next problem you mentioned is:
PB: Note that a path that points to a single typed dvquantity in an
archetype can still point to many items in the RM if somewhere up the
tree there is a list or a set, for example more than one observation
So I think this implies an incorrect interpretation of this kind of code
within an archetype. It can't be understood as simultaneously applying
to multiple Observations if it is within an Observation archetype, only
to one OBSERVATION instance at a time - usually one about to be committed.
You can still have Lists of things internal to the archetype, as shown
above with the Events list, but to process the multiplicity, you would
need to do as we have done and use for_all, or some other
container-aware operator or function.
Anyway, does this get closer to the sense of what you would like to do?
It's more than I had conceived of, so this is a useful challenge...
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
