Hi Christian, I try to digest what you have said.
See in the text. Gerard -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 27-okt-2005, at 17:49, Christian Heller wrote: > Nevertheless, I think that these ontology definitions are not that > important if talking about knowledge modelling in general. > Every knowledge model (I use "model" to not conflict with different > definitions of "template") is a subjective abstraction of the real > world anyway. It does not matter whether the abstraction is simplified > a lot (like an ontology of information) for a specific context or less > (ontology of the real world) -- it is always an abstract model and as > such simplified. Nobody can model the real world in complete anyway. 1- The real world. Very complex and we don't know all about it. Both patient and healthcare provider operate in this world. This is where illness, and physical signs, molecules, atoms do their thing. 2- The model of the real world. People all have a simplified model of this real world. This is based on the knowledge and expertise of people. The knowledge and expertise is ever growing. This knowledge and expertise is formed using a system of concepts. Some of these are completely shared, others partially, between communicating parties. Concepts are defined within a context and with a purpose. People use various collections of concepts depending on context and purpose. The system of concepts is known as Ontology or model of the real world. 3- Registration/documentation of the healthcare process This takes place in the real world using real world events using real world physical objects. Each healthcare provider has the need or obligation to record what he has done while treating patients with problems, symptoms. The healthcare process from the documentation point of view (context) is the collection of facts of what is heard, seen, felt, smelled, thought during this healthcare process. Data is collected and documented. On the basis of expertise and knowledge the healthcare provider (professional) forms a professional opinion supported by a series of collected data. The production of a professional opinion about the real world phenomena (see bullit number 1) is from the registration/ documentation point of view one important function of any healthcare professional. In addition he performs/orders certain procedures that need to be registered and documented. The documentation of collected real world facts and real world procedures plus the production of the professional opinion and some orders or the execution of procedures is what gets done and documented. All the facts are expressed by the patient using his own model of the real world. (bullit number 2) and subsequently interpreted by the healthcare professional using his own bullit point number 2 model. And then it gets documented in a registrative system (paper and pencil or computers) using a collection of concepts designed for this purpose. e.g. Archetypes. For this we need an Archetype ontology (aka model of information, domain information model) as an abstract model that is very much simplified and distorted as compared with the models of bullet points 1 and 2. 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). An other confusion is the fact that at one point something is a professional opinion and after transfer to the next healthcare provider a fact and no longer the professional opinion. What I mean is: a blood sample is drawn. It is very physical and is part of the bullet point 1 world. This fact is documented as facts (data) using concepts from bullet point 3. On the basis of a sub-set of the bullet point 2 model the facts are interpreted and end up in the professional opinion. This opinion is described in terms of the bullet point 3 ontology. But when sent to an other healthcare provider this opinion becomes a fact in his system. > > 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. Archetypes are the constructs of "what can or must be said/ documented" in the course of the provision of healthcare. > I guess you had some difference of opinion with terminology people and > therefore introduced those two differing definitions. > If you use these two kinds of ontology to distinguish between > archetypes > (ontology of information) and terminologies (ontology of the real > world), > then why not? This is just a question of definition. Anyway, I > don't see > a big difference between the principles behind the two. > 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. > > I am not exactly talking about typeless programming but about a > universal kind of type Universal kind of type? What do you mean? 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 did and still do appreciate your first > OpenEHR design paper back in 2001, since it opened my eyes. Could you elaborate on this? > In it, > you described how to move from a single model, across a semi- > structured > model on to a hierarchical knowledge representation and, as > consequence, > the dual model approach. Of course, the composite design pattern (as > used by the hierarchical knowledge representation) was not sufficient > to represent knowledge of any kind. But it was the right starting > point > to extend it to a universal kind of type. Further research would have > been/ would be necessary. Unfortunately, you seemed to leave this path > of research in the following years and sticked with OOP instead. > > > 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. > 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? What do you mean by OOP in this context? P stands for Programming, isn't it? And what have programs to do with the definition of things/concepts? > Use unidirectional > dependencies; the "object" model (without OOP rather system-level/ > runtime > model) knows about the archetypes, not the other way. > Of course, some changes in the archetypes would be necessary, too. Can I understand that the "object model" is that what gets instantiated in a computer system at run time? And that the "information Model" (aka Archetype) defines several aspects: a- information (its invariants, etc) b- methods and c- presentation 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. > > I know this sounds a bit crazy and like a lot of work, much what has > been achieved would have to be thrown away; but why not think about > it? > > I fully agree with your approach to archetypes. All kinds of knowledge > models are made to serve a special purpose/ application. Terminologies > are very subjective ways of sorting millions of terms and one could > find a million ways to sort those millions of terms differently. It > always depends on the intended purpose/ planned application. > > What I wanted to say above was not about terminologies etc. > I suggested to make archetypes general in a way that they could > represent not only domain knowledge, but also graphical/ textual/ web > user interfaces, algorithms etc. Of course, you would have to separate > attributes and methods (algorithms), in order to represent them > independently. > > The main advantage, to me, are not so much the constraints, but the > distinction between knowledge (archetypes) and system control > (object model). If we want to improve OOP, then let's not build on it. > Have you ever thought about implementing the "object model" in a > procedural language? If your knowledge resides in archetypes anyway, > why still using OOP? > > > The first release of OpenEHR will be an important step. Go for it! > I am just philosophising about version 3 or 4 ... > Good. Thanks. > Christian > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051028/8cba90a2/attachment.html>
