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 From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Bert Verhees Sent: Monday, 10 December 2007 11:22 PM To: For openEHR technical discussions Subject: Re: path of ArchetypeInternalRef 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) contact[0005].......... ......... addresses cardinality matches {0..*; ordered} matches { ADDRESS[at0006] matches { -- phone number contact[0009].......... ......... addresses cardinality matches {0..*; ordered} matches { use_node ADDRESS /contacts[at0005]/addresses[at0006] two paths pointing to the ADDRESS object /contacts[at0005]/addresses[at0006] and (as I think we agree which is the good thing (a little below in this email)) /contacts[at0009]/addresses[at0006] In both cases ADDRESS will have the same archetype_node_id: [at0006] Maybe I misunderstand some small but fundamentally issue: The path of a CObject, that is connected with a payload of an Locatable-Object in the persistence-database is important. Because, (in my opinion) an application must be able to locate a Locatable-Object inside an archetype, and how can it do that when it has no unique identifier pointing to location in an archetype 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. To avoid possible misunderstandings, I think: /contacts[at0009]/addresses[at0006] will be the best way to define the path for that object (pointed to by a internal_ref), I think you agree. If not, please tell me 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.p df 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). I think it is a good feature when path's are allowed to be meaningful. They add information to the system. Too bad if this possibility is not used, except when there are strong arguments against it. 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. My suggestion is that the path needs to go inside the archetype-slot, because, it is necessary to locate a Locatable to the right context. Specially because, more and more small parts of archetypes are used, as building blocs, the connected Locatables can loose their necessary context, afterwards. But this is only a suggestion, I am technician, not a medical-software-architect (I like to keep it that way) I understand in so far, that I, for the moment, avoid the use of Archetype_slots, because, it chances are small that I use them in a way that will later on appear in the specs, and it is possible to avoid the use, just a bit hairy <http://catb.org/jargon/html/H/hairy.html> . Thanks Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071211/d0bcfa73/attachment.html>
