On 26/08/2010 09:27, Sebastian Iancu wrote: > Hi Ian, > > I was not thinking on names attribute of an archetype as holding more > than names. Yet, the demographic_im.pdf is suggesting/stating to use > them to associate a type meaning the the owner objects (i.e. things > like PERSON/name/value = "PERSON" or ROLE/name/value = "General > practitioner"), and for some objects the purpose() is designed that > way as well. > > As you previously said, there can be RM-types and Archetype-types and > the later is introduced in demographic package through this > construction of 'name' attribute. As long as the scope of that 'type' > is within (or related) that owner archetype domain I don't see any > problem, but if that that 'type' need used outside I don't really see > it working, without a proper coding system or at least a binding. > > Maybe I was not very clear in previous emails about my reasoning, > maybe I am just confused about specifications or about the modeled > archetypes on CKM, but nevertheless one of my main technical question > remains: > /how can a function like ACTOR.has_legal_identity() be implemented > regardless the archetypes being used? /
that can only be done if the concept 'legal_entity' is also hardwired into the information model, which is exactly what we are avoiding via the use of archetypes. A function like this would make more sense with a template-generated programming object, not the base RM objects. A template, based on specific archetypes might have a legal_entity defined somewhere, and this could be queried with a hardwired function. Otherwise the approach has to be to implement functions like this using AQL or similar queries that make use of paths from available archetypes. But in this case you would not be doing ACTOR.has_legal_entity, but a query over the whole demographic repository, or some subset of it, which searches for ACTOR objects containing the specific path. - thomas beale* * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100831/43e562ef/attachment.html>
