Skip to Navigation | Skip to Content

Ref_impl_Java mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

RE: Adding a new method to the Archetype class


Thanks a lot Thomas,

Sometimes I'm a little hard-to-understand things, thanks for the patience :D

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?


Best Regards,
Pablo.




Date: Fri, 29 Jan 2010 10:33:00 +0000
From: thomas.beale@oceaninformatics.com
To: ref_impl_java@openehr.org
Subject: Re: Adding a new method to the Archetype class

On 29/01/2010 06:03, pablo pazos wrote:
Hi Thomas,

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).

- thomas



Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
_______________________________________________
Ref_impl_java mailing list
Ref_impl_java@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java