Hi Gerard,

> Many of the problems we have dealing with information in computer
> systems is that the same concept is used in several contexts/
> ontologies and ends up in a "universal" archetype that gets
> instantiated and becomes a non-universal. This state change confuses
> many systems (and persons).

I am talking about a universal *schema* (structure) for knowledge
representation, not a universal archetype. The schema, however, would
be general enough to be able to represent any archetype.
Note: A schema delivers just the knowledge structure and is free of
any domain knowledge; archetypes ideally contain domain knowledge only.

> > To me, ontology of information as you use it in form of archetypes
> > sounds more useful than the other kind. The ontology of the real
world
> > sounds like what terminologies want to achieve, right?
>
> We need those terminologies.
> They are the words (codes) used the express concepts.

O.k. I admit that I am still not clear with myself on this issue.
Currently, I don't consider myself proficient enough to further
contribute to this discussion. Need more time for reflection first.

[archetypes and terminologies]

> They are never the same.
> Context/purpose make them different.
> What they describe is different and not the same.
> But they overlap because they use the same words/codes to define the
> concepts used.

Yes, the terminology used in the contexts of archetypes/terminologies
definitely does overlap. But I am not sure if they really have to be
treated separately or not. As said before, I still need to reflect more
on this topic and cannot/ will not further participate in its discussion.

> Universal kind of type?
> What do you mean?

More concrete, a universal schema (type structure).

> In ontology terms used by Barry Smith universal is meant to denote,
> as I understand and translate it,  the facts/items that describe an
> object in the general sense.
> Not this particular object (say chair) but those objects in general
> (all types of chairs).
> In a way archetypes are universals themselves. And describe of what
> could be said in a particular context in general. When instantiated
> (as template) and filled they describe a fully defined particular
> context at this time, place, author, patient, etc.
> But the archetypes make use of concepts that don't have to be
> universals.

I think we have a misunderstanding here. Hearing "universal", you seem
to think about elementary building blocks, while I was talking about
a schema (structure) underlying all knowledge.
I did *not* mean archetypes or their contents or context etc.

> > . I did and still do appreciate your first
> > OpenEHR design paper back in 2001, since it opened my eyes.
>
> Could you elaborate on this?

I mentioned the three modelling approaches: single, semi-structured
and hierarchical knowledge representation. For further details on
these, please refer to Thomas' explanations in the referenced paper.
I believe that the last of these models (composite pattern) comes
closest to the universal schema I was talking about. Of course, it
certainly is insufficient still and further research is needed.

> > I do not criticise the archetype approach. I do criticise the
> > underlying
> > object model. I think you could try to reduce this model to just one
> > universal type. Put type information and inheritance, if wanted, into
> > the archetypes. Separate attributes and methods into their own
> > archetypes.

These are clear statements/ instructions.

> > Then you don't need OOP anymore. Reflective techniques that you use
> > (following Fowler's analysis patterns) to reference archetypes bring
> > with a lot of bidirectional dependencies and problems.
>
> Could you provide examples, so I can understand what you mean?

See: Martin Fowler. Analysis Patterns. You will find two levels of
software, a "knowledge level" and an "operational level" with
bidirectional dependencies.
Also see: Frank Buschmann. Pattern-orientierte Softwarearchitektur.
You will find the "Reflection" pattern and illustrations of the
bidirectional dependencies between its two (or more) levels.
Even Buschmann mentions the disadvantages of these dependencies.

> What do you mean by OOP in this context?
> P stands for Programming, isn't it?

Yes, "Object Oriented Programming".
Sorry that I didn't write the full name.
I myself don't like unexplained abbreviations.

> And what have programs to do with the definition of things/concepts?

Oh Jesus, that is getting to much! One could write a whole book about
this. This whole list is about how to abstract things/ concepts in
software/ programs. I thought you knew about that.

> Can I understand that the "object model" is that what gets
> instantiated in a computer system at run time?

Yes. Archetypes at design time. Object model at runtime.
But you have to distinguish between the actual instances (objects)
and the structure they have. This often caused a knot in my mind,
because one never knew exactly what was meant when talking about
the object model or reference information model.
I believe the reference information model relates to the structure
behind the object model. But OpenEHR people should specify this.

[I personally do call the three:
1 "Knowledge Template" (design time)
2 "Knowledge Model" (runtime)
3 "Knowledge Schema" (research time)
But since there were conflicts with the usage of the term
"template", so I sticked to OpenEHRs terms.]

> And that the "information Model" (aka Archetype) defines several
> aspects:
> a- information (its invariants, etc)
> b- methods
> and
> c- presentation

Yes.

> So far the Archetypes in OpenEHR and CEN describe -a-.
>
> If what I understand is what you mean, then I agree fully that the
> future of OpenEHR and CEN is to explore in future versions the
> definition, expression, exchange of aspects b and c.
> B is needed to define protocols.
> C is needed to handle the aspect of presentation that conveys
> semantic information in its own right.

Yes.

Christian

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Reply via email to