Christian Heller wrote: >Hi Philippe, > > >Object hierarchies in memory, correct. But the problem is that hierarchy >as most fundamental abstraction was not worked in to OOP. If the designers >of Java, for example, had implemented the principle of hierarchy into >their framework, the top-most class java.lang.Object would be a CONTAINER: > >-------------------- >| java.lang.Object |------ >-------------------- | > ^ 0..* | > | | > ----------------- > >All inheriting types would be a hierarchy by default. Hundreds of >set/get/remove methods could be saved because they'd be inherited >from java.lang.Object. As another side-issue, the known problems > > I haven't ever tried to analyse this problem as such, but I suspect your proposed solution would only work in a world where programmers had permanent access to knowledge models, in order to provide semantic sense to the java instances in memory - any meaningful hierarchy needs to be a model of something, e.g. the hierarchy of levels of body/gastro-intestinal system/colon/various areas of the colon/various features etc etc. This is only possible with somethink like archetypes and Philippe's 'smart' lexicon (remember - the fils guides contain hierarchy building rules).
It may be in the future that we discover that we have chosen the wrong balance point between reference models and archetypes/terminology; maybe we will one day think that the openEHR reference model should be like your java.lang.object picture above, and that the totality of the semantics can be encoded in archetypes. But - we had to choose somewhere which works for practical purposes - and which "normal" programmers can handle. The criterion for the division of what is in the RM versus what is in the archetypes, by the way, is: - any concept which is domain generic - i.e. absolutely permanent across all uses of it in space (differnt software, systems) and time - can go in the reference model. Now, we happen to think that concepts like "versions" and "audit-trails" are permanent; we also think that the hierarchy Composition/Section/Entry can be safely permanent. So this means that the archetypes don't have to define such semantics (they would continually redefine the same thing anyway) - they define what seem to be the variable semantics - different kinds of Entries for example. >Up to now I thought OpenEHR's archetype model was developed independently >from OO mechanisms and that OO principles would only be used in the >reference model. Thomas' great design paper from 3 years ago made me >assume so because it described ontologies as hierarchies of layers, >so I thought OpenEHR would consider each model (archetype) to be a >hierarchy. Anyway, I do. > > Each archetype is a hierarchy of nodes, that's true - if you look at the ADL examples on the web you will see the hierarchic nature of each archetype. But there is also a UML model of archetypes - see http://www.openehr.org/tmp/adl-1_2_draft_d.pdf - which is what allows OO software developers to do something with an archetype in memory. We are working hard to improve ADL, build more tools, and connect ADL to OWL and other formalisms. Hopefully as more people play with the tools, we will get more creative input into these debates, and will make further progress on building knowledge resources for information systems. - thomas - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
