Hi Thomas, taking the risk of being too philosophical, I reply to the list anyway.
> In an ontology of information we might define (say, with an archetype) a > structured model of "systemic arterial blood pressure measurement". This > is a model of the information captured during the measuring of BP in the > usual way; it would include systolic, diastolic, and a way to record > patient position, cuff size and instrument type. > > In an ontology of reality, we might define "blood pressure" as a > concept; in this ontology, the model expresses things like BP being a > specialisation of a pressure in a vessel (blood in a blood vessel); with > 5 identified phases etc etc etc. This model is likely to be a) quite > complex, and b) the details found in the archetype model might be there, > but will be buried in a large model which shows what blood pressure > really is. > > Archetypes in general are models of information and belong to an > ontology of information; "ontologies of the real world" on the other > hand describe kinds or categories of actual reality - the same > information as would be found in a medical, biochemistry and anatomy > textbook. That was well-explained, thanks! 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. 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? 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. > well, typeless programming is one approach to software programming. > Personally I don't believe in it, and neither do many others. I realise > of course that there are some who do, so I am not going to claim to have > the absolute truth on this issue. But just consider this: almost > everyone who writes in a typeless language ends up using variable names > like intSectionCount and boolPersistenceFlag etc - where the intended > types are built into the variable names. I am not exactly talking about typeless programming but about a universal kind of type. I did and still do appreciate your first OpenEHR design paper back in 2001, since it opened my eyes. 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 can't say I have felt any lack of flexibility in using typed systems - > I think flexibility or lack of is really a result of good or bad design. > The kind of design we use - based on archetypes as an entirely separate > level of modelling is extremely flexible, but the underlying object > model is still type-based. 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. 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. 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? > >Why shouldn't the archetype structure be the ideal way to make domain > >data persistent, too? If the archetype structure were general enough > >to represent any kind of knowledge, why shouldn't it be possible to > >make data persistent in this general structure? > > > We are not trying to make the archetypes so general - they have a very > defined purpose, and it does not include trying to represent the same > sort of information as snomed or Galen - i.e. models of reality. 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. > >That for the past decades most of the world is using relational databases > >doesn't mean that for the next thousand years we have to continue to do so. > >I am convinced that there are better ways to store knowledge. > >Object-orientation is just one step, but not sufficient. > > > well, I agree there. Archetypes are constraint models, which I consider > an advance on object-orientation. 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? > >What we need, in my opinion, is some kind of universal runtime type > >(knowledge structure/ schema), which is able to represent any kind of > >knowledge. Then the difference between knowledge templates (archetypes) > >and knowledge models (their instances) vanishes, because runtime models > >are represented in a general way, similar to their templates. > > > well, maybe this could happen in the future, I don't know. But we are > already so far ahead of the standard way of computing that it has become > imperative to put a stake in the sand and work with the approach we have > created so far. The first release of OpenEHR will be an important step. Go for it! I am just philosophising about version 3 or 4 ... Christian - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
