If I might ask a rather mundane technical question about archetypes ...
Looking at the archetype models, there appears to be no way to enforce that the class to be used for some specific piece of information is exactly that class and not one of its subtypes. For example, what if it is important to have a DVTime used and not a DVPartialTime? Or an ObjectRef that should never an AccessGroupRef or a PartyRef?
My feeling is that the class constraint in an archetype needs an additional property "subtypesAllowed" or similar to cater for the two cases.
Kerry
Dr Kerry Raymond
Distinguished Research Leader
CRC for Enterprise Distributed Systems Technology
University of Queensland 4072 Australia
Ph: +61 7 3365 4310, Fax: +61 7 3365 4311, www.dstc.edu.au
The archetype editor sets this constraint for dv_date_time using a syntax for the purpose.
At present the other reference model classes are not available in the same manner - that is they do not impinge directly on the data. Generally, one assumes that in the reference model people will use the actual classes specified.
I am sure Tom will have something to say on the matter!
If I might ask a rather mundane technical question about archetypes ...
Looking at the archetype models, there appears to be no way to enforce that the class to be used for some specific piece of information is exactly that class and not one of its subtypes. For example, what if it is important to have a DVTime used and not a DVPartialTime? Or an ObjectRef that should never an AccessGroupRef or a PartyRef?
My feeling is that the class constraint in an archetype needs an additional property "subtypesAllowed" or similar to cater for the two cases.
Hi Kerry,
there are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this. If on the other hand, there are circumsances where a Y is ok but not an X, then the underlying reference model should say so by modelling X and Y as disjoint subtypes of a common parent W.
A pragmatic approach would be to do what you say. We could probably argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out.
The purist in me says stick with the first way of seeing it; the realist says to consider the second. What do others think?
A pragmatic approach would be to do what you say. We could probably
argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out.
Yes, that's the angle I'm coming from (where we don't control the reference model).
And in any case, I don't see the openEHR following the purist road of having FullySpecifiedDateTime or ObjectIdThatIsntArchetypeIdNorTerminologyIdEtc
A pragmatic approach would be to do what you say. We could probably
argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out.
Yes, that's the angle I'm coming from (where we don't control the reference model).
And in any case, I don't see the openEHR following the purist road of having FullySpecifiedDateTime or ObjectIdThatIsntArchetypeIdNorTerminologyIdEtc
Absolutely!
Further, regarding the choice between a specific attribute that could be constrained and the disjoint inheritance modification suggested by Tom, I think the former would, in any case, be cleaner (I imagine we'd put it in the C_OBJECT class). There would be just this one place in the model to change rather than changing the inheritance everywhere where the more normal inheritance is used, and would have general applicability. The latter would probably also lead to a certain unwanted dissimilarity between the Archetype model and the Reference model in a few places.
Please also note (as Sam has just pointed out) that, in the latest Archetype Model, there is a full set of attributes in the C_ classes for dates and times that already allows very specific constraints to be placed on the parts.
Regards
David
Kerry
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
* David S.L. Lloyd, Technical Consultant
* CHIME - Centre for Health Informatics and Multiprofessional Education, at UCL
* E-Mail: d.lloyd@chime.ucl.ac.uk Tel: +44 (0)20 7288 3364
* Web: www.chime.ucl.ac.uk/~rmhidsl#contact
If I might ask a rather mundane technical question about archetypes ...
Looking at the archetype models, there appears to be no way to enforce that the class to be used for some specific piece of information is exactly that class and not one of its subtypes. For example, what if it is important to have a DVTime used and not a DVPartialTime? Or an ObjectRef that should never an AccessGroupRef or a PartyRef?
My feeling is that the class constraint in an archetype needs an additional property "subtypesAllowed" or similar to cater for the two cases.
Hi Kerry,
there are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this.
What I am wondering now is during automated object creation process, it has to be clear which concrete class to be instantiated - either X or Y ? Apparently the end user will not supply the class name to the system
My guess is that the choice has to be made before 'operational' archetypes are created based on some extra input from local settings, for instance a localized template.
The beauty of OpenEHR (and CEN/TC251 EN 13606) is the fact that we have a reference document model that because of its stability help store and retrieve persistent documents over long periods of time.
Being able to change the reference document model will create problems by to much divergence.
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
there are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this.
What I am wondering now is during automated object creation process, it has to be clear which concrete class to be instantiated - either X or Y ? Apparently the end user will not supply the class name to the system
My guess is that the choice has to be made before 'operational' archetypes are created based on some extra input from local settings, for instance a localized template.
it might be, it might also be decided dynamicaly by the application. A typical example is DV_DATE and DV_PARTIAL_DATE. It will only be known at runtime whether a DV_PARTIAL_DATE is needed - i.e. the user doesn't know the day for some particular date field in a screen form.
I think we will have to see implementation and application experiences to find out what is most common. Certainly it does need to be settable in templates.
A pragmatic approach would be to do what you say. We could probably
argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out.
Yes, that's the angle I'm coming from (where we don't control the reference model).
And in any case, I don't see the openEHR following the purist road of having FullySpecifiedDateTime or ObjectIdThatIsntArchetypeIdNorTerminologyIdEtc
nicely put;-). I have created a new change request for this. (New CRs will shortly be visible on the new openEHR CR tracker).
