The semantics of archetype Specialization
Andrew The lab result is a good example of further constraining and it is really additional constraints. It is just that the at0013 (any data type) is labelled and turned into a quantity with units. It looks like extention but is it further constraint in this instance. However, we do extend archetypes - as Kerry says - as long as there are no surprises at runtime this is OK. So all the paths in the parent must do what they do in the parent. Cheers, Sam Hi Grahame and Health, It seems that Sam is working by a philosophy of extension in his archetypes. For example, take lab result, which is an entry level archetype that has a list of coded result values. The lipids labs result archetype seems to extend the existing archetype by create new fields for cholesterol, triglycerides, etc, rather than further constraining the existing coded result values in the lab result archetype. I am not sure specialization by extension is applicable to the archetype specialization case. Archetypes works by constraining the reference model. Therefore, any further specializations of an archetype may only further constrain what the parent archetype supports. For example, the lipids lab result archetypes should have further restricted the lab result archetype to have contained coded fields for cholesterol, triglycerides, etc. -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 2:21 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew If the language only makes positive structural statements, such as standard 3gl o-o paradigms, then specialization cannot be done by restriction - while there's nothing stopping it, there's no way to express it. (Though reference Heath's email - there's various ways to actually do it, but many of them result in ill-formed models, just the compiler doesn't know how to stop them, therefore they are legal) If the language is able to make constraint statements, then specialization can be done by both restriction and extension - but restrictions in the generalization will prohibit some forms or instances of both extension and restriction in the specializations. ADL is able to make both positive structural statements and constraint statements, so it's able to support specialization by extension and restriction. But I think, due to the nature of ADL, that there is no computationally provable answer to whether any given specialisation is properly formed (at least in the general case). Many of the stupid things about XML Schema arise because they have a requirement (I think), that there must be a computationally provable answer. Grahame Andrew Goodchild wrote: I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific
The semantics of archetype Specialization
Andrew We are not able to implement specialisation as I would like - true O-O would be better - so the child has all the features of the parent at the outset - though the editor knows a little about what is going on. Try renaming - you have to specialise the concept (shadowing in O-O), but you can move it about with impunity. This should not be allowed if the archetype is ordered. Until we get an editor that can cope with specialisation in the o-o paradigm (which is well beyond my technical skill) we will have to make do with what we have. Cheers, Sam I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
Hi Andrew The principles of specialisation have been described in our development environment and there is a placeholder for the documentation in the archetype system document. Our initial thoughts are at: http://www.deepthought.com.au/it/archetypes/output/specialisation.html The rules that we are working with but are not fully embodied in the editor are: An archetype that is a specialisation of a parent contains data with archetype node IDs that conform to that of the parent. This means that: 1) All paths mandatory in the parent are present in the child 2) All paths optional in the parent may be present in the child, and if so will have the same path The meaning of any element or cluster expressed in the parent is preserved in the child (although it may be narrowed). If it is not identical then it will have an id that is a specialisation of the parent id. at0001 - at0001.1 Optional elements (and clusters) in the parent do not have to be available in the child. New elements can be available in the child - their meaning is guaranteed to be different than that included in the parent. They have a code that identifies the level of specialisation, and these may be specialised in subsequent children. A new id at level 0 is at0001, a new id at level 1 is at0.1, a new id at level 2 is at0.0.1. The editor enforces most of these, but specialisation of clusters (allowed in the laboratory archetype) introduces issues. These rules do need documentation and it would be helpful to have others think about this. Cheers, Sam Hi, Does anyone know what it actually means to specialize an archetype? And what the rules are? I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don?t exist as optional fields in the parent archetype To me this particular example is not safe as one of the basic rules of specializing archetypes is you should be able to validate any new specialized EHR data against the parent archetype. -Andrew - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
There are two kinds of specialisation, subtyping, inheritance
(whatever you like to call it). One that relates to re-use of an
existing definition during development, and the other that relates to
substitutable behaviour at run-time.
It's nice during development to be able to construct types using the
hard work you've already done before (I'd like it like a video store
rental but instead of DVDs, I'll be renting crutches). And this could
appear to be the motivation behind the cut-n-paste philosophy of the
archetype editor. However, arbitrary cut-n-paste during type development
may or may not lead to substitutability between the types at run-time.
This is fine if you appreciate this distinction, but not fine if you
don't.
Although it's formalised in different ways by different people, the
informal definition of run-time substitutability is the no surprises
rule. That is, if the user is expecting to interact with a P, then if
someone at run-time substitutes an instance of type Q, then Q must
behave like P so that the user is not surprised.
In some specific languages or systems, people can put rules on how types
are developed at design-time that guarantee that the run-time
no-surprise rule is ensured (e.g. the UML rules about generalisation).
However, there may be ways to develop types outside of those design-time
rules that still achieve no-surprises at run-time.
Therefore, it is not a good idea to argue about the validity of a
specialisation based on what extension or restriction you made at
design-time. When the rubber hits the road, it is only run-time
substitutability that counts.
Generally the richer the expressive power of the modelling language, the
harder it is to come up with ways to specialise definitions that yield
run-time substitutability. For example, if your modelling language is
purely based on static typing, then you have a less rich specification
and therefore the user's expectations of run-time behaviour are lower
and anything that offers the right type of parameters will be
substitutable. When you have a richer specification language with pre-
and post-conditions on operations, then this increases the user's
understanding of type P and hence makes it harder to substitute other
types. If you include arbitrary constraints in the modelling language,
it becomes very hard for other types to substitute.
Just as a simple example, consider a definition of a Rectangle
Rectangle {
length : real;
width: real;
makeLarger() // doubles the length and the width
makeSmaller () // halves the length and the width
}
If I introduce a specialisation Square with the restriction that length
= width, does this satisfy run-time substitutability? Yes, it does.
But if my definition of Rectangle included another operation
stretch () // double the length, width is unchanged
then Square would not satisfy run-time substitutability because it can't
stretch.
Generally unless a supertype is defined initially with a good
understanding of the ways in which it might be later subtyped, the
designer of the supertype will usually over-specify it (particularly if
a rich modleling language is used), making it very difficult to extend
in a run-time no-surprises way. So what tends to happen in practice is
that people find a type definition Q that is more-or-less similar but
not extensible directly as is because of some aspect of Q (lets call
that aspect X). The developer then extracts the the non-X parts of Q
into a new supertype type P and make the original type Q a
specialisation of P that adds back the X-ness. Then the developer
introduces their new type R another subtype of P but with its alternate
flavour of X-ness (which might be no X-ness). So, in practice, re-use
often occurs through generalisation rather than by specialisation (which
isn't exactly the original O-O vision). In the case of Rectangle and
Square above, one would extract all the methods of Rectangle that could
maintain the length=width invariant into the supertype and move the
methods that could not maintaint that invariant into the Rectangle
subtype. Of course, later someone will realise that the new supertype
still insists on right-angles in the 4 corners and will generalise it
again to eliminate that aspect, and then someone else will decide that
being 4-sided is an over-constraining limitation, etc. Such is the
lifecycle of a type definition :-)
So, what this means in practice for EHRs is that developing a new
archetype will often involve refactoring of existing archetypes (as I've
described above). So then we have to ask ourselves whether the new
definition of archetype Q (now a specialisation of a more generalised
class) is in fact substitutable for the old Q. Now providing you got the
refactoring right, then probably the old Q is identical in its behaviour
to the new Q (and both are substitutable for one another), but it's
going to have a new version number etc
The semantics of archetype Specialization
Or only against the meta-Archetype model Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On May 26, 2005, at 2:37 AM, Andrew Goodchild wrote: Hi, Does anyone know what it actually means to specialize an archetype? And what the rules are? I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don?t exist as optional fields in the parent archetype To me this particular example is not safe as one of the basic rules of specializing archetypes is you should be able to validate any new specialized EHR data against the parent archetype. -Andrew -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/8581ea13/attachment.html
The semantics of archetype Specialization
Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame
The semantics of archetype Specialization
Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
Andrew, I thought that the archetype approach was certainly extension. In fact there examples of such. Refer to Adverse-Reaction and Adverse-Reaction-Medication. I am also sure it supports restriction, the same example also supports this. Unlike some people, I believe that restriction is a valid form of specialisation as far as UML is concerned. Certainly in OOP, I often have an abstract property that has its value set (sometimes in hardcode) in the concrete class. Heath -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Andrew Goodchild Sent: Thursday, 26 May 2005 13:36 To: openehr-technical at openehr.org Subject: RE: The semantics of archetype Specialization I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
Andrew Goodchild wrote: Hi, Does anyone know what it actually means to specialize an archetype? And what the rules are? I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don?t exist as optional fields in the parent archetype To me this particular example is not safe as one of the basic rules of specializing archetypes is you should be able to validate any new specialized EHR data against the parent archetype. At the moment I would not read anything into the specialisation facility in the editor; it isn't implemented yet. The specialisation rules are, informally, that the constraint represented by the cADL section of an archetype must be wholly contained within that of a parent. The constraint structure of an archetype is a kind of nested set specification structure, or alternatively a nested query specification structure. So specialisation means that the specialised archetype's constraint structure must be, on a node-by-node basis, inside the constraint structure of the parent. This is fairly easily implementable with a function: is_inside(a_node: C_OBJECT): Boolean This needs to be executed on every node recursively. The node_id on each node is how to ensure the comparison is done between the correct nodes. Then the trick is to implement this function properly. The implementation is relatively simple for each of the leaf types, such as Integer ranges etc. It gets a bit harder for leaf nodes representing vocabulary subsets, indicated either in-line, or marked by ac codes. The latter are probably the hardest to get right, since it requries the presence of the vocabulary server to resolve the queries and do the comparison. For non-leaf nodes, the cardinality, occurrences and existence have to be taken into account; this is relatively simple. These rules will be documented release 1.0 archetype specifiaction. I am working on a paper which describes the mathematics of this formally. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
