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
On Wed, May 7, 2008 at 7:37 PM, Tim Cook <timothywayne.cook at gmail.com>
wrote:
>
> On Wed, 2008-05-07 at 18:04 +0100, Thomas Beale 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.
>
> 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
>
>
>
>
>
>
>
> --
> 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*
> **************************************************************
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080507/be79bb30/attachment.html>
