Hi Seref/Thomas,
Node IDs at0022 and at0023 have no semantic significance, they are just a
value of a speed limit element no matter if they are in km/h or mph. These
are just alternative value constraints on the value due to different units
allowed and range when using that unit. When you query you would want to get
all speed limit values and if you needed to compare then you need to convert
based on the units.
The instance should actually look like the following
items = <
["1"] = < -- ELEMENT
archetype_node_id = <"at0004">
value = < --
QUANTITY
units = <"mph">
magnitude = <25>
>
>
["2"] = <....>
etc
>
However, one area that is problematic is in the validator, how do we know
which constraint we should use when the constraints are ambiguous. The
example provided previously does no have this issue but if you consider an
element with an alternative values of type DV_TEXT allowing free text and
DV_CODED_TEXT in some specified terminology.
ELEMENT[at0004] matches {
value matches {
DV_TEXT matches { * }
DV_CODED_TEXT matches { -- km per hour
defining_code matches { |SNOMED-CT::| }
}
}
}
This cases doesn't require at-codes because they are different types, but
they are still ambiguous due to the inheritance allowing any coded term to
be used, not just the specified term.
Here it would be nice to have an at-code in the instance to differentiate
which alternative is being used.
Heath
From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Wednesday, 15 August 2012 2:07 AM
To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?
On 14/08/2012 10:34, Seref Arikan wrote:
Greetings,
According to adl 1.5 document on the openEHR web site (issued 25 Jan 2012),
Section 5.3.6.3, the runtime paths for single valued attributes can omit
node identifer.
The example given in the document uses miles per hour and km per hour
alternatives. The thing is, if the runtime path is what is going to be
persisted (and I can't see any other practical cases), the persisted data
will have no information to mark the semantics of the selection of an option
among alternatives.
actually, this text is a bit misleading. If we have the archetype
ELEMENT[at0004] matches { -- speed limit
value matches {
QUANTITY[at0022] matches { -- miles per hour
magnitude matches {|0..55|}
property matches {"velocity"}
units matches {"mph"}
}
QUANTITY[at0023] matches { -- km per hour
magnitude matches {|0..100|}
property matches {"velocity"}
units matches {"km/h"}
}
}
}
then the data instance created from the at0022 form of the QUANTITY will be
(in dADL):
items = <
["1"] = < -- ELEMENT
archetype_node_id = <"at0004">
value = < --
QUANTITY
archetype_node_id = <"at0022">
magnitude = <25>
>
>
["2"] = <....>
etc
>
so the path items[at0004]/value[at0022] will choose the quantity, although
items[at0004]/value would do just as well. (Remember, the Xpath equivalents
are items[@archetype_node_id='at0004']/value[@archetype_node_id='at0022']
etc - the [at0022] is just a shorthand selection predicate.)
The paths are not 'persisted' as such - just the data. The paths are always
derivates of the data.
In case of a query such as get me all Xs where value is expressed as km per
hour, the system can not know what which option was used: kmph or mph,
because there is not node identifier.
in this case, use the path items[at0004]/value[at0022].
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120815/affa5946/attachment-0001.html>
