Hi Heath,
Maybe semantics is not the right word for it, but it is what would help
me/my code easily express that the interest is in a particular element,
given a bunch of options. The lack of node identifier is thus at least lack
of information, if not semantics.
Not to suggest that you're wrong in this specific example, but the
following quote from page 47 of the adl 1.5 spec makes one inclined to
assign the responsibility of expressing semantics to node identifiers, or
at least that is my impression:
"The node identifier also performs a semantic function, that of giving a
design-time meaning to the
node, by equating the node identifier to some description"
Maybe I've incorrectly generalized this statement.
Kind regards
Seref
On Wed, Aug 15, 2012 at 1:10 AM, Heath Frankel <
heath.frankel at oceaninformatics.com> wrote:
> 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-bounces at 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****
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120815/fed7489e/attachment.html>
