You will have to excuse my failing eyesight - I read 'legal_entity'
not 'legal_identity'. I realise now that Sebastian was referring to
the has_legal_identity() function in the invariants of ACTOR. I
think there is a problem in the model here - we either should get
rid of this function, as Sergio suggests, or else we need to add
something more to the model, so that the function can indeed be
impelmented in a reasonable way. Which we do depends on whether we
think it is reasonable to force all ACTORs (in all openEHR
demographic data, forever!) to have a 'level identity'. This is the
debate we need to have. My feeling today is that it is probably too
restrictive.
- thomas
On 31/08/2010 11:16, Thomas Beale wrote:
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
|