On Wed, 2008-05-07 at 22:03 +0100, Thomas Beale 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.
> >
> 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
--
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
**************************************************************
*You may get my Public GPG key from popular keyservers or *
*from this link http://timothywayne.cook.googlepages.com/home*
**************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Displayemail.gif
Type: image/gif
Size: 4274 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080508/7d55e3d6/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080508/7d55e3d6/attachment.asc>
