[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. > but your original statement was (I thought) that you are using XML for the > information model as well. Not specifically. We knew that we wanted to exercise all of the capabilities of XML in actual implementation. So, when building th information model we remained conscious of that fact. So, we knew there were limitations. Otherwise, the model would just be openEHR without the EHR structures. But, we wanted to be better prepared for implementability without having to build all of the tools and technologies that already exist. We took a great idea and used pragmatism on it. > 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 looooong 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. The conceptual model expressed as a mindmap (XMind template): https://github.com/mlhim/tools/blob/master/xmind_templates/MLHIM_Model-2.4.2.xmt A UML(ish) view: https://drive.google.com/a/mlhim.org/?tab=mo#folders/0B9KiX8eH4fiKUFhTb2w2ZGJlWVU I know that there is now a convention to express XML in UML models but I have not had the time to study it properly. There are examples; from instance data -> CCDs -> RM along with documentation and XQL examples: https://github.com/mlhim/tech-docs There are more than 1500 CCDs published on the Healthcare Knowledge Component Repository site: http://www.hkcr.net/ Historical code and other information is on Launchpad along with sub-projects at:http://launchpad.net/mlhim HTH. Thanks for asking. > well that's just the point, they don't - it's possible to define a model so > that an XSD form, a programming form, a display screen form and many others > are all derivable from that source model. We only want to define the model > of 'microbiology result' once, after all. This single-source modelling is a > key goal of the approach. Right and being able to be 'transformed' into all of those expressions is what the XML family of tools is very well known for. So, I misunderstood your original comment. > there is no data in ADL, only models. Not sure what you are trying to say > here.... Really? I have seen several examples of dADL with instance information in it. > well, pretty much the whole world is using programming languages that are > essentially object-oriented or object-enabled - even uber languages like > Haskell do most OO tricks. You're using Python, that's an OO language. > That is true. And each and every one of them have binding libraries to XML Schema. > It must (according to you) be easy to express e.g. this part of the openEHR > RM in XSD 1.1. I would be very interested to see how it deals > with the > generic types and inheritance, both handled by any normal programming > language. I don't think you will find where I ever used the word easy. But yes it is possible. If you are interested enough to study then you can discover how it can be done. Prior to removing the unnecessary things from the RM (for MLHIM 2.x), MLHIM was openEHR 1.0.1 compliant. I am not sure now if those artifacts exist. You can check on Launchpad. > XML wasn't designed for data representation, it was designed for structured > document mark-up. That's why it's so horrible for data representation. > That is technically true; originally. However, it is not representative of what XML is today and is the reason why XML Schema was designed and revised. In your opinion it is horrible but there is a global industry that doesn't agree with you. > well let me just point to a single feature of object languages (including > ADL) - inheritance / specialisation. Are you saying that's of no use? How do > you propose to adapt a model that you have to include local needs, without > breaking the parent model semantics? Witness my use of XML Schema 1.1 Yes, it makes some XML users uncomfortable too because it is unconventional. But it is standards compliant, valid and allows for valid CCDs and instance data. But then, you don't have to take my word for it. The examples are there. USe your favorite off-the-shelf parser/validator that supports 1.1 (Xerces and Saxon come to mind) and see for yourself. I won't discuss the merits of using or not using XML any further. You may or may not agree with me. But I am very confident in my multi-level model approach along with the use of RDF metadata to extend semantics as the modeller sees fit. MLHIM is a platform to provide semantic interoperability. We don't tell you how to structure your application data (outside of having a small concept instance). We don't tell you how to do workflow (though there are hooks to enable it) nor do we tell you how to build your APIs. The information industry has published an enormous amount of openly available documentation on using XML instance data "in healthcare" in these scenarios. MLHIM only provides a structure to separate the reference and domain models. There is only enough semantics in the RM to the separation of categories such as clinical, demographic and admin entries. Semantics in healthcare are well defined in ontologies and controlled vocabularies are are referenceable via RDF. > if you can point to some online MLHIM models so we can see the result - the > information model, and layers of MLHIM archetypes specialised based on that, > it would be very helpful. > See above. But you first need to realize that specialization is not a necessary feature and is infact quite messy. At least according to the domain experts that I have had discussions with in attempting to specialize the 12 archetypes on the CKM. I think that by now it is evident that people and groups of people want to define their models and use them. Whether or not their model fits some some definition of maximal coverage. Unless you have an actual maximal coverage archetype, there will be missing concepts for some sub-domains. So, we removed that approach in our definition of multi-level modelling. > Firstly , we are in the process of rewriting this, but also I think you > misread what it said (which might not have been very clear) - it's saying > that machine ids are computable (obviously they are, at a basic level) > Okay, well that document was written in 2009 and revised in 2010. It is in the published branch. > Archetypes on the NEHTA CKMhttp://dcm.nehta.org.au/ckm/ carry only > the openEHR RM namespace. > So, are therefore uncontrolled and of unknown quality; by openEHR > definition. > > > the spec you are quoting from is about the future of identification, not the > past (or present). > It is difficult to tell from the various arguments whether this should be considered to be part of the spec or not. On one hand we are told that the problem with conflicting IDs has been addressed. Then in another context, we are told that I am quoting from a 'future' document. My point is; people are building systems and not adhering to the full specifications. I just think it is important for everyone to know that the openEHR eco-system is very well engineered and it will only work correctly when all of the parts are implemented correctly. >> The openEHR eco-system is well engineered. It just isn't >> sociologically acceptable. People want to be free to >> design their concept models without top-down consensus. MLHIM allows >> that with industry standard, off the shelf tooling. > 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? > I followed some of your URLs, but I still can't locate a) the MLHIM > reference model or any b) MLHIM archetypes that I can understand / read. I > know they are lurking out there somewhere... can you provide some links? > If the links above do not answer your questions please inquire on the MLHIM Google Plus page(s) or on the mailing lists from Launchpad. Have a great day. --Tim ============================================ Timothy Cook, MSc +55 21 94711995 MLHIMhttp://www.mlhim.org Like Us on FB:https://www.facebook.com/mlhim2 Circle us on G+:http://goo.gl/44EV5 Google Scholar:http://goo.gl/MMZ1o LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130405/5e23bf96/attachment.html>
