Operand '/=' in rules section


On value dependent existence part of ADL 2 (the https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_value_dependent_existence) the example rule:

Substance_use: $substance_use_status /= [at17] implies exists /data[id2]/items[id8] – [at17] = 'never used'

contains a '/=', which is never used again in the rules specification or in the Expression Language and Model documentation.

Should '=' be used instead?




Thomas Beale
September 4, 2018, 4:32 PM

from memory, the /= (not equals) is used to say 'if this field value = anything except [code for never smoked], then the tobacco use details have to be filled in'. I think this is semantically the right way to state this kind of thing, at least for substance use.

The new expression spec will change the way this is done, to something like:

check ($is_smoker implies defined ($smoking_details))

Where $is_smoker and $smoking_details are bound to archetype paths or AQL queries. See the spec to see the current ideas on this: https://www.openehr.org/releases/BASE/latest/docs/expression/expression.html#_defined_predicate

Diego Bosca
September 5, 2018, 7:32 AM

If it's not equals (I assumed it was equals) then the symbol '/=' should be '!=' as stated in primitive operators https://www.openehr.org/releases/BASE/latest/docs/expression/expression.html#_primitive_operators

That's the thing I was pointing out (hence the 'trivial' tag).
Regarding the example itself, has more consequences the change from 'exists' to 'defined'?

Thomas Beale
September 5, 2018, 10:04 AM

Ah - yes, we had better make sure the symbols match
The previous way of just asserting 'exists' I think is problematic. What does exists mean in that context? The 'exists' quantifier in logic normally means that 'there is an x (possibly of type X) such that <some statement about x>'.

What we are really trying to assert that some particular data exists in the concrete real world sense, which does not seem like the same thing. Another way to look at it is: a Boolean valued data item at some path in an archetype can have one of two values, assuming it is defined. If not being defined is also a possibility, then we have 3-value logic (T, F, Unknown).

The idea is that the 'defined()' predicate makes this more explicit, rather than matching data items (not just Booleans) with proper values or some 'unknown' value, and also not subverting the standard meaning of the logical quantifier 'exists'.

EL is still a draft right now - so other ideas on this are welcome.


Diego Bosca