Re: Run-time name constraints and appropriate use of terminologies

[Sergio Freire <sergiomfreire@gmail.com>]

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@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

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical