openEHR Subversion = Github move progress
Hey that?s really awesome! Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Roger Erens Sent: Saturday, 13 April 2013 11:44 a.m. To: For openEHR technical discussions Subject: Re: openEHR Subversion = Github move progress Hey guys, now that openEHR is on github, have you realised that WE'RE ALL REALLY WRITING HISTORY? See, e.g. http://starlogs.net/#openEHR/gdl-tools Now that's gonna baffle them at Medinfo! Cheers, On Fri, Mar 22, 2013 at 12:13 AM, Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote: The last of what I think are the active Subversion repositories on the old openEHR.org server has been converted to GitHub now (the Archetype Editor). Repositories which appear to be inactive but could be converted if anyone wants: * liu_knowledge_tools (Linkoping has a more recent version of this AFAIK) * the original 'knowledge' repository containing a lot of old NHS archetypes * knowledge_tools_java - not sure about this one. * ref_impl_python For those who have links, checkouts or other pointers to any openEHR SVN repositories, please now refer to the Github openEHR repositorieshttps://github.com/openEHR. Any questions like 'where did xxx go?', feel free to post them here. - thomas beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto:openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __ Information from ESET NOD32 Antivirus, version of virus signature database 8291 (20130503) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130503/250bf9d7/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
Bert Verhees wrote: And of course, good non-GUI-building archetype-editors which are still not there, the complains I had about the both mainstream archetype-editors were admitted, but the improvement did not yet come. Hi Bert, I remember that you described some inconsistencies on one of the mailing lists last year, but you need to report issues to the problem tracker if you really want them fixed. There's a link here for reporting problems: http://openehr.org/downloads/archetypeeditor/home ... although the Jira problem tracker appears to be down at the moment. Peter
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
I am always somewhat surprised as well. Thanks by the way for your clarifying notes, that is exactly how I would summarise the discussions. - thomas On 07/04/2013 22:08, Randolph Neall wrote: Hi Thomas, I'm surprised that at this advanced stage of openEHR's maturity you'd still have to defend concepts like these, which are self-evident. Your architecture, or something closely resembling it, is actually the only path to (1) computability, (2) shareability, and (3) coherent and maintainable program code. Ultimately the real enemy is chaos, and that's precisely what you get unless someone detects and names the universal patterns amidst the diversity, and structures program code to conform to such patterns. I'm not clear why this should be controversial. This discussion is now dividing into two unrelated branches: (1) the desirability of consensus around the content of data model, and (2) whether the model itself, whether widely agreed to or not, should embody a multi-level abstraction hierarchy permitting code and logic reuse at its more abstract levels. Both branches, wrongly argued, are a direct invitation to chaos. From what I understand of it, openEHR is an attempt, in both regards, to avoid chaos. I can only wish you success against the two challenges.
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
There is always a meta-architecture. It's just a question of whether system builders are conscious of it. Thomas, perhaps you don't intend humor, but gems like this are what make reading your posts both enlightening and entertaining, even for someone at my distance. On Mon, Apr 8, 2013 at 8:06 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: I am always somewhat surprised as well. Thanks by the way for your clarifying notes, that is exactly how I would summarise the discussions. - thomas On 07/04/2013 22:08, Randolph Neall wrote: Hi Thomas, I'm surprised that at this advanced stage of openEHR's maturity you'd still have to defend concepts like these, which are self-evident. Your architecture, or something closely resembling it, is actually the only path to (1) computability, (2) shareability, and (3) coherent and maintainable program code. Ultimately the real enemy is chaos, and that's precisely what you get unless someone detects and names the universal patterns amidst the diversity, and structures program code to conform to such patterns. I'm not clear why this should be controversial. This discussion is now dividing into two unrelated branches: (1) the desirability of consensus around the content of data model, and (2) whether the model itself, whether widely agreed to or not, should embody a multi-level abstraction hierarchy permitting code and logic reuse at its more abstract levels. Both branches, wrongly argued, are a direct invitation to chaos. From what I understand of it, openEHR is an attempt, in both regards, to avoid chaos. I can only wish you success against the two challenges. __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130408/84293f5b/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
[This is Tim again, initially bounced] And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall You are mostly correct. It isn't that I don't think that re-use is a good idea. The knowledge modellers and developers are telling us by their actions that do not want to participate in the top-down, maximal data model approach. As I have said many times, for many years; it is a wonderfully engineered eco-system. Now we know, it just doesn't work in real practice on a global basis. So that had to change. Add in some other simplifications in the RM and openEHR turns into MLHIM. My goal is to encourage multi-level modelling to solve the semantic interoperability issue. Whatever acronym you want to tie to it. I know that MLHIM isn't perfect, but it is designed with agility and data durability in mind. --Tim -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130406/e81f625a/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 06/04/2013 23:50, Thomas Beale wrote: [This is Tim again, initially bounced] And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall You are mostly correct. It isn't that I don't think that re-use is a good idea. The knowledge modellers and developers are telling us by their actions that do not want to participate in the top-down, maximal data model approach. As I have said many times, for many years; it is a wonderfully engineered eco-system. Now we know, it just doesn't work in real practice on a global basis. Tim, obviously some of us are interested in this statement. You say 'it just doesn't work in real practice'. Our experience is different, and I am interested in your evidence / justification of this statement. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130407/c623cfc8/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 06/04/2013 23:50, Thomas Beale wrote: [This is Tim again, initially bounced] And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall You are mostly correct. It isn't that I don't think that re-use is a good idea. The knowledge modellers and developers are telling us by their actions that do not want to participate in the top-down, maximal data model approach. As I have said many times, for many years; it is a wonderfully engineered eco-system. Now we know, it just doesn't work in real practice on a global basis. actually, I will be a bit more specific. Let's say we are talking about archetypes for some of the following topics (the following are some openEHR CLUSTER archetypes): None of these can be defined by 'developers'. They are clinical content, and only clinical professionals can develop proper versions of them. So what you are saying is that 'knowledge modellers' (presumably physicians) don't want to build such models by participating in a modelling exercise in which they communicate with other physicians working on the same models? It seems to me that the only alternative is that they build their own private models and ignore everyone else. That's expedient, but it's also a guarantee of non-interoperability. Maybe you can explain your statements in more detail? thanks - thomas ** -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130407/ee7346b2/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: caheidaa.png Type: image/png Size: 16099 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130407/ee7346b2/attachment-0001.png
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 07/04/2013 00:35, Bert Verhees wrote: That's expedient, but it's also a guarantee of non-interoperability. As far as I can see, also from my experience, nor OpenEHR, nor MLHIM will be the only datamodel system on the world. Cooperation with other systems will always need a message-format. The same goes for other systems. Mapping will always be (at least partly) done manually. The goal, what the customer wants, is not a solution, which dictates him to throw away his system, but he wants connectivity in which his system can participate. Hi Bert, that's obviously one thing customers want - data interoperability. But - what do they want to do with the data? Let's say that want to have a managed medication list, or run a query that identifies patients at risk of hypertension, or the nursing software wants to graph the heart rate. Then they need more - just being able to get the data isn't enough. You have to be able to compute with it. That means standardising the meaning somehow. Now, each healthcare provider / vendor / solution producer could just define their own 'content models'. Like they do today. Or we could try and standardise on some of them. The openEHR way seems to me the one that can work: because it standardises on the archetypes, which are a library of data points and data groups, it means that anyone can write their own data set specification (template) based on that. So you define what blood pressure looks like once (in the archetype) and it gets used in 1000 places, in different ways. But - it's guaranteed to be queryable by queries based on the archetype. That's the essence of the system - 3 modelling layers: * reference model - agree on the data * archetypes - agree on the clinical data points and data groups - this only needs to be done more or less once; queries are based on these models * templates - define localised / specific data sets using the archetypes We're working on major improvements on the details in ADL 1.5, but I have to admit I don't think of trying to change the ground rules. These three logical levels are the minimum for data interoperability, content standardisation, and local freedom. With specialisation and association between models in the archetype and template layers, that's a lot of freedom to customise. Is there a better meta-architecture available? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130407/f856ec86/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 07/04/2013 12:11, Grahame Grieve wrote: Hi Tom You ask: Is there a better meta-architecture available? When actually the question at hand appears to be: is it even worth having one? I don't think that this is a question with a technical answer. It's a question of what you are trying to achieve. I've written about this here: http://www.healthintersections.com.au/?p=820 There is always a meta-architecture. It's just a question of whether system builders are conscious of it. If they aren't, then by definition they are just doing /ad hoc/ development, with no comprehension of the semantics of what they build. I prefer to have conscious design going on, and make some attempts at defining rules for system semantics. Then you know what you can expect the system to do or not. To go back to the question of meta-architecture, let me ask the following questions... 1. is it worth trying to have a publicly agreed (by some community at least) information model? I.e. to at least be able to share a 'Quantity', a data tree of some kind, a 'clinical statement' and so on? = in my view yes. Therefore, define and publish some information model. Aka 'reference model' in openEHR. 2. do we really want to redefine the 'serum sodium', 'heartrate' and 'primary diagnosis' data points every time we define some clinical data set? = in my view no. Therefore, provide a way to define a library of re-usable domain data points and data groups (openEHR version of this: archetypes) 3. do we need a way to define data sets specific to use cases, e.g., the contents of messages, documents etc etc? = in my view, yes, it seems obvious. Therefore, provide a way to define such data sets, using the library of 'standard data points/groups', and also the reference model. and 4. would we like a way of querying the data based on the library of re-usable data items? E.g. is it reasonable to expect to query for 'blood sugar' across data-sets created by different applications sources? = in my view yes. To fail on this is not to be able to use the data except in some /ad hoc /brute force sense. You (I don't mean Grahame, I mean anyone ;-) may answer differently, but if you don't care about these questions, it means you have a fundamentally different view about how to deal with information in complex domains requiring information sharing, computation, and ultimately intelligent analysis (health is just one such domain). Either you think that the above is a 'nice idea' but unachievable, or else that it's irrelevant to real needs, or.. something else. If you think the questions are relevant but have different answers to them, it means you believe in a different meta-architecture. Note that these considerations are actually orthogonal to whether standards should be built by agreeing only on messages between systems, or how systems are built (the topic of Grahame's blog post). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130407/16cef831/attachment-0001.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 04/07/2013 10:40 AM, Thomas Beale wrote: Is there a better meta-architecture available? I think is a very good architecture, that is why I am using it, but I(we) keep having to deal with people who think otherwise. I am not smart enough to point out why HL7v3 messaging is good or bad, or what William Goossen does now, DCM, is good or bad. As long as a system can hold all required information, I think it is good enough. But good enough does not mean that it cannot be improved. I have some thoughts, but that concerns the way they define the messages, and I think, it is a shortcoming of the system, that it only can be done that way. I think the messages themselves, as designed by NIctiz, for example, are very complete, and can hold all required information. But, there is some doubt in evidence based practice, so freedom is very important. And in that part, HL7v3 and DCM do not satisfy on this. They don't offer freedom, they impose elsewhere and predefined ways of thinking and methods of treatment. Did you see the link Karsten Hilbert published? http://www.youtube.com/watch?v=Ij8bPX8IINg Don't eat like a pig and get some exercise is often a good medicine for many diseases, but that does not make money. But not only, sometimes it is even better not to treat people at all. There is quite some discussion between physicians on what is a good way to treat people. And we also have alternative medicine, such as herbal medicine, acupuncture. This should, all fit in information systems. I am happy to be a technician and like to offer freedom to the users of my software. The advantages come, as I already explained, from my point of view with the flexibility, and the completeness of the eco-system, and the easiness with which, even non-technicians can get involved in system-modeling. I once explained it on Wikipedia with two drawings. http://commons.wikimedia.org/wiki/File:SingleLevelModelling.png http://commons.wikimedia.org/wiki/File:TwoLevelModelling.png In the first, the technicians have to talk with domain-experts, and with the users. Technicians talking about evidence based practice? That does not make sense. In the second, the technicians are standing beside, and create a base platform on which users and domain-experts can design their system. More or less this is OpenEHR. But there is still work to do, for example a good GUI-creator, like Visual Studio (does that still exist?), and generate archetypes from a designed GUI, helping them to incorporate terminology etc. And of course, good non-GUI-building archetype-editors which are still not there, the complains I had about the both mainstream archetype-editors were admitted, but the improvement did not yet come. A really good user friendly development environment, which is absolute necessary to make the idea of multi-level modeling to work, has not yet arrived. Ten years we are working on that, and still we do not comfort the users, who we value very much as main system-modelers, with easy ways to do, what they are expected to do in our philosophy. Bert
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On 05/04/2013 13:03, Thomas Beale wrote: [original post by Tim bounced; reposting manually for him] On Thu, Apr 4, 2013 at 12:50 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: if you mean the competing inheritance models - I have yet to meet any XML specialist who thinks they work. The maths are against it. Interesting that you, the creator of a technology that makes many people very uncomfortable (multi-level modelling), thinks that conventional users of XML have something to say regarding XML as a multi-level implementation. Confusing. not sure what you want to say here! Can you point to some MLHIM models that show specialisation, redefinition, clarity of expression, that sort of thing? I tried to find some but ran into raw XML source. There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. so does openEHR, that's what namespaces are about. If two groups both define a 'blood pressure' archetype today, there is an immediate problem. In the future with namespaced ids, the problem becomes manageable, since both forms can co-exist. Thanks for confirming this problem, for today. I hope that people realize the potential issues that they are creating by operating outside of the eco-system. I also hope that whenever, 'the future', arrives that people will understand that the need to use this namespace capability. Are there estimates yet as to when the future will arrive? Now more or less. New versions of the documents are being published imminently, and the tooling is catching up to namespaces (also other things like annotations). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130405/4753ad75/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
Hi Tim There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. Response from Tom: But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. What was apparently an argument about XML modeling was actually an argument about something quite different, namely, whether specialization or redefinition have any place in EHR data modeling. I'm surprised you would mount such a challenge (if that's what you meant to do), familiar as you have been with openEHR since the beginning. This is fundamental and basic. It would be interesting to hear you address this point directly and explicitly, leaving aside the preferred modeling ecosystem for now. Is specialization or redefinition actually important? Or was it important only until MLHIM appeared? I looked briefly at some of the MLHIM XSDs, which appear to model something akin to flat files, but then I probably missed the parent schema into which they all fit. Randy Neall On Fri, Apr 5, 2013 at 9:34 PM, Randolph Neall randy.neall at veriquant.comwrote: Cook: There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. Beale: I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. Beale: But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall On Fri, Apr 5, 2013 at 6:00 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 05/04/2013 13:03, Thomas Beale wrote: [original post by Tim bounced; reposting manually for him] On Thu, Apr 4, 2013 at 12:50 PM, Thomas Bealethomas.beale at oceaninformatics.com thomas.beale at oceaninformatics.com wrote: if you mean the competing inheritance models - I have yet to meet any XML specialist who thinks they work. The maths are against it. Interesting that you, the creator of a technology that makes many people very uncomfortable (multi-level modelling), thinks that conventional users of XML have something to say regarding XML as a multi-level implementation. Confusing. not sure what you want to say here! Can you point to some MLHIM models that show specialisation, redefinition, clarity of expression, that sort of thing? I tried to find some but ran into raw XML source. There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. so does openEHR, that's what namespaces are about. If two groups both define a 'blood pressure' archetype today, there is an immediate problem. In the future with namespaced ids, the problem becomes manageable, since both forms can co-exist. Thanks for confirming this problem, for
The Truth About XML was: openEHR Subversion = Github move progress
Tim Cook wrote: On Thu, Apr 4, 2013 at 8:40 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: You are conflating two quite different issues. I don't think so. I demonstrated what the specifications have to say on the matter. Then pointed out that an internationally respected expert on ADL and archetypes states that this situation is unacceptable. The two issues are not a conflation. They are specifically inter-twined. Well, Tim, I just went back and had another look at the relevant few minutes of the Google hangout (http://goo.gl/UP2Z1 at around 1:05) and what I see is Bert explaining how he works around the potential for conflicts in the ADL 1.4 archetype IDs (which sound similar to the workarounds that Ian just mentioned), and Dr. Kalra replying that workarounds like that aren't going to work globally. None of that is controversial. The problem was acknowledged years ago. Then on the other hand you were quoting from the ADL 1.5 specs, which introduce the concept of namespaces to the archetype IDs, in order to solve the problem that Bert was describing. So I don't really see why you say that Dr. Kalra was responding to the ADL 1.5 namespace specs. They aren't mentioned at all in that Google hangout video, as far as I can see. Peter
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
On Fri, Apr 5, 2013 at 9:03 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: [original post by Tim bounced; reposting manually for him] Thanks Tom. I probably posted with the incorrect email address again. Arrrgh, organizing the simple things is difficult. --Tim
The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]
Cook: There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. Beale: I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. Beale: But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall On Fri, Apr 5, 2013 at 6:00 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 05/04/2013 13:03, Thomas Beale wrote: [original post by Tim bounced; reposting manually for him] On Thu, Apr 4, 2013 at 12:50 PM, Thomas Bealethomas.beale at oceaninformatics.com thomas.beale at oceaninformatics.com wrote: if you mean the competing inheritance models - I have yet to meet any XML specialist who thinks they work. The maths are against it. Interesting that you, the creator of a technology that makes many people very uncomfortable (multi-level modelling), thinks that conventional users of XML have something to say regarding XML as a multi-level implementation. Confusing. not sure what you want to say here! Can you point to some MLHIM models that show specialisation, redefinition, clarity of expression, that sort of thing? I tried to find some but ran into raw XML source. There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a long time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today. I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. so does openEHR, that's what namespaces are about. If two groups both define a 'blood pressure' archetype today, there is an immediate problem. In the future with namespaced ids, the problem becomes manageable, since both forms can co-exist. Thanks for confirming this problem, for today. I hope that people realize the potential issues that they are creating by operating outside of the eco-system. I also hope that whenever, 'the future', arrives that people will understand that the need to use this namespace capability. Are there estimates yet as to when the future will arrive? Now more or less. New versions of the documents are being published imminently, and the tooling is catching up to namespaces (also other things like annotations). - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130405/34f41dba/attachment.html
The Truth About XML was: openEHR Subversion = Github move progress
On 04/04/2013 12:09, Tim Cook wrote: well, since the primary openEHR projects are in Java, Ruby, C#, PHP, etc, I don't see where the disconnect between the projects and the talent pool is. I think if you look at the 'who is using it' pages, and also the openEHR Github projects, you won't find much that doesn't connect to the mainstream. The discussion about talent pool is about the data representation and constraint languages. XML and ADL. The development languages are common across the application domain. I know that you believe that ADL is superior because it was designed specifically to support the openEHR information model. It is an impressive piece of work, but this is where its value falls off. actually, ADL was specifically designed to not support any information model, and it doesn't. It's just an abstract syntax, free of the vagaries of any other syntax. XML has widespread industry acceptance and plethora of development and validation tools against a global standard. sure. In terms of being able to /serialise /archetypes to XML, that has been available for probably a decade, and is in wide use. Some users ignore ADL entirely. I don't think anyone has an issue with this. NB: in the below I am talking about the industry standard XSD 1.0, not the 9-month old XML Schema 1.1 spec The industry standard XML Schema Language is 1.1. The first draft was published in April 2004 making it nine years old, well, but it's been stillborn for years, everyone knows that... But XML schema as an information modelling language has been of no serious use, primarily because its inheritance model is utterly broken. There are two competing notions of specialisation - restriction and extension. Interesting. I believe that the broader industry sees them as complimentary, not competing. if you mean the competing inheritance models - I have yet to meet any XML specialist who thinks they work. The maths are against it. Restriction is not a tool you can use in object-land because the semantics are additive down the inheritance hierarchy, but you can of course try and use it for constraint modelling. Restriction, as its name implies, is exactly intended and very useful for constraint modelling. Constraint modelling by restriction is, as you know, the corner-stone of multi-level modelling. Not OO modelling. Which is, of course, why openEHR has a reference model and a constraint model. They are used for the two complimetary aspects of multi-level modelling. but your original statement was (I thought) that you are using XML for the information model as well. That's where it breaks, because of the inability to represent basic concepts like inheritance in the way that is normally used in object modelling (and most database schema languages these days). Although it is generally too weak for anything serious, and most projects I have seen going this route eventually give in and build tools to interpolate Schematron statements to do the job properly. Now you have two languages, plus you are mixing object (additive) and constraint (subtractive) modelling. Those examples you are referring to are not using XML Schema 1.1. Or at least not in its specified capacity. There is no longer a need for RelaxNG or Schematron to be mixed-in. Your information on XML technologies seems to be quite a bit out of date. I'm just reporting what I know to be the case in various current national e-health modelling initiatives, none of which I am directly involved in... all the serious ones use XSD 1.0 + Schematron. Add to this the fact that the inheritance rules for XML attributes and Elements are different, and you have a modelling disaster area. I will confess that XML attributes are, IMHO, over used and inject semantics into a model that shouldn't be there. For example HL7v3 and FHIR use them extensively. James Clark, designer of Relax NG, sees inheritance in XML as a design flaw (from http://www.thaiopensource.com/relaxng/design.html#section:15 ): Of course! But then you are referencing an undated document by the author of a competing/complimentary tool, that is announcingannounces RelaxNG as new AND its most recent reference is 2001. So, my guess is that it is at least a decade old. Hardly a valid opinion today. I can't say whether it is valid with respect to XSD 1.1, but it remains valid with respect to 1.0. I don't see that XSD 1.1 has a healthier inheritance model, so it seems to me that anyone trying to do information modelling (not constraint modelling) is still going to get into trouble. I can't see anything that contradicts Clark's statements, even if they are not from last week. But let's assume I don't know what I am talking about. It must (according to you) be easy to express e.g. this part of the openEHR RM http://www.openehr.org/local/releases/1.0.1/uml/Browsable/_9_0_76d0249_1109599337877_94556_1510Report.html in XSD 1.1. I would be
The Truth About XML was: openEHR Subversion = Github move progress
Hi Tim, I will leave the XML vs. ADL aspects for others to discuss and address your comments re namespacing. I think we all agree that openEHR artefacts need proper identification control, almost certainly something like namespacing. Some draft suggestions have been made and are carried on documentation on the openEHR website. Where I would take issue is that this implies some sort of sociological approach to enforce people to use the archetypes in the international CKM space. As an editor of these archetypes but also a consumer, I can assure you that I have no hesitation in using, or recommending the use of local archetypes wherever and whenever necessary. The only issue is that people must be aware of potential name conflicts, which I resolve by adding some kind of simple suffix to the archetypeID e.g. OBSERVATION.blood_pressure_simi.v1. Of course namespacing would be a better way of doing this but I see this a a technical issue and I do not recognise the kind of top-down mentality that you are suggesting is a blocker. Of course we would like to develop international archetypes of sufficient quality and general applicability that developers can pick these up without needing to redevelop locally. Apart from enhancing interoperability , there are clear efficiencies in re-using something that has already been developed. For every suggestion, like yours, that we are trying to enforce a top-down process, we get twice as many implementers asking why there is not an international archetype for x,y,z. IMO both perspectives are valid. I think the point re the deficiences in archetype naming is well-made, is non-contentious and is being addressed. It is easy to work around, in my experience, and is certainly not a blocker to their inclusion in real-world implementations. It is absolutely not a blocker to the development and use of local/ regional or national archetypes where the international equivalents are felt to be unsuitable, whether for technical or sociological reasons. The last 3 projects I have worked on (all major) have successfully blended international, national and vendor archetypes without any technical or sociological impediments. If the international ones fit, use them, if they don't, don't. Over time as the international ones improve, and the need to interoperate more widely also grows, I would expect to see the balance change, but it is up to the consumers to decide, where the balance of benefit lies You are conflating two quite different issues. Regards, Ian On 4 April 2013 12:09, Tim Cook tim at mlhim.org wrote: Hi Tom, On Fri, Mar 29, 2013 at 1:14 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: However, you seem to promote the idea that object oriented modelling is the only information modelling approach[1]. This is a critical failure. The are many ways to engineer software using many different modelling approaches. I don't see any problem here. The extant open 'reference implementation' of openEHR has been in Java for years now, and secondarily in Ruby (openEHR.jp) and C# (codeplex.com). The original Eiffel prototype was from nearly 10 years ago and was simply how I prototyped things from the GEHR project, while other OO languages matured. I am not sure that we have suffered any critical failure - can you point it out? If you re-read the paragraph you will note that I said that the assumption that OO modelling is mandatory, is a critical failure; not any type of language count. well, since the primary openEHR projects are in Java, Ruby, C#, PHP, etc, I don't see where the disconnect between the projects and the talent pool is. I think if you look at the 'who is using it' pages, and also the openEHR Github projects, you won't find much that doesn't connect to the mainstream. The discussion about talent pool is about the data representation and constraint languages. XML and ADL. The development languages are common across the application domain. I know that you believe that ADL is superior because it was designed specifically to support the openEHR information model. It is an impressive piece of work, but this is where its value falls off. XML has widespread industry acceptance and plethora of development and validation tools against a global standard. NB: in the below I am talking about the industry standard XSD 1.0, not the 9-month old XML Schema 1.1 spec The industry standard XML Schema Language is 1.1. The first draft was published in April 2004 making it nine years old, well I don't really have anything to add to any of that. For the moment, industry (including openEHR, which publishes XSDs for all its models for years now) is still using XML, although one has to wonder how long that will go on. A curious prognostication indeed. But XML schema as an information modelling language has been of no serious use, primarily because its inheritance model is utterly broken. There are two competing notions of
The Truth About XML was: openEHR Subversion = Github move progress
On 29/03/2013 14:15, Tim Cook wrote: Hi Tom, I have amended the Subject Line since the thread has diverged a bit. [comments inline] On Thu, Mar 28, 2013 at 9:55 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: one of the problems with LinkEHR (which does have many good features) is that it is driven off XSD. In principle, XSD is already a deformation of any but the most trivial object model, due to its non-OO semantics. As time goes on, it is clear that the XSD expression of data models like openEHR, 13606 etc will be more and more heavily optimised for XML data. This guarantees such XSDs will be a further deformation of the original object model - the view that programmers use. I agree with you that you cannot represent an object model, fully, in XML Schema language. However, you seem to promote the idea that object oriented modelling is the only information modelling approach[1]. This is a critical failure. The are many ways to engineer software using many different modelling approaches. So abstract information modelling, as you have noted, does not necessarily fit all possible software modelling approaches and it is unrealistic to think that it does. In desiging the openEHR model you chose to use object oriented modelling. The openEHR reference implementation uses a rather obscure, though quite pure, implementation language, Eiffel. I think that history has shown that this has caused some issues in development in other object oriented languages. Hi Tim, I don't see any problem here. The extant open 'reference implementation' of openEHR has been in Java for years now, and secondarily in Ruby (openEHR.jp http://openehr.jp/) and C# (codeplex.com http://openehr.codeplex.com/). The original Eiffel prototype was from nearly 10 years ago and was simply how I prototyped things from the GEHR project, while other OO languages matured. I am not sure that we have suffered any critical failure - can you point it out? So now if you build archetypes based on the XSD, you are not defining models of object data that software can use (apart from the low layer that deals with XML data conversion). I am unclear how any tool based on XSD can be used for modelling object data (and that's nearly all domain data in the world today, due to the use of object-oriented programming languages). I think that if you look, you will find that nearly all of the domain data in the world exists in SQL models, not object oriented models. So this is a rather biased statement designed to fit your message. Not a representation of reality. ok, so I'll clarify what I meant a bit: most domain (i.e. industry vertical) applications are being written in object languages these days - Java, Python, C#, C++, Ruby, etc. The software developer's view of the data is normally via the 'class' construct of those languages. You are right of course that the vast majority of the data physically resides in some RDBMS or other. However, the table view isn't the primary 'model' of the data for I would guess a majority of software systems development these days. There are of course major exceptions - systems written totally or mainly in SQL stored procedures or whatever, but new developments don't tend to go this route. In terms of sheer amount of data, these latter systems are probably still in the majority - since tax databases, military systems etc, legacy bank systems are written this way, but in terms of numbers of software projects, I am pretty sure the balance is heavily in the other direction. That said, the abstract concept of multi-level modelling, where there is the separation of a generic reference model from the domain concept models is very crucial. Another crucial factor is implementability; as promoted by the openEHR Foundation mantra, implementation, implementation, implementation. The last and possibly most crucial issue relates to implementability, which is the availability of a talent pool and tooling. In order to attract more than a handful of users to a technology there needs to exist some level of talent as well as robust and commonly available tools. The two previous paragraphs are the reasons that the Multi-Level Healthcare Information Modelling (MLHIM) project exists. well, since the primary openEHR projects are in Java, Ruby, C#, PHP, etc, I don't see where the disconnect between the projects and the talent pool is. I think if you look at the 'who is using it' pages http://www.openehr.org/who_is_using_openehr/, and also the openEHR Github projects https://github.com/openEHR, you won't find much that doesn't connect to the mainstream. MLHIM is modeled from the ground up around the W3C XML Schema Language 1.1 [2] . The reason for this is that the family of XML technologies are the most ubiquitous tools throughout the global information processing domain today. There is a significant number of open source and proprietary tools from
The Truth About XML was: openEHR Subversion = Github move progress
On 29/03/2013 16:19, Thomas Beale wrote: Hi Tim, I don't see any problem here. The extant open 'reference implementation' of openEHR has been in Java for years now, and secondarily in Ruby (openEHR.jp http://openehr.jp/) and C# (codeplex.com http://openehr.codeplex.com/). The original Eiffel prototype was from nearly 10 years ago and was simply how I prototyped things from the GEHR project, while other OO languages matured. I should make it clear that the above is not exhaustive or definitive - there is the openEHRgen framework using Groovy, at least one openEHR PHP product and much more diversity out there. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130329/b9c14232/attachment.html
openEHR Subversion = Github move progress
Hi! Apache as something called The Apache Attic for unmaintained old projects in order to keep the code/assets somewhere, see http://attic.apache.org/Perhaps we could simply have an openEHR attic project at github where each unmaintained previous project gets a sub-directory-tree. Would creating an attic be an OK plan? I am cross-posting this suggestion to the openehr-implementers mailing list where we can continue the discussion and qualified members could cast a formal vote as described on... http://www.openehr.org/programs/software/governance ...and... http://www.apache.org/foundation/voting.html If no major objections or counter-proposals are seen within a week from now I'll assume lazy consensus and create an Attic project. I think an attic is where things like the liu_knowledge_tools could go for example. Future web-policies at universities and other places are not always guaranteed to maintain old URLs and content. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Fri, Mar 22, 2013 at 12:13 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: The last of what I think are the active Subversion repositories on the old openEHR.org server has been converted to GitHub now (the Archetype Editor). Repositories which appear to be inactive but could be converted if anyone wants: - liu_knowledge_tools (Linkoping has a more recent version of this AFAIK) - the original 'knowledge' repository containing a lot of old NHS archetypes - knowledge_tools_java - not sure about this one. - ref_impl_python For those who have links, checkouts or other pointers to any openEHR SVN repositories, please now refer to the Github openEHR repositorieshttps://github.com/openEHR . Any questions like 'where did xxx go?', feel free to post them here. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130325/288216b3/attachment.html
openEHR Subversion = Github move progress
The last of what I think are the active Subversion repositories on the old openEHR.org server has been converted to GitHub now (the Archetype Editor). Repositories which appear to be inactive but could be converted if anyone wants: * liu_knowledge_tools (Linkoping has a more recent version of this AFAIK) * the original 'knowledge' repository containing a lot of old NHS archetypes * knowledge_tools_java - not sure about this one. * ref_impl_python For those who have links, checkouts or other pointers to any openEHR SVN repositories, please now refer to the Github openEHR repositories https://github.com/openEHR. Any questions like 'where did xxx go?', feel free to post them here. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130321/daea12b2/attachment.html
