path of ArchetypeInternalRef

[system]

How is the path to an ArchetypeInternalRef constructed so that it is
pssible that it points to some ohter point in an archetype, and at the
same time is identifiable as being an unique point in the archetype.

For example:

I have contacts in an archetype, and these have addresses, for
efficiency-reasons the addresses are defined only once in the archetype,
like this:

addresses cardinality matches {0..*; ordered} matches {
                    ADDRESS[at0006] matches { -- phone number
                        type matches {
                            CODED_TEXT matches {
                                code matches {[ac0006]} -- phone
number
                            }
                        }
                        details matches {
                            allow_archetype LIST matches {
                                include
                                    id matches {"some.other.archetype.*"}
                            }
                        }
                    }

In this case the path to details is:
/contacts[at0005]/addresses[at0006]/details

Then I have this construct

addresses cardinality matches {0..*; ordered} matches {
                    use_node ADDRESS /contacts[at0005]/addresses[at0006]

The path of addresses will be in this case: /contacts[at0009]/addresses
I will, when I dig into this, also have a details-attribute, but what
will be the path then of it?
Two simple possibilities have disadvantages
- replace the first part of the path, like this:
/contacts[at0009]/addresses[at0006]/details
- do not replace the first part, which leaves the original path of the
item referred in tact.

The first seems to have disadvantage that the second part of the path is
not a followable path, because it makes a jump somewhere in the middle
and has no indication that it does.

The second solution as bad, because it makes Items to have a non-unique
path.

So I prefer the first solution, my question, are there any agreements on
this, i did not find them. If there are, please excuse me for not
looking at the right place.

[Lisa_Thurston1 (Lisa Thurston)]

Hi Bert

First I don't think an archetype path that goes inside an ARCHETYPE_SLOT
is meaningful because from the point of view of an archetype you don't
know what (if anything) will go into that slot. For an archetype path
that goes into a referenced node, I think it is helpful to imagine the
referenced node being completely cloned and replacing the internal ref
(after all we are dealing with references to constraints here, not
references to objects). Then the path should be
<path_to_location_where_ref_is_created>/<sub_path_within_referenced_node>.
Does that make sense?

Lisa

Bert Verhees wrote:

[system]

Hi Bert

First I don't think an archetype path that goes inside an ARCHETYPE_SLOT
is meaningful because from the point of view of an archetype you don't
know what (if anything) will go into that slot. For an archetype path
that goes into a referenced node, I think it is helpful to imagine the
referenced node being completely cloned and replacing the internal ref
(after all we are dealing with references to constraints here, not
references to objects). Then the path should be
<path_to_location_where_ref_is_created>/<sub_path_within_referenced_node>.
Does that make sense?

Hi Lisa,

Thank you very much for thinking with me about this. It is important for
me to make a good decision, because, at this moment, these days, I am
working on this.

I think it makes sense, it is in fact what I am thinking, it is just that
I need confirmation if it is OK what I am thinking.

About your suggestion about the internal_ref I have a remark, because, if
you construct the path like that, and which seems logical, it is not
possible to distinguish in the path, or from the path, that it contains a
reference.

So in my example the path would be:
/contacts[at0009]/contacts[at0005]/addresses[at0006]
This would suggest that there exists a contacts inside contacts, other
examples (not repeating the same rm-reference) could even be more
confusing.

So replacing the second contacts by the first is another option, like this
/contacts[at0005]/addresses[at0006]
would become this:
/contacts[at0009]/addresses[at0006]
Maybe in this constructs also are problems of which I haven't thought of,
yet. How are other implementers doing this?

I wonder, is there no specification/rule about this? Shouldn't there be
one, maybe in the context of having an open standardized platform where
third parties can connect to, and understand the objects they get from a
system?

About the archetype-slot, I will come back to that later.
Maybe it is OK to leave the path just as it is, a path can only be
meaningfull inside a single archetype. Maybe it makes sense to add the
connected arcehtype to the original path of the archetype slot.

Thanks,
Bert

[Lisa_Thurston1 (Lisa Thurston)]

Hi Bert

Bert Verhees wrote:

About your suggestion about the internal_ref I have a remark, because, if
you construct the path like that, and which seems logical, it is not
possible to distinguish in the path, or from the path, that it contains a
reference.
  

Does this matter? Anything that handles these paths (eg a "Get ADL Node
at Path" function) should be able to find the targeted node whether it
goes through an ARCHETYPE_INTERNAL_REF or via the more common
C_COMPLEX_OBJECTs.

So in my example the path would be:
/contacts[at0009]/contacts[at0005]/addresses[at0006]
  

Perhaps I misunderstood you. I think it would be
/contacts[at0009]/addresses[at0006] because your reference is to the
addresses node, not contacts node.

This would suggest that there exists a contacts inside contacts, other
examples (not repeating the same rm-reference) could even be more
confusing.

So replacing the second contacts by the first is another option, like this
/contacts[at0005]/addresses[at0006]
would become this:
/contacts[at0009]/addresses[at0006]
Maybe in this constructs also are problems of which I haven't thought of,
yet. How are other implementers doing this?

I wonder, is there no specification/rule about this? Shouldn't there be
one, maybe in the context of having an open standardized platform where
third parties can connect to, and understand the objects they get from a
system?
  

The relevant documents don't make this explicit to the best of my
knowledge. The ADL1 spec has a section on "ADL paths"
(http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/adl.pdf
section 5.3.7, section 7) and the Architecture Overview mentions paths
in archetypes and templates too
(http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf
section 10.5).

About the archetype-slot, I will come back to that later.
Maybe it is OK to leave the path just as it is, a path can only be
meaningfull inside a single archetype. Maybe it makes sense to add the
connected arcehtype to the original path of the archetype slot.
  

While I still don't think there should be paths going inside archetype
slots, there is a question of what the path should be when you are
talking about a path within a template. This is a bit more complicated
to answer because there is no template spec yet, but in general I think
the same approach can be taken as with the internal refs.

I have created in-memory flattened AOM representations of templates
which add the definition.attributes of the referenced archetype as
attributes of a new C_COMPLEX_OBJECT that becomes a sibling of the
ARCHETYPE_SLOT. Imagine we did this for a template made from your
archetype, with a CLUSTER.address_details.v1 archetype in the details
slot. To get to the first item in your address details you'd end up with
the path /contacts[at0009]/addresses[at0006]/details[at0001] where the
at0001 of details is actually identifying the first one of the items
nodes under the definition of a referenced CLUSTER.address_details
archetype.

Hope that is more helpful than confusing.

Lisa

[system]

Hi Lisa, please read my comments below

Lisa Thurston schreef:

Hi Bert

Bert Verhees wrote:

About your suggestion about the internal_ref I have a remark, because, if
you construct the path like that, and which seems logical, it is not
possible to distinguish in the path, or from the path, that it contains a
reference.

Does this matter? Anything that handles these paths (eg a "Get ADL Node
at Path" function) should be able to find the targeted node whether it
goes through an ARCHETYPE_INTERNAL_REF or via the more common
C_COMPLEX_OBJECTs.

No, it does not matter, the only problem is that must be standardized, because “path” is an important item to uniquely identify the location of a node inside an archetype.
Because, as I understand, in internal_ref situations, the archetype_node_id is not unique.
Because, in my example, (I go back some days)

(excuse my too simple use of ADL)

[Heath_Frankel3 (Heath Frankel)]

Bert,

There is no unique identifier within an archetype but every node within an archetype has a unique path. This is why paths are used in the internal_ref. Your paths must start at the root of the archetype and should not go beyond the archetype (i.e. the node being reference must already exist in the archetype). Have a look at the Blood Pressure archetype to see how internal_ref is used. As Lisa suggested, paths are explained in the Architecture overview, section 13 from memory. I personally don’t see any issue with referencing a archetype slot, I would suggest that it would just mean that we are using the same slot constraints, but you would not be able to traverse through the slot into an included archetype node.

Heath

[system]

Thanks Heath, for trying to explain to me.

It is still not clear to me, please allow me one question.

Since archetype_node_id's are not unique inside an archetype, even paths
are not unique, from a programmers point of view:

Please correct me if I am wrong.
There is only one way to create the data-set which represents the
archetype, that is
Take the root object from an archetype (which is the locatable
rm-object), and iterate to the properties, on an object oriented way,
not necessarily using the archetype_node_id's

That is OK, but my question is then:
what is the function of the archetype_node_id?

That I don't understand

Thanks
Bert

[Heath_Frankel3 (Heath Frankel)]

Bert,
Paths are unique, they must be.

The archetype node ID provides you a link to the ontology to give you the
semantics, this is fundamental to Archetypes.

Heath

[system]

Heath Frankel schreef:

Bert,
Paths are unique, they must be.
  

I thought so too, that is why it seemed more logical to me to store the
path, instead of the archetype_node_id in the locatable/pathable
But I read in the Architecture Overview section 11.2.4 that even paths
are not guaranteed uniquely, for that purpose, the name-attribute of a
node can be used.

I have never seen an archetype which uses the name-attribute of a node.
The ADL-example in the document is not very clear.

When I look in the ADL-specs, part 5.3.6, it states more or less in
contradiction to the above mentioned document, a path must be
unambiguous, and that this is achieved by different archetype_node_id's

So not the archetype_node_id's have to be unique, but the path must be.
So we come to another function of the archetype_node_id

The archetype node ID provides you a link to the ontology to give you the
semantics, this is fundamental to Archetypes.
  

That is true, I thought of that, but that is no reason to store them in
the Locatable/pathable-object. They can not identify the location in an
archetype of a data-object.
The only reason for existence I can think of and you mention, is in the
archetype itself.

This all does not seem logically to me, I can live with that, but it
wonders me, I can misunderstand: What are the design thoughts behind?

Thanks
Bert

[Heath_Frankel3 (Heath Frankel)]

Bert,
Archetype paths are unique. Data paths are not necessarily unique with
archetype_node_id alone, this is why you need to add a name/value to the
node predicate. Section 11.2.4 is referring to data paths.

In the case of archetype internal ref, you use archetype paths, which are
unique.

Heath

From: Bert Verhees [mailto:bert.verhees@rosa.nl]
Sent: Wednesday, 12 December 2007 6:44 PM
To: heath.frankel@oceaninformatics.com; For openEHR technical discussions
Subject: Re: path of ArchetypeInternalRef

Heath Frankel schreef:
> Bert,
> Paths are unique, they must be.
>
I thought so too, that is why it seemed more logical to me to store the
path, instead of the archetype_node_id in the locatable/pathable
But I read in the Architecture Overview section 11.2.4 that even paths
are not guaranteed uniquely, for that purpose, the name-attribute of a
node can be used.

I have never seen an archetype which uses the name-attribute of a node.
The ADL-example in the document is not very clear.

When I look in the ADL-specs, part 5.3.6, it states more or less in
contradiction to the above mentioned document, a path must be
unambiguous, and that this is achieved by different archetype_node_id's

So not the archetype_node_id's have to be unique, but the path must be.
So we come to another function of the archetype_node_id
> The archetype node ID provides you a link to the ontology to give you

the

[system]

Heath has said it how it is:

Archetype paths - that is the path to each node in an archetype - is unique. This is what the ADL statement you have seen refers to.

In data, in contrast, an individual archetype node which has occurrences set as (1…2) in the archetype could exist twice in the data. That is what occurrences of 2 means. How then to differentiate between the two instances of this node. The answer is in the name of that thing - which can be coded or free text. What this means is that you can ask for something in the data as a specific instance (unique) which may have a name in the path as well as the archetype_node_id’s - for example:

/items[at0002 and name/value=“xxx”]

or as a path as in the archetype

/items[at0002]

which will return all instances of the node.

Both paths transform to XPath in a very straightforward manner and give the same results.

Hope this is helpful.

Cheers, Sam

Bert Verhees wrote:

(attachments)

[system]

Sam Heard schreef:

Heath has said it how it is:

Archetype paths - that is the path to each node in an archetype - is
unique. This is what the ADL statement you have seen refers to.

In data, in contrast, an individual archetype node which has
occurrences set as (1...2) in the archetype could exist twice in the
data. That is what occurrences of 2 means. How then to differentiate
between the two instances of this node. The answer is in the name of
that thing - which can be coded or free text. What this means is that
you can ask for something in the data as a specific instance (unique)
which may have a name in the path as well as the archetype_node_id's -
for example:

/items[at0002 and name/value="xxx"]

or as a path as in the archetype

/items[at0002]

which will return all instances of the node.

Both paths transform to XPath in a very straightforward manner and
give the same results.

Hope this is helpful.

Thanks Sam, for explaining, so, if I may resume:

If you have a node in your ADL
/items[0002]

and you have a node
/items[0003]

and /items[0003] contains a Internalref to items/[0002], what will be
the ADL-path?

My guess is, in cADL it will be /items[0003] (because, that is the
location of the internalref)
In data it will be /items[0002] with a "name"-qualifier.

Is that correct?

Thanks, Bert

[system]

Thanks Bert

The path has to be unique - generally if an internal ref is used then it will be at a different path in the archetype so the name qualifier is not required (ie it will have a name but it will not be required to address it) Names are only required at points in paths where the node_id is repeated at the same level. So /items[at0002]/items[at0003] will only need a name qualifier in the path if there are more than 1 items[at0003]. As I have said, usually an internal ref (reuse of a node within the archetype) will be in a different place (such as /items[at0004]/items[at0003].

Cheers, Sam

Bert Verhees wrote:

(attachments)

[thomas.beale]

Bert Verhees wrote:

Sam Heard schreef:
  

Heath has said it how it is:

Archetype paths - that is the path to each node in an archetype - is
unique. This is what the ADL statement you have seen refers to.

In data, in contrast, an individual archetype node which has
occurrences set as (1...2) in the archetype could exist twice in the
data. That is what occurrences of 2 means. How then to differentiate
between the two instances of this node. The answer is in the name of
that thing - which can be coded or free text. What this means is that
you can ask for something in the data as a specific instance (unique)
which may have a name in the path as well as the archetype_node_id's -
for example:

/items[at0002 and name/value="xxx"]

or as a path as in the archetype

/items[at0002]

which will return all instances of the node.

Both paths transform to XPath in a very straightforward manner and
give the same results.

Hope this is helpful.
    

Thanks Sam, for explaining, so, if I may resume:

If you have a node in your ADL
/items[0002]

and you have a node
/items[0003]

and /items[0003] contains a Internalref to items/[0002], what will be
the ADL-path?
  

the paths /items[at0002] and /items[at0003] always stand for themselves.
The latter would not be able to have an internal reference to the
former, because that would imply that the latter information structure
could contain the former as a sub-structure. You can always work out
what internal references are valid by imagining how the archetype would
like by not using one, and just expanding out a copy of the part you
want. Use the Archetype workbench to see the paths that result from
internal references - e.g. have a look at Apgar result and BP
measurement, to name two.

- thomas

[system]

the paths /items[at0002] and /items[at0003] always stand for themselves.
The latter would not be able to have an internal reference to the
former, because that would imply that the latter information structure
could contain the former as a sub-structure. You can always work out
what internal references are valid by imagining how the archetype would
like by not using one, and just expanding out a copy of the part you
want. Use the Archetype workbench to see the paths that result from
internal references - e.g. have a look at Apgar result and BP
measurement, to name two.
  

Thanks, Thomas, this is a very helpful tip.

Bert