RFC CR-000101 - request for comments - deadline 23 july 2004
Hi All, 'hierarchical', at a minimum, shouldn't be used to describe physical/chemical processes, e.g., flight dynamics and control of the 747 I just rode. Space has to be included in this; OK throw in the Universe we are in and all the others we do not know about. The brain, as a chemical engine, and the storage of information in it, as a first-order approximation, is parallel in nature; otherwise you probablably would not be able to perform activities and visualize simultaneously. 'hierarchical', and its uses, can be pinned human attempts to inject order. e.g., heirarchical classifications. Some attempts at controlling parallelisms, e.g., symmetric multiprocessor systems, are controlled to the point where they cannot be labeled are parallel systems. Parallel systems do exist, e.g., independent, communicating systems that coordinate processing to achieve specific goals, objectives and performance, e.g., space missions (constraint-based control; close control impossible). 'concurrently executing processes' can be considered parallel systems. Of course goals, objectives and performance impose operational constraints, e.g., constraint-based system. Examples come from high performance data processing, control applications (e.g., nuclear reactors), and manufacturing. 'hierarchical' control systems require that control be exercised continuously, on a regular schedule, or when events require it. Continuous systems under my control would not permit 'sleep' time; regular systems would mean I would have to adapt to the schedule, and event-driven systems would mean I would be awoken frequently. These type systems are limited in number throughout the world populations. It is true that the sun has imposed a hierarchical ordering to daily activities for farmers but it is also true that the sun is close to the model of a 'parallel' system than a 'hierarchical' system. In your own words: 'as the human mind perceives it' hierarchical implies human ordering, e.g., a model reduced to a chalk talk session. 'hierchical' applied to nature has some serious obstacles to overcome, e.g., Quantum Mechanics. Regards! -Thomas Clark Karsten Hilbert wrote: - every concept, everything in existence (as the human mind perceives it) is hierarchical, to microcosm as well as towards macrocosm Including the brain itself ? Karsten - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
Hi, Karsten and Christian, Nice brain pingpong match ;o) Don't you think that your vision depends on the feeling you get and the tools you are familiar with ? In a pure object oriented model, dealing with hierarchies of object is natural. However when it comes to knowledge management, it is more natural to shift to predicates, for example semantic networks. Because it is usually not possible to define THE hierarchy : to keep on with the brain, you may succed in building an anatomical hierarchy, but when you will consider brain functions or brain diseases, you will have to build new hierarchies. All this hierarchical trees are inter-connected, and you have better replacing hierarchical traits with named traits (ie predicates). I don't know if all this is relevant with openEHR ? (I mean does a system need to mimic what it should manage) Regards Philippe physical brain == carrier of knowledge == neurons, synapses etc. == real world But they are not interconnected in a hierarchy only, to the best of my knowledge. The mind knows about itself and its physical carrier, the brain. But the functioning of the brain has nothing to do with the abstract concepts build within it. I tend to think that Nature had no abstract concepts in mind when building the brain. Rather abstract concepts are what we with our limited ability to comprehend use to reduce complex things to something we *can* understand, no ? Eg. the brain simply IS but we use abstract concepts to *describe* what we understand of it. Unless you want to reduce those abstract concepts to Laws of Nature - which have nothing much to do with why or whether the brain is internally connected hierarchially or web-like. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
Hi Philippe, Don't you think that your vision depends on the feeling you get and the tools you are familiar with ? of course, everybody has a different vision of the world, depending on how their brain was learned. The principle concepts of human thinking (not physically in brain but logically in mind) however, are the same. In a pure object oriented model, dealing with hierarchies of object is natural. 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 with container inheritance (http://www.norvig.com/java-iaq.html) would disappear. See also http://www.josmc.org/bohl2003.pdf, section 5.1 (much of this paper is a bit out of date). Further reading includes Gottfried Wilhelm Leibnitz's Monades, see: http://www.e-text.org/text/Leibnitz%20Gottfried%20Wilhelm%20-%20La% 20Monadologie.txt (in french, but it also exist in english on the web). 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. However when it comes to knowledge management, it is more natural to shift to predicates, for example semantic networks. Because it is usually not possible to define THE hierarchy : to keep on with the brain, you may succed in building an anatomical hierarchy, but when you will consider brain functions or brain diseases, you will have to build new hierarchies. All this hierarchical trees are inter-connected, and you have better replacing hierarchical traits with named traits (ie predicates). I agree with that view. An application system is a collection of trees, each representing a special concept. Only the last sentence is unclear to me; a whole model names its part models _and_ is hierarchical. Christian - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
The CR to be considered in this post is CR-000101- Improve Modelling of Structure classes. See http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-00010 1.txt . This CR proposes a change to the Data structure classes which makes for more efficient data representation. The current model is at http://www.openehr.org/repositories/spec/latest/publishing/architecture/re ference_model/data_structures/im/REV_HIST.html The PDF attached to this post shows the proposed change, in the form of a UML diagram for the data structure classes. In the PDF, the 2nd UML diagram is the important one; if you compare it to the existing model you will see that in the new model, each data structure type (ITEM_TABLE etc) now has its own connection to the appropriate CLUSTER or ELEMENT type. Previously, ITEM_LIST would have had a CLUSTER then a bunch of ELEMENTs; now it just has a list of ELEMENTs. There are of course still far more efficient ways to implement [..] I propose to introduce one top-most container structure to be used for all knowledge templates/ archetypes. Philosophical Background: - the universe is a mixed conglomerate - one important (the most important) kind of abstraction that our mind uses to perceive its environment is Composition - there is only ONE kind of container; all other types are just variations - a list, for example, is a container that keeps additional information about the order of its elements; but it is NOT another kind of container - every concept, everything in existence (as the human mind perceives it) is hierarchical, to microcosm as well as towards macrocosm - OpenEHR needs to introduce Hierarchy as top-most concept of ALL knowledge templates/ archetypes Christian - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
- every concept, everything in existence (as the human mind perceives it) is hierarchical, to microcosm as well as towards macrocosm Including the brain itself ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
- every concept, everything in existence (as the human mind perceives it) is hierarchical, to microcosm as well as towards macrocosm Including the brain itself ? Yes, because in our concept of a brain it consists of regions, neuron cells, organelles, molecules etc. You have to distinguish between: logical mind == knowledge == models/concepts/archetypes == abstracted world and: physical brain == carrier of knowledge == neurons, synapses etc. == real world The mind knows about itself and its physical carrier, the brain. But the functioning of the brain has nothing to do with the abstract concepts build within it. Christian - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
physical brain == carrier of knowledge == neurons, synapses etc. == real world But they are not interconnected in a hierarchy only, to the best of my knowledge. The mind knows about itself and its physical carrier, the brain. But the functioning of the brain has nothing to do with the abstract concepts build within it. I tend to think that Nature had no abstract concepts in mind when building the brain. Rather abstract concepts are what we with our limited ability to comprehend use to reduce complex things to something we *can* understand, no ? Eg. the brain simply IS but we use abstract concepts to *describe* what we understand of it. Unless you want to reduce those abstract concepts to Laws of Nature - which have nothing much to do with why or whether the brain is internally connected hierarchially or web-like. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
physical brain == carrier of knowledge == neurons, synapses etc. == real world But they are not interconnected in a hierarchy only, to the best of my knowledge. I did not say that. I was talking about concepts (mind) only. The mind knows about itself and its physical carrier, the brain. But the functioning of the brain has nothing to do with the abstract concepts build within it. I tend to think that Nature had no abstract concepts in mind when building the brain. Rather abstract concepts are what we with our limited ability to comprehend use to reduce complex things to something we *can* understand, no ? Eg. the brain simply IS but we use abstract concepts to *describe* what we understand of it. Unless you want to reduce those abstract concepts to Laws of Nature - which have nothing much to do with why or whether the brain is internally connected hierarchially or web-like. That is what I said/meant. Mapped to informatics/computing, the brain is represented by hardware plus operating system; the mind is the knowledge that OpenEHR et al. try to abstract in concepts, stored as software. Neural Networks is another issue. They try to imitate the functioning of the physical brain. But it is the _concepts_ learned by neural networks what we talk about here. Christian - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
RFC CR-000101 - request for comments - deadline 23 july 2004
Dear all, as some of you may have noticed, the openEHR Architectural Review Board was created some months ago, and is now in action (see http://www.openehr.org/about_openehr/t_arb.htm). Its job is to manage changes to openEHR. The ARB is currently processing a number of CRs (Change Requests) which have been raised and are targetted to openEHR release 1.0 (for the list, see http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR_by_release.html - toward bottom). As part of the process, we feel that certain CRs would benefit from community feedback - in particular, anything which actually changes models or specifications, and would cause changes in current openEHR software projects being. (Note: CRs which are processed by the ARB alone are generally to fix errors in documentation or software, and don't appear to require much decision-making as such. In other words, we try not to waste your time with no-brainers!). To add some focus to this process, I have suggested making a post for each CR to the openEHR technical group, in order to start a discussion thread. There will accordingly be a series of posts like this one, each for an openEHR CR. We anticipate two kinds of response: - technical feedback - feedback about timing of implementation, impact, etc The CR to be considered in this post is CR-000101- Improve Modelling of Structure classes. See http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-000101.txt . This CR proposes a change to the Data structure classes which makes for more efficient data representation. The current model is at http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/data_structures/im/REV_HIST.html The PDF attached to this post shows the proposed change, in the form of a UML diagram for the data structure classes. In the PDF, the 2nd UML diagram is the important one; if you compare it to the existing model you will see that in the new model, each data structure type (ITEM_TABLE etc) now has its own connection to the appropriate CLUSTER or ELEMENT type. Previously, ITEM_LIST would have had a CLUSTER then a bunch of ELEMENTs; now it just has a list of ELEMENTs. There are of course still far more efficient ways to implement these data structure classes; my preferred proposal for the future is that the model specifies only interfaces, and implementors do whatever they want; they just have to implement one method, namely the as_hierarchy method you see in the class ITEM_STRUCTURE - this is the one that guarantees that each data structuer can be converted to a CEN / openEHR / CDA hierarchical CLUSTER/ELEMENT form, as required for interoperable EHR Extracts / Documents. However, the simpler change proposed here is probably preferable for the moment. The DSTC in Brisbane, Australia is currently working on an openEHR implementation, and have analysed the XML data resulting from the current model; their analysis shows that this proposed change would reduce the amount of duplication in XML structures; I would expect anyone working with openEHR and XML would come to a similar conclusion; implementors' comments very welcome. Close of RFC: 23 July 2004. regards, - Thomas Beale -- ___ CTO Ocean Informatics (http://www.OceanInformatics.biz) Hon. Research Fellow, University College London openEHR (http://www.openEHR.org) Archetypes (http://www.oceaninformatics.biz/adl.html) Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html) -- next part -- A non-text attachment was scrubbed... Name: CR-000101-a.pdf Type: application/pdf Size: 25263 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20040709/c84314a4/attachment.pdf
