Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

Hi Thomas,

I actually didn't even consider the fact that DV_QUANTITY didn't have a node
ID property, but good point. My point was that the units property provides
the information required to determine if a speed limit value was mph or
km/h.

 

Not sure I like the idea of adding the property attribute to DV_QUANTITY,
this is metadata that can be derived from the archetype if required but I
just don't see the use case.  I think we have more than enough metadata in
the instance already.

 

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 8:02 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?

 

On 15/08/2012 01:10, Heath Frankel 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.


Hi Heath,

you are no doubt assuming that the 'QUANTITY' type in the RM doesn't carry
archetype node+id information, which is indeed the case for DV_QUANTITY as
used in openEHR, but I was not assuming that for the example. In that case
you are right of course - querying would have to take account of it in
another way. One thing we potentially should do is include the 'property'
attribute in DV_QUANTITY, for just this purpose. 

I will add something to the documentation to indicate these subtleties.




 

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.


as it happens, due to another discussion I have already changed this rule to
say force at-codes even if the RM types are different under a single-valued
attribute. This will be annoying for some current archetypes, but that's
life.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120816/b44b1d59/attachment-0001.html>

Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

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
 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 wi

Should not node identifiers in runtime paths be mandatory?

[Thomas Beale]

On 15/08/2012 01:10, Heath Frankel 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.
>

Hi Heath,

you are no doubt assuming that the 'QUANTITY' type in the RM doesn't 
carry archetype node+id information, which is indeed the case for 
DV_QUANTITY as used in openEHR, but I was not assuming that for the 
example. In that case you are right of course - querying would have to 
take account of it in another way. One thing we potentially should do is 
include the 'property' attribute in DV_QUANTITY, for just this purpose.

I will add something to the documentation to indicate these subtleties.

> 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.
>
*
* as it happens, due to another discussion I have already changed this 
rule to say force at-codes even if the RM types are different under a 
single-valued attribute. This will be annoying for some current 
archetypes, but that's life.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

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">
>   

Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

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>

Should not node identifiers in runtime paths be mandatory?

[Thomas Beale]

On 14/08/2012 21:42, pablo pazos wrote:
> Hi Thomas, thanks for the answer. (now I see the problem of doublign 
> the number of node ids)
>
> I understood the Seref's problem as a case that could not be decided 
> automatically by a system, i.e. when to use and when not use the 
> nodeID to query and to get the desired node.
>
> Re-reading your response, I believe this should be part of the specs 
> as a rule: "...in this case, use the path 
> items[at0004]/value[at0022]...", i.e. when you have alternatives but, 
> in the data, one of them was choosen.
>
> What do you think?
> *
> *

Pablo,

yes, I will add this in.

thanks

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

Hi Pablo,
My problem was not what you've described. I thought there was a gap in the
spec that let data exist without a node Id when there is need for one. That
was not the case.

As long as the archetypeNodeId is in the data, there is no need for a rule
that enforces node id based path usage, because node Id is there to find
out if necessary.

(this is not the easiest thing to communicate over e-mail :) )

All the best
Seref


On Tue, Aug 14, 2012 at 9:42 PM, pablo pazos  wrote:

>  Hi Thomas, thanks for the answer. (now I see the problem of doublign the
> number of node ids)
>
> I understood the Seref's problem as a case that could not be decided
> automatically by a system, i.e. when to use and when not use the nodeID to
> query and to get the desired node.
>
> Re-reading your response, I believe this should be part of the specs as a
> rule: "...in this case, use the path items[at0004]/value[at0022]...", i.e.
> when you have alternatives but, in the data, one of them was choosen.
>
> What do you think?
>
> --
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos <http://twitter.com/ppazos>
>
> --
> Date: Tue, 14 Aug 2012 19:44:53 +0100
>
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
> Subject: Re: Should not node identifiers in runtime paths be mandatory?
>
> On 14/08/2012 18:46, pablo pazos wrote:
>
>  Hi Thomas,
>
>  Just thinking...
>
>  Why not make node ID mandatory for all nodes?
>
>  Since this will be handled by tools, I don't see the point of having to
> worry about if the node has an id or not: the tool just put some node ID on
> each node and us as developers use that fact to query and process data. It
> seems so much simple to have only one criteria, and we don't lose
> flexibility or expresiveness.
> *
> *
>
>
> Hi Pablo,
>
> the reasons we make it optional in cases where it is not needed:
>
>- there are huge numbers of chains of leaf nodes near the periphery of
>most models, where every attribute has only a single object value (have a
>look at any ELEMENT node and below in any archetype); node_ids serve
>absolutely no purpose in these locations, but could easily double the
>number of ids in the model - and for each of these, some definition has to
>be invented. These 'junk' definitions would confuse translators who would
>never be sure what has to be translated and what not.
> - it would increase the size of most paths used in real querying,
>because they nearly always have things like /value/value, or
>/value/magnitude on the end.
>
> So it actually creates problems without solving anything (for example, it
> has no impact at all on Seref's problem). The rules for knowing when they
> are needed are simple and published, and easy to implement, so it's no
> problem for tools.
>
> - thomas
>
>
>
> ___ openEHR-technical mailing
> list openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> 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/20120814/ffc235d9/attachment.html>

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

Thank Tom,
Somehow the text gave me the impression that use of archetype Node Id was
optional, which is clearly not the case.

Kind regards
Seref


On Tue, Aug 14, 2012 at 5:37 PM, Thomas Beale <
thomas.beale at oceaninformatics.com> wrote:

>  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: 

Should not node identifiers in runtime paths be mandatory?

[Thomas Beale]

On 14/08/2012 18:46, pablo pazos wrote:
> Hi Thomas,
>
> Just thinking...
>
> Why not make node ID mandatory for all nodes?
>
> Since this will be handled by tools, I don't see the point of having 
> to worry about if the node has an id or not: the tool just put some 
> node ID on each node and us as developers use that fact to query and 
> process data. It seems so much simple to have only one criteria, and 
> we don't lose flexibility or expresiveness.
> *
> *

Hi Pablo,

the reasons we make it optional in cases where it is not needed:

  * there are huge numbers of chains of leaf nodes near the periphery of
most models, where every attribute has only a single object value
(have a look at any ELEMENT node and below in any archetype);
node_ids serve absolutely no purpose in these locations, but could
easily double the number of ids in the model - and for each of
these, some definition has to be invented. These 'junk' definitions
would confuse translators who would never be sure what has to be
translated and what not.
  * it would increase the size of most paths used in real querying,
because they nearly always have things like /value/value, or
/value/magnitude on the end.

So it actually creates problems without solving anything (for example, 
it has no impact at all on Seref's problem). The rules for knowing when 
they are needed are simple and published, and easy to implement, so it's 
no problem for tools.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Should not node identifiers in runtime paths be mandatory?

[pablo pazos]

Hi Thomas, thanks for the answer. (now I see the problem of doublign the number 
of node ids)
I understood the Seref's problem as a case that could not be decided 
automatically by a system, i.e. when to use and when not use the nodeID to 
query and to get the desired node.
Re-reading your response, I believe this should be part of the specs as a rule: 
"...in this case, use the path items[at0004]/value[at0022]...", i.e. when you 
have alternatives but, in the data, one of them was choosen.
What do you think?
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Tue, 14 Aug 2012 19:44:53 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?


  

  
  
On 14/08/2012 18:46, pablo pazos wrote:



  
  
Hi Thomas,



Just thinking...




Why not make node ID mandatory for all nodes?



Since this will be handled by tools, I don't see the point
  of having to worry about if the node has an id or not: the
  tool just put some node ID on each node and us as developers
  use that fact to query and process data. It seems so much
  simple to have only one criteria, and we don't lose
  flexibility or expresiveness.

  

  
  



Hi Pablo,



the reasons we make it optional in cases where it is not needed:


  there are huge numbers of chains of leaf nodes near the
periphery of most models, where every attribute has only a
single object value (have a look at any ELEMENT node and below
in any archetype); node_ids serve absolutely no purpose in these
locations, but could easily double the number of ids in the
model - and for each of these, some definition has to be
invented. These 'junk' definitions would confuse translators who
would never be sure what has to be translated and what not.

  
  it would increase the size of most paths used in real
querying, because they nearly always have things like
/value/value, or /value/magnitude on the end.

So it actually creates problems without solving anything (for
  example, it has no impact at all on Seref's problem). The rules
  for knowing when they are needed are simple and published, and
  easy to implement, so it's no problem for tools.


- 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/20120814/ce4701d7/attachment.html>

Should not node identifiers in runtime paths be mandatory?

[Thomas Beale]

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: 

Should not node identifiers in runtime paths be mandatory?

[pablo pazos]

Hi Thomas,
Just thinking...

Why not make node ID mandatory for all nodes?
Since this will be handled by tools, I don't see the point of having to worry 
about if the node has an id or not: the tool just put some node ID on each node 
and us as developers use that fact to query and process data. It seems so much 
simple to have only one criteria, and we don't lose flexibility or 
expresiveness.


-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Tue, 14 Aug 2012 17:37:02 +0100
From: thomas.be...@oceaninformatics.com
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/20120814/7dc4acc2/attachment.html>

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

To comment on my own query:
Section 5.3.12 of the same document says that node identifiers are
mandatory for the case I've referred to in 5.3.6.3, but there is no
explicit metion of runtime paths. So does this rule cover runtime paths
too? I think it should, not due to ambiguity, but due to loss of semantics

Regards
Seref


On Tue, Aug 14, 2012 at 10:34 AM, Seref Arikan <
serefarikan at kurumsalteknoloji.com> 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.
>
> 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 decision support/ machine learning use cases, having different units of
> measurements would lead to mayhem etc etc.
>
> So there is a potential loss of information here, in exchange for
> flexibility, but what is the use of that flexibility? Should not the node
> identifier be mandatory in runtime paths when there is a decision among
> alternatives?
>
> Kind regards
> Seref
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

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.

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 decision support/ machine learning use cases, having different units of
measurements would lead to mayhem etc etc.

So there is a potential loss of information here, in exchange for
flexibility, but what is the use of that flexibility? Should not the node
identifier be mandatory in runtime paths when there is a decision among
alternatives?

Kind regards
Seref
-- next part --
An HTML attachment was scrubbed...
URL: