Hi Sebastian and all, IMHO, I think that the invariant Legal_identity_exists: has_legal_identity is too restrictive, because it may happen that you may register a person without no known legal identity at the moment of registration. I think it should be removed from the reference model.
We also had to include the types of identity as a constraint in the name attribute because the rm demands it. Again I think this is too restrictive because we cannot register two identities of the same type because the name must be unique among siblings. I wonder why the name attribute should receive the type of the identity. If we remove these restrictions, the type of identity could be moved to a normal ELEMENT in the archetype. Cheers, Sergio On Thu, Aug 26, 2010 at 5:27 AM, Sebastian Iancu <sebastian at code24.nl>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? * > If you or somebody else can give some suggestion on this, I think it will > be much more easier to understand the concepts behind the demographic > package. > > Sebastian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100829/0b994953/attachment.html>
