While implementing ARCHETYPE objects I ran into an odd thing. Maybe I
am missing something or there is a mistake in the documentation?
The ontology attribute of ARCHETYPE is of the type ARCHETYPE_ONTOLOGY.
The AOM then says that the attribute ARCHETYPE_ONTOLOGY.parent_archetype
is of type ARCHETYPE and it is described as the; "Archetype which owns
this ontology."
Is that REALLY what it should be or should
ARCHETYPE_ONTOLOGY.parent_archetype be an ARCHETYPE_ID?
Thanks,
Tim
Tim Cook wrote:
While implementing ARCHETYPE objects I ran into an odd thing. Maybe I
am missing something or there is a mistake in the documentation?The ontology attribute of ARCHETYPE is of the type ARCHETYPE_ONTOLOGY.
The AOM then says that the attribute ARCHETYPE_ONTOLOGY.parent_archetype
is of type ARCHETYPE and it is described as the; "Archetype which owns
this ontology."Is that REALLY what it should be or should
ARCHETYPE_ONTOLOGY.parent_archetype be an ARCHETYPE_ID?Thanks,
Tim
*Tim,
this attribute is populated in memory when an archetype is deserialised,
so it points to the actual ARCHETYPE object. In almost every case (of
the few that there are) that there is a 'parent' reference, it works
like this.
- thomas
Okay, so now my understanding is that; the attribute contains the
parent archetype of this archetype? Not the current ("owner of this
ontology") archetype (which is circular). That kind of clears that up.
But according to the AOM spec:
"2.3.3 Archetype Specialisation
Archetypes can be specialised. The formal rules of specialisation are
described in the openEHR
Archetype Semantics document (forthcoming), but in essence are easy to
understand. Briefly, an
archetype is considered a specialisation of another archetype if it
mentions that archetype as its par-
ent, and only makes changes to its definition such that its constraints
are ‘narrower’ than those of the
parent. Any data created via the use of the specialised archetype is
thus conformant both to it and its
parent. This notion of specialisation corresponds to the idea of
‘substitubility’, applied to data.
Every archetype has a ‘specialisation depth’. Archetypes with no
specialisation parent have depth 0,
and specialised archetypes add one level to their depth for each step
down a hierarchy required to
reach them.
"
I originally read this to say that the specialization section was really
for information and not an operational requirement for an archetype
instance.
However, from your explanation. It seems to me that an archetype
instance with layers of specialization will require instances of all
parents nested within. If this is true; what value are they at
implementation?
Am I still confused? 
Cheers,
Tim
Tim,
My understanding of the specs (and what Tom explained in his post) is the attribute parent_archetype is exactly the same instance who owns the ontology. It is nothing to do with specialization. What Tom meant by “deserialised” is also normally known as the process of parsing a textual format (e.g. ADL) into the object form (e.g. AOM), hence the name of parser.
But you were correct on that this causes circular reference. I raised a similar issue before on C_OBJECT, which has an attribute “parent” of type C_ATTRIBUTE, which in turn has a list of children of C_OBJECT. The introduction of this new attribute make it impossible to implement immutable C_OBJECT because of this circular reference.
Cheers,
Rong
Tim Cook wrote:
this attribute is populated in memory when an archetype is deserialised,
so it points to the actual ARCHETYPE object. In almost every case (of
the few that there are) that there is a 'parent' reference, it works
like this.
Okay, so now my understanding is that; the attribute contains the
parent archetype of this archetype? Not the current ("owner of this
ontology") archetype (which is circular). That kind of clears that up.
no - it is the latter - the owner archetype. 'parent' was a poor choice
of name....
But according to the AOM spec:
"2.3.3 Archetype Specialisation
...
reach them.
"I originally read this to say that the specialization section was really
for information and not an operational requirement for an archetype
instance.
there is a whole new section in the forthcoming version 1.5 of ADL that
(finally;-) deals with specialisation semantics.
However, from your explanation. It seems to me that an archetype
instance with layers of specialization will require instances of all
parents nested within. If this is true; what value are they at
implementation?
in the archetype workbench we have implemented the idea of an 'archetype
lineage', i.e. specialisation trees of archetypes. Each specialised
archetype in the tree is in its 'differential' form, and also in its
'flat' generated form. Now, a confusing factor here in this is that the
current .adl files for specialised archetypes are in the flat form, i..e
they contain copies of inherited elements from parents. Clearly this is
not maintainable, so in the new generation of tools, .adls will be used
as the source files and these will be in differential form. For the
majority of archetypes that are not specialised, the result is the same.
The .adl files of the future will be generated from the .adls files; for
specialisation archetypes this is done by doing an
'inheritance-flattening' procedure. This is already implemented in a
basic way in the latest release of the Archetype Workbench.
Drafts of the new version of the ADL specification will be available as
soon as they are in a comprehensible form.
- thomas
Rong Chen wrote:
Tim,
My understanding of the specs (and what Tom explained in his post) is
the attribute parent_archetype is exactly the same instance who owns
the ontology. It is nothing to do with specialization. What Tom meant
by "deserialised" is also normally known as the process of parsing a
textual format (e.g. ADL) into the object form (e.g. AOM), hence the
name of parser.But you were correct on that this causes circular reference. I raised
a similar issue before on C_OBJECT, which has an attribute "parent" of
type C_ATTRIBUTE, which in turn has a list of children of C_OBJECT.
The introduction of this new attribute make it impossible to implement
immutable C_OBJECT because of this circular reference.
not quite - it just happens to be an attribute that is not persisted, it
is generated during deserialisation. What we should have done, and can
still do is to indicate more clearly which attributes are to be
persisted and which are not...
- thomas
> Okay, so now my understanding is that; the attribute contains the
> parent archetype of this archetype? Not the current ("owner of this
> ontology") archetype (which is circular). That kind of clears that up.
>
no - it is the latter - the owner archetype. 'parent' was a poor choice
of name....
Okay. So we now have a circular reference issue. Again, I do not
understand the value of this in any implementation.
First of all; an ontology instance cannot (should not) exist outside of
an archetype instance. Therefore it is obvious which archetype it
belongs with.
Secondly, on the issue of persistence in your reply to Rong. It doesn't
matter if the attribute is persistent or not, it'll still be a circular
reference in memory.
>
there is a whole new section in the forthcoming version 1.5 of ADL that
(finally;-) deals with specialisation semantics.
Great.
in the archetype workbench we have implemented the idea of an 'archetype
lineage', i.e. specialisation trees of archetypes. Each specialised
archetype in the tree is in its 'differential' form, and also in its
'flat' generated form. Now, a confusing factor here in this is that the
current .adl files for specialised archetypes are in the flat form, i..e
they contain copies of inherited elements from parents. Clearly this is
not maintainable, so in the new generation of tools, .adls will be used
as the source files and these will be in differential form. For the
majority of archetypes that are not specialised, the result is the same.
The .adl files of the future will be generated from the .adls files; for
specialisation archetypes this is done by doing an
'inheritance-flattening' procedure. This is already implemented in a
basic way in the latest release of the Archetype Workbench.
Okay, I have to object to the differential approach.
First I like the axiom, "just because we can does not mean we should".
So, what is the technical/operational value to the differential
approach? I know that Ocean has a lot of implementation experience that
most of us do not yet have. Maybe there are good reasons?
Secondly, a fundamental concept of clinical archetypes is that they are
a complete representation of a clinical concept expressed as an object
model. An ADL file is supposed to be the fully semantic serialization
of that archetype.
Third, there is already push back on using ADL (hence all the XML
discussions) by developers. Making what I consider a pretty drastic
change in just what an ADL file is, this early in the implementation
game, will only add to the confusion and further hurt acceptance that
ADL is a good thing. I think that the one ADL file per archetype object
is simpler to implement and maintain in an application. This is
especially true where you have special purpose apps with only a few
archetypes required.
Finally, maintainability should not be an issue. The versioning process
and placing the version number as part of the ID takes care of
maintainability. For example:
If I create at1 and then a specialization called at1x. Then someone
creates a new version of at1 called at2. at1x is still a specialization
of at1. at1x has no association with at2 other than both having risen
from at1.
I am certainly willing to listen if there are good reasons for these
changes. But, try as I did to come up with some the only thing I could
think of was to save disk space.
Regards,
Tim
Tim Cook wrote:
Okay. So we now have a circular reference issue. Again, I do not
understand the value of this in any implementation.
Although ARCHETYPE - ARCHETYPE_ONTOLOGY isn't exactly a case of the
Composite design pattern, nonetheless this quote from the GoF Design
Patterns book (p.166) seems applicable:
"Maintaining references from child components to their parent can simplify
the traversal and management of a composite structure. The parent reference
simplifies moving up the structure ... With parent references, it's
essential to maintain the invariant that all children of a composite have as
their parent the composite that in turn has them as children."
First of all; an ontology instance cannot (should not) exist outside of
an archetype instance. Therefore it is obvious which archetype it
belongs with.
I don't understand how it would be obvious, Tim. You would have to search
through all of the archetypes somehow in order to find the one to which the
ontology belongs.
Okay, I have to object to the differential approach.
First I like the axiom, "just because we can does not mean we should".
It was more a case of, "We can't, but we have to!"
Figuring out how to do it was not easy. Months of work. It wasn't done on a
whim.
So, what is the technical/operational value to the differential
approach? I know that Ocean has a lot of implementation experience that
most of us do not yet have. Maybe there are good reasons?
The value is that currently specialisations easily get out of step with the
specialisation parent. Someone might correctly create a specialised
archetype, but it's all too easy for someone to modify the parent and not
update the specialisations to match. This is not a hypothetical problem: it
has been happening.
Another reason for differential archetypes is to make it easier for multiple
people to work concurrently on the same lineage of specialised archetypes.
The current flat-form archetype source is basically a crude copy-and-paste
approach. It's not maintainable.
- Peter
Hi peter,
Thanks for this reply.
Although ARCHETYPE - ARCHETYPE_ONTOLOGY isn't exactly a case of the
Composite design pattern, nonetheless this quote from the GoF Design
Patterns book (p.166) seems applicable:"Maintaining references from child components to their parent can simplify
the traversal and management of a composite structure. The parent reference
simplifies moving up the structure ... With parent references, it's
essential to maintain the invariant that all children of a composite have as
their parent the composite that in turn has them as children."
I totally agree that it is applicable. References, being the key word.
Hence my suggestion that the type ARCHETYPE_ONTOLOGY.parent_archetype
should be ARCHETYPE_ID instead of ARCHETYPE.
> First of all; an ontology instance cannot (should not) exist outside of
> an archetype instance. Therefore it is obvious which archetype it
> belongs with.I don't understand how it would be obvious, Tim. You would have to search
through all of the archetypes somehow in order to find the one to which the
ontology belongs.
Ahhhh, but I think that this has more to do with your implementation
decisions than with the object model. ???
How could your ontology instance lose it's reference to its parent
archetype instance while in memory? My guess is that it doesn't. I'll
venture that it happens based on how you choose to persist your objects.
Correct?
This isn't to suggest that implementation issues shouldn't feedback to
the specifications. Heck that is one thing that makes this group and
the openEHR specifications different. If you can't implement it, it
doesn't work.
> Okay, I have to object to the differential approach.
>
> First I like the axiom, "just because we can does not mean we should".It was more a case of, "We can't, but we have to!"
Figuring out how to do it was not easy. Months of work. It wasn't done on a
whim.
I truly did not intend to suggest that it was. Hence my reference to
the amount of experience that Ocean Informatics has in this area.
The value is that currently specialisations easily get out of step with the
specialisation parent. Someone might correctly create a specialised
archetype, but it's all too easy for someone to modify the parent and not
update the specialisations to match. This is not a hypothetical problem: it
has been happening.Another reason for differential archetypes is to make it easier for multiple
people to work concurrently on the same lineage of specialised archetypes.The current flat-form archetype source is basically a crude copy-and-paste
approach. It's not maintainable.
Very valid and unsurprising points. Can we agree that this is a
development mode issue and that it doesn't apply to released ADL?
Since as I described before, released ADL files (should) follow a very
rigorous version control process.
IF so then I believe that the development issues are really one of
management and tools. Since it is completely logical that a
specialization of an archetype will reside in the same folder of the
development tree (as is the case with the ones I've seen). The tools
could scan the directory for specializations of the current archetype.
Warn the developer that specializations exist. Prior to committing any
changes ask the developer to approve an email to the author(s) of the
specialization(s) with the revision_history enclosed. If we were to add
a datetime stamp attribute to the specialization section along with the
parent archetype id then if the first email was lost, the tools could
check the parent and see if it had been modified since the last time the
specialization was edited.
Thoughts?
I appreciate the dialog.
Cheers,
Tim
Tim Cook wrote:
Okay, so now my understanding is that; the attribute contains the
parent archetype of this archetype? Not the current ("owner of this
ontology") archetype (which is circular). That kind of clears that up.
no - it is the latter - the owner archetype. 'parent' was a poor choice
of name....
Okay. So we now have a circular reference issue. Again, I do not
understand the value of this in any implementation.First of all; an ontology instance cannot (should not) exist outside of
an archetype instance. Therefore it is obvious which archetype it
belongs with.Secondly, on the issue of persistence in your reply to Rong. It doesn't
matter if the attribute is persistent or not, it'll still be a circular
reference in memory.
sure, but that doesn't matter. Works fine in the current
implementations. It's not really that important - if it causes problems
in an implementation, I would leave it out....I would have to go back to
the model to have a good look at why it is there in fact...
Okay, I have to object to the differential approach.
First I like the axiom, "just because we can does not mean we should".
So, what is the technical/operational value to the differential
approach? I know that Ocean has a lot of implementation experience that
most of us do not yet have. Maybe there are good reasons?
sure - it is just like OO code for subclasses - you don't include copies
of the methods and attributes already present in the parent, you only
include those being overridden or added. Doing otherwise creates a
maintenance problem, since child class B, containing copies of class A's
unchanged methods X and Y is out of date as soon as class A is modified
to change or remove X or Y.
Secondly, a fundamental concept of clinical archetypes is that they are
a complete representation of a clinical concept expressed as an object
model. An ADL file is supposed to be the fully semantic serialization
of that archetype.
it still will be, it is just that the .adl files of the future will be
generated objects from the .adls files.
Third, there is already push back on using ADL (hence all the XML
discussions) by developers. Making what I consider a pretty drastic
change in just what an ADL file is, this early in the implementation
game, will only add to the confusion and further hurt acceptance that
ADL is a good thing. I think that the one ADL file per archetype object
is simpler to implement and maintain in an application. This is
especially true where you have special purpose apps with only a few
archetypes required.
there is still only one .adl file per archetype; it is just that is a
.adls fle as well now. I don't see any way around this. Also, the XML
for all this is generated automatically by the tools, so I don't see any
problem with XML.
Finally, maintainability should not be an issue. The versioning process
and placing the version number as part of the ID takes care of
maintainability. For example:If I create at1 and then a specialization called at1x. Then someone
creates a new version of at1 called at2. at1x is still a specialization
of at1. at1x has no association with at2 other than both having risen
from at1.
yes, but that's not the problem. The problem is if at1 itself is changed
- all its child specialisations may be outdated.
- thomas
There is always one of those; "oh, why didn't I say ..." things you
think of right after clicking the Send button.
The ADL files are under SVN control. Are the knowledge workers using
those features? Editing locally and submitting commits? These changes
are already recorded and can easily be sent via email to subscribers.
The openEHR Java list does this quite nicely.
--Tim
Hi Tom,
>
sure - it is just like OO code for subclasses - you don't include copies
of the methods and attributes already present in the parent, you only
include those being overridden or added. Doing otherwise creates a
maintenance problem, since child class B, containing copies of class A's
unchanged methods X and Y is out of date as soon as class A is modified
to change or remove X or Y.
Correct. In software development you use a version control system to
keep everyone up to date. If I change class A, you get a notice and are
responsible for making any changes to your child class B. But when we
release a complete version of an application we do not send out .diffs
for our users to assemble.
Cheers,
Tim
Tim Cook wrote:
Hi Tom,
Correct. In software development you use a version control system to
keep everyone up to date. If I change class A, you get a notice and are
responsible for making any changes to your child class B. But when we
release a complete version of an application we do not send out .diffs
for our users to assemble.
it might be different with Python. But normally it is the compiler that
catches incompatibilities between parent and child classes. But this can
only work if the child classes are in differential format, which they
are in every OO language that I know of.....
- thomas
Hi Tim,
Regardless of whether a version control system is used, when the person in
charge of child class B becomes aware that something has changed in parent
class A, we don't require all of those changes to be copied manually from A
to B.
That is the situation at the moment with .adl files. When the person in
charge of b.adl becomes aware that a.adl has changed, all of those changes
have to be copied manually from a.adl to b.adl.
- Peter
Tim Cook wrote:
> First of all; an ontology instance cannot (should not) exist outside of
> an archetype instance. Therefore it is obvious which archetype it
> belongs with.I don't understand how it would be obvious, Tim. You would have to search
through all of the archetypes somehow in order to find the one to which
the
ontology belongs.Ahhhh, but I think that this has more to do with your implementation
decisions than with the object model. ???How could your ontology instance lose it's reference to its parent
archetype instance while in memory? My guess is that it doesn't. I'll
venture that it happens based on how you choose to persist your objects.
Correct?
No, I didn't say anything about an ontology instance losing its reference.
We're talking about whether the in-memory ontology instance should refer to
its archetype via (a) a direct object reference of type ARCHETYPE, or (b) an
indirect reference of type ARCHETYPE_ID.
My point was that with (a) you have the owning archetype immediately,
whereas with (b) you would have to do some kind of look-up or search.
(Note that I don't know whether this actually was the motivation for
choosing ARCHETYPE rather than ARCHETYPE_ID.)
- Peter
Tim Cook wrote:
First of all; an ontology instance cannot (should not) exist outside of
an archetype instance. Therefore it is obvious which archetype it
belongs with.I don’t understand how it would be obvious, Tim. You would have to search
through all of the archetypes somehow in order to find the one to which
the
ontology belongs.Ahhhh, but I think that this has more to do with your implementation
decisions than with the object model. ???How could your ontology instance lose it’s reference to its parent
archetype instance while in memory? My guess is that it doesn’t. I’ll
venture that it happens based on how you choose to persist your objects.
Correct?No, I didn’t say anything about an ontology instance losing its reference.
We’re talking about whether the in-memory ontology instance should refer to
its archetype via (a) a direct object reference of type ARCHETYPE, or (b) an
indirect reference of type ARCHETYPE_ID.My point was that with (a) you have the owning archetype immediately,
whereas with (b) you would have to do some kind of look-up or search.(Note that I don’t know whether this actually was the motivation for
choosing ARCHETYPE rather than ARCHETYPE_ID.)
In the Java implementation, the reference to parent is not used so far, both in the case of ARCHETYPE/ARCHETYPE_ONTOLOGY and C_OBJECT/C_ATTRIBUTE. I think the explanation could be the navigation between child and parent is nearly always from parent to child (top down traverse of the object tree), e.g. serializing AOM to ADL and use AOM as a template to create RM instances. The only exception is during parsing when the object tree is built from bottom up. This is where these circular references are getting in the way. If these references are not very useful in other implementations, I would like to suggest to leave them out.
Cheers,
Rong
that the reference of the parent is still in the context if needed.
I only found it getting in the way of implementing immutable object pattern.
Rong Chen wrote:
In the Java implementation, the reference to parent is not used
so far, both in the case of ARCHETYPE/ARCHETYPE_ONTOLOGY
and C_OBJECT/C_ATTRIBUTE.
Actually, Rong, I note with surprise that our Eiffel implementation doesn't
even have ARCHETYPE_ONTOLOGY.parent_archetype.
- Peter
Peter Gummer wrote:
Rong Chen wrote:
In the Java implementation, the reference to parent is not used
so far, both in the case of ARCHETYPE/ARCHETYPE_ONTOLOGY
and C_OBJECT/C_ATTRIBUTE.
Actually, Rong, I note with surprise that our Eiffel implementation doesn't
even have ARCHETYPE_ONTOLOGY.parent_archetype.
*I knew that >
Peter Gummer wrote:
Rong Chen wrote:
In the Java implementation, the reference to parent is not used
so far, both in the case of ARCHETYPE/ARCHETYPE_ONTOLOGY
and C_OBJECT/C_ATTRIBUTE.Actually, Rong, I note with surprise that our Eiffel implementation doesn’t
even have ARCHETYPE_ONTOLOGY.parent_archetype.*I knew that >
It doesn’t exit in the Java implementation either. It could be a recent change in the specs.
/Rong
It appears that my argument on this issue is void.
I have been informed by off list email that the so called 'flat ADL'
files will continue to be produced by the tools.
I suppose the issue of managing these releases will be up to the
knowledge management/governance group. But I am very happy to hear that
they will continue to be available.
Cheers,
Tim