I know that the nodeID attribute of CObject is used to distinguish between two sibling nodes, but when I create an archetype using the Ocean’s Archetype Editor, each node in the ADL has a different nodeID value, so we can use the nodeID to distinguish between all nodes in the archetype. So, is it right to think of adding a new method to the Archetype class to get a node from it’s nodeID? it’s like the node(path) method but node(nodeID). I think it’s easier to use nodeID instead of the node path, for example, if you have a RM object instance (rmIns) and the archetype (arch) that constraints this instance, with arch.node( rmIns.archetypeNodeId ) you’ll get the particular node that constraints the rmIns, so you can validate the rmIns against it’s constraints. I can’t find an easy alternative way to do this, I mean, walk through an RM instance and validate each node against the corresponding archetype nodes.
If each node has a unique id, this would work. But it's not guaranteed
that each node will have a id. Some leaf level nodes do not have any
node id at all. They will have to be located by path e.g.
"/items[at0001]/value"
I think I understand your point and Rong’s too, but I have some questions to you both.
If one constraint is reused inside the same archetype, all constraints with the same nodeID will be semantically equivalent, is this correct? So, in terms of semantics RM validation against an archetype node it will be the same if I check to one node or another (that have the same nodeID). I think this “post rm creation” kind of validation against an archetype is needed to make semantic interoperability work. May be my solution is not the optimal, but I think some kind of openehr protocol to do this is needed. For Rong’s point I suppose that if I have a RM node that don’t have a nodeID, this node must be a primitive node, because for ELEMENT, CLUSTER and ITEM_STRUCTURE, ENTRY, SECTION, etc, I think all had to have a nodeID. Correct me if I’m wrong.
Off topic: I’ve talked to Thomas telling him I’ve problems with Internal Refs nodeIDs, because when I load an ADL created by the Oceans Archetype Editor using the ADL parser from Java Ref Impl project, the nodeID attribute of the internal refs is null, I don’t know if this is a problem with the editor or is a problem with the parser. I can send you my test archetype to help you to take a look to this issue.
I think I understand your point and Rong’s too, but I have some questions to you both.
If one constraint is reused inside the same archetype, all constraints with the same nodeID will be semantically equivalent, is this correct? So, in terms of semantics RM validation against an archetype node it will be the same if I check to one node or another (that have the same nodeID). I think this “post rm creation” kind of validation against an archetype is needed to make semantic interoperability work. May be my solution is not the optimal, but I think some kind of openehr protocol to do this is needed.
the ‘meaning’ of a node is given by its path from the root, not just the node id. So you can have two nodes whose node_id is at0004 for ‘systolic pressure’, but the paths are as follows:
/data/events[at0006]/data/items[at0004] - human readable form: /data/events[any event]/data/items[Systolic]
/data/events[at0031]/data/items[at0004] - human readable form: /data/events[Postural change]/data/items[Systolic]
you can see here two different data points, both having node_id at0004, but the paths tell you the real meaning
For Rong’s point I suppose that if I have a RM node that don’t have a nodeID, this node must be a primitive node, because for ELEMENT, CLUSTER and ITEM_STRUCTURE, ENTRY, SECTION, etc, I think all had to have a nodeID. Correct me if I’m wrong.
the rule is that a node_id is needed:
on any node that is a child of a multiple-valued attribute (even if there is only one child for now)
any nodes of a single-valued attribute, where there are multiple alternative nodes, and they can’t otherwise be distinguished by RM type (e.g. DV_QUANTITY).
Sometimes I’m a little hard-to-understand things, thanks for the patience
The problem I found in our implementation is that we are not saving the AOM paths in the RM nodes. Now I’m fixing this bug.
For the issue with internal refs with no nodeID, do you have taken a look to this on the Archetype Editor?
Rong: are you aware of this possible issue on the ADL parser?
I was thinking about your example with blood presure:
/data/events[at0006]/data/items[at0004] - human readable form: /data/events[any event]/data/items[Systolic]
/data/events[at0031]/data/items[at0004] - human readable form: /data/events[Postural change]/data/items[Systolic]
You say that the meaning of each node is given by the path, because it determines the context of each node.
But if you have diferent meanings, I think that different ontology terms are needed for each node, but the ontology terms are indexed by the nodeID, instead of the node path.
I’ve an Instruction archetype with a constraint of DvText in the archetype, this example is like the one mentioned by Rong, this node has no nodeID, its path is /narrative, so I can’t find a term in the ontology to show the label for this field on the GUI, because I need the nodeID.
May be the ontology mapping must be something like ont[lang][pathToAOMNode] instead of ont[lang][AOMnodeID], What do you think?
Sometimes I’m a little hard-to-understand things, thanks for the patience
The problem I found in our implementation is that we are not saving the AOM paths in the RM nodes. Now I’m fixing this bug.
in my Eiffel implementation, I don’t save any paths. I can compute a path from any node back to the root (needs a ‘parent’ link) and the paths are cached in Hash tables on the ARCHETYPE object; if any part of the archetype structure is changed e.g. due to an archetype editor allowing cut & paste or whatever, these cached paths have to be re-computed.
For the issue with internal refs with no nodeID, do you have taken a look to this on the Archetype Editor?]
I was thinking about your example with blood presure:
/data/events[at0006]/data/items[at0004] - human readable form: /data/events[any event]/data/items[Systolic]
/data/events[at0031]/data/items[at0004] - human readable form: /data/events[Postural change]/data/items[Systolic]
You say that the meaning of each node is given by the path, because it determines the context of each node.
But if you have diferent meanings, I think that different ontology terms are needed for each node, but the ontology terms are indexed by the nodeID, instead of the node path.
the ontology section of the archetype defines the ‘meaning’ of each at-code. The meaning of each node is inferred from its path - i.e. you need to think of a path as a post-coordination of terms.
I’ve an Instruction archetype with a constraint of DvText in the archetype, this example is like the one mentioned by Rong, this node has no nodeID, its path is /narrative, so I can’t find a term in the ontology to show the label for this field on the GUI, because I need the nodeID.
well there are quite a few single-valued attributes in the model, like CARE_ENTRY.protocol, the narrative one you mention and so on. They don’t need at-codes, because they don’t have siblings - siblings can only exist under container attributes (like CLUSTER.items for example). So the correct path for an object under the ‘narrative’ attribute is simply ‘/narrative’ (relative to the Instruction root).
May be the ontology mapping must be something like ont[lang][pathToAOMNode] instead of ont[lang][AOMnodeID], What do you think?
the point of the ontology is to define the at-code meanings - as I say, the node meanings are inferred. Note that in the bindings section you can use at-codes or paths, enabling external terms to be bound to particular paths, e.g. 5 min ave systolic BP or so.
