Hi Seref, Not sure I understand your point anymore.
The quote you have reference seems to indicate that it is part of a greater explanation of the purpose of node ID. Semantics is one, and as a distinguisher is another. For me, the speed limit example is the second and because DV_QUANTITY has a unit property that provides the querying requirement you are looking for there is no need for the node ID to be provided in the instance, which as Thomas points out doesn't exist. The free text/coded text example, which Ian constantly battles with, is one case where the distinguish does add value to a validator, but again we have nowhere to put. Heath From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Seref Arikan Sent: Wednesday, 15 August 2012 6:47 PM To: For openEHR technical discussions Subject: Re: Should not node identifiers in runtime paths be mandatory? 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-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 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120816/ec8708f2/attachment.html>
