About openEHR BMM
Bert Verhees wrote: I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. - Both are not configurable. I would like to have an archetype editor which can be feeded with some RM-definition, and configured to use it, and then is being able to create archetypes following that definition. ... Do you know how I create archetypes (I don't if I can someone else having to do it :), but I work my way in LinkEHR or the Ocean editor, and edit them manually in a text-editor, with syntax-highlighting. Hi Bert, Problems with the Ocean Archetype Editor should be reported to http://www.openehr.org/issues/issues/?jql=project%20%3D%20AEPR . The Ocean Archetype Editor only gets worked on when we have spare time, or if there is a pressing business requirement for us to fix something in it, so mentioning a problem on a mailing list is not likely to get it fixed. If you have examples of archetypes generated by LinkEHR that are not handled properly by the Ocean Archetype Editor, please attach them to your problem report. Alternatively, you could try fixing it yourself. I recall that you compiled it under Mono a few years ago, but you had a problem that there were dependencies on some DLLs that only worked under Windows. We have removed those dependencies, so you should be able to build it successfully under Mono these days. But I understand that you're a very busy guy yourself, so submitting a problem report would probably be best ;-) Peter
About openEHR BMM
Hi, If we see the multi-axial identifier not as a fixed string, but a computed output from a bunch of identifying meta-data, as per the recent knowledge identification proposal updatehttp://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts, then we should consider adding the rm_release to these items. Then it is just a case of defining a function that includes it in one of (possibly many) ids. I didn't think to include it in this draft, but we can do that. I still don't believe it's useful in the primary multi-axial ontological identifier, because there is no certain computational relationship between an archetype and a given release of the RM. Some archetypes will be valid for many releases, others for only one. But having it in the archetype meta-data is a good idea, because that nails down at least the release at which the archetype was created. Then it can be interrogated by some sort of compatibility testing tools. David, can I suggest you add a comment in the feedback table on that page, so I don't forget to do this. Exactly, that was one of the original ideas, at least add that RM version information at the archetype header. As you say, that only indicates the version used to create the archetype and not the compatibility with other versions of the RM (forward or backward). That could be even added also as metadata: rm_compatibility = openEHR-RM_1.0.0, openEHR-RM_1.0.1 Since we can have all the RM versions loaded at the tools it should be quite easy to check the validity towards all of them automatically. you probably should also report a relevant summary of these points on the CIMI list and/or to Michael van der Zel so he can fix his generator. I wasn't aware that the CIMI BMM was automatically generated by Michael, that explains many of the cases. I'll contact him. - Need of visualization information. There are two properties defined related to visualization of the model. The archetype_data_value_parent_class property is defined at the documentation as a base class from the Reference Model whose descendants are considered to be 'logical data types [...] is only used to help tooling provide more intelligent display. The archetype_visualise_descendants_of property is used to designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. In order to repeat some of the problems of existing model representation, such as XMI, we should avoid polluting the pure RM definition from visualization or user-oriented metainformation. At the end that only complicates the BMM format. The representation of that metainformation should not be part of the BMM requirements. I do agree that in general XMI suffers from this, I am not sure if I agree that the above items are a big problem in BMM at a practical level (in XMI land, the graphical stuff can be all over the place and is complex). But in any case, they could be made to disappear from the .bmm files with the use of 'archetype repository profile' (.arp) files or maybe some other future alternative. At the moment I am not sure if it is worth the trouble until we have a proper concept of ARPs. Dave Carlson wants to use these to store some general meta-data for models, but noone has really agreed on what is required. For me those visualization characteristics are more about preferences of each tool/user. So it's fine for me to separate them in a different place, where they can be modified without changing the model itself, whose definition should remain immutable. That, said, I must say that we are not big fans of BMM :-) While we agree that current alternatives (i.e XMI) are not usable in practice nowadays, we find extremely improbable that BMM gains big acceptance outside the openEHR world. I doubt that we ever see the HL7 CDA model expressed in BMM for example. So we decided to support it as another option, but we still hope that the industry finds a way to agree on a common usable format for defining models. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/17abd27a/attachment-0001.html
About openEHR BMM
There is plenty of people working on this, mostly from the semantic point of view. Apart from the works in CIMI, I must point to our colleagues at the University of Murcia that have been working for years in reference model conversions using semantic web technologies: http://webs.um.es/jfernand/miwiki/doku.php?id=projects:poseacle_gen POSEACLE converter: http://miuras.inf.um.es:9080/PoseacleConverter/ 2013/5/2 pablo pazos pazospablo at hotmail.com Great! BTW, it will be really useful to have multi-model tools. I was thinking if multi-model apps could be also useful, e.g. to have different persistent structures. My guess is that app can implement one canonical model (e.g. openEHR RM) and then map to other models e.g. for instance transformation and output purposes. My idea: what do you think about creating some kind of mapping language, to specify correspondences between BMM models? (e.g. using semantic mappings/relationships to tell if one class in model A is equivalent/more generic/more specific/... to other class in model B). There are many kinds of semantic correspondence between models, e.g. a class in one model can map to a property in another model, etc... The idea behind that is that using the mapping information and an input instance schema (in the canonical model), and maybe some input or cursomization from the user/designer, a complete transformation definition can be created, so automatic transformation from an instance in the canonical model to some output model (13606, CDA, ...) can be done. Is this idea to crazy or do you think it can be useful to have something like that? Anyone is working on something like that? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com http://cabolabs.com/es/homehttp://twitter.com/ppazos -- Date: Wed, 1 May 2013 16:07:08 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: About openEHR BMM On 01/05/2013 14:48, pablo pazos wrote: Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? wait time = 5 days - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/59641c13/attachment.html
About openEHR BMM
Hi Bert I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. I remember that list of problems, and some of them can be resolved and it is our fault not to have resolved some of them yet. But there are others that are not so easy to address since they are related to the basic internal philosophy of the tool, such use adding an id to every node. We'll try tu publish an updated version of the editor sooner than later. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/9c341cd1/attachment.html
About openEHR BMM
On 02/05/2013 08:36, David Moner wrote: Hi, Exactly, that was one of the original ideas, at least add that RM version information at the archetype header. As you say, that only indicates the version used to create the archetype and not the compatibility with other versions of the RM (forward or backward). That could be even added also as metadata: rm_compatibility = openEHR-RM_1.0.0, openEHR-RM_1.0.1 Since we can have all the RM versions loaded at the tools it should be quite easy to check the validity towards all of them automatically. I would suggest we don't include this list in the archetypes themselves, because it can easily change as more testing is done - and that would mean reversioning and releasing archetypes as this happens - even though nothing has changed in the archetype. So I would suggest we need to conceive of some functions in a registry service that provides this information. For me those visualization characteristics are more about preferences of each tool/user. So it's fine for me to separate them in a different place, where they can be modified without changing the model itself, whose definition should remain immutable. maybe 'tool preferences' is the way to go.. That, said, I must say that we are not big fans of BMM :-) While we agree that current alternatives (i.e XMI) are not usable in practice nowadays, we find extremely improbable that BMM gains big acceptance outside the openEHR world. I doubt that we ever see the HL7 CDA model expressed in BMM for example. So we decided to support it as another option, but we still hope that the industry finds a way to agree on a common usable format for defining models. well, as I said earlier, I built it over a weekend because none of the current options were palatable. I still don't see a clear better solution than BMM to our current model interop needs - today. My feeling is that something may emerge out of Ecore that can be usable. Right now, I am not sure still that it is semantically powerful enough. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/9b9427cd/attachment.html
About openEHR BMM
Hi David, I wonder if this be a point in time where it is worth clearly documenting the differences and agreeing to get them resolved. Before long the Foundation will start to explore a product accreditation mechanism which will include archetype authoring tools, and will need formal conformance criteria. It would be good to re-visit Bert's concerns. If we had better conformance then some thing like the lack of Demographics model support in the Ocean tool would be much less of an issue. Ian On 2 May 2013 08:56, David Moner damoca at gmail.com wrote: Hi Bert I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. I remember that list of problems, and some of them can be resolved and it is our fault not to have resolved some of them yet. But there are others that are not so easy to address since they are related to the basic internal philosophy of the tool, such use adding an id to every node. We'll try tu publish an updated version of the editor sooner than later. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
About openEHR BMM
all these criticisms are fair, and need to be addressed. I am hoping that we can get some combined effort from various vendors and others to work on a more coherent new generation of tools. The tool space is changing a lot, and it may be that the strategy is to target Eclipse with a group of plug-ins that together provide a good quality integrated modelling experience. I don't believe this is that hard to achieve - most of the difficult algorithms have been worked out in existing tools, so a fair bit of logic can be ported or re-used. Expect some announcements on this in the near future, and be prepared to contribute! Would be good to try to reach some collaboration. The new Eclipse 4.2 is really a good platform. As you can see what LinkEHR achieved with a previous 3.x version, and also other examples. One could also think about editors, and also archetype-editors, a platform in which several OpenEHR tools are combined. When time comes, we should maybe assign tasks to volunteers. - Until now LinkEHR used XML-Schema, which is good enough for expressing an master-RM. I am satisfied with any other way too, XMI, for example. I know there is a lot of bad XMI-software, this is because vendors try to put all kind of things in it, which should not be in it, and in this way they make it incompatible. But XMI itself, it is a well defined standard from OMG. It is also a very succesful standard. I think it must be possible to validate and use it in a standardized way. actually this is not true to date; I happen to be in communication with some of the relevant OMG people, and XMI has been recognised as a 'historically serious problem' by OMG at a recent board meeting, and is being treated as almost an emergency situation. This was because many tools did not respect the spec, made implementation choices where the spec was lacking, possibly as well as adding things of their own. My impression is that now, i.e. 2013 going forward, things should improve reasonably rapidly. But prior to now, XMI has been a nearly unusable format for practical purposes. I didn't know that, what you say about XMI, too bad that it happened. The idea for that kind of standard is good. I never studied the software-vendors well, but I think there must be good XMI-producing software. You mention BOUML, I know the product, it has a plugin-interface, at least i - My problem is, when you are going to use software which can only run from Windows and you need to create parsers to understand the output (like LinkEHR has published a grammar-file), it will be a stony road, with hard to solve bugs and incompatibility situations. We have seen that until now, only two archetype-editors on the market, and after five years, still not compatible. You mean EA I presume? I think the next step is to see if we can replicate the EA plug-in in other UML tools. BOUML for example runs on all 3 major platforms, and Rational Software Architect must as well, since it's Eclipse based. So this is just a piece of work for someone to do. I am sure Michael will publish his plug-in for use by others. No, no, BOUML has a plugin interface, I accidentally saw on their website, but I read again, it is a plug-out-interface ;-) I don't know what the word means. As I understand you are planning to use a niche definition, which can only be created by one vendor (Enterprise Architect) and let important software (archetype-editors) rely on that. it's what we did so far, because at the point when we needed a solution, there simply was nothing working that we could just use. For a future plan... there isn't a defined plan yet, I think it is up to people here to help define it. The two things I think are important are a) that the /semantics/ of the BMM schemas can be supported by other solutions and tools and b) that a schema file is human readable and writable. We might be able to migrate to using some Ecore syntax, and/or XMI. I personally have not had the time to go and look at this. One thing the BMM format has achieved which we could not in any other way has been to connect the following tools together: * at least one UML tool (so far: EA) * the ADL 1.5 Workbench * the LinkEHR tool * tools that Intermountain health are developing to produce archetypes from Intermountain / GE Clinical Element Models If we replace this connectivity by another method, as long as it works, let's do it. It's just a question of determining a coherent strategy together. Maybe just forget my criticism, I don't have really good reasons against BMM, I just have a natural aversion against new formats. Especially if the tooling is expensive and does not run out of the box on my favorite platform. For EA I need to install Codeweavers to get it to run, I once did something like that, it was a drama. First by Codeweavers, then buy EA, then spend a
About openEHR BMM
On 05/02/2013 09:56 AM, David Moner wrote: We'll try tu publish an updated version of the editor sooner than later. Don't forget the 64 bits version for Linux. ;-) It is really hard, paths and that kind of annoyance, to have a 32 bits version of Java running on the same OS where a 64 bits Java version is default. Bert
About openEHR BMM
On 05/02/2013 10:47 AM, Ian McNicoll wrote: It would be good to re-visit Bert's concerns. If we had better conformance then some thing like the lack of Demographics model support in the Ocean tool would be much less of an issue. I completely agree. It must be possible to find the messages, it is better then me working again a day or so, to document what is wrong. It are no big things, but enough to make the combination of the two nearly impossible, and people end up working in their text-editors. I have seen that happen many times. Bert
About openEHR BMM
On 05/02/2013 09:56 AM, David Moner wrote: But there are others that are not so easy to address since they are related to the basic internal philosophy of the tool, such use adding an id to every node. Of course I don't know the structure of your software, but having a configuration-switch in a dialog to put off/on the node-id's on datavalues would really be a great improvement. Bert
About openEHR BMM
Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect - CodeWeavers' Crossover 10.0.3 (or later), Microsoft Data Access Components (MDAC) 2.8, DCOM95, Internet Explorer 6 Stupid product, EA, cannot be used in an environment based on international standards, but is even when used on Mac of Linux depending on Internet Explorer and Microsoft Database Access Extensions. Probably to lazy to develop their products in a vendor-independent way. If in this way EA gets the status of preferred third party tooling for modeling in OpenEhr context, I think, that it is a very bad evolution. Bert that traverses a UML model in memory and pumps out a BMM schema for it. So now we have a nice way of having a primary UML model expression and a generated tool-consumable format (BMM schemas), which will help tool chains components to communicate - right now the ADL workbench and now LinkEHR can consume it. The converter is pretty good right now, but David Moner's group has obviously found a few more bugs than I found, which is good - hopefully we can converge on a very tight version of the EA converter soon. Then the same thing can be done with openEHR, 13606, any other model in EA, which means we have a way of representing a RM in UML, and driving archetype tools from that. I'm just putting together a GitHub repo now for it on which I'll post a spec, the class models I use (in UML) and pointers to every implementation we can find. - 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/20130501/336803d7/attachment.html
About openEHR BMM
Hi Bert, we're not in the business of endorsing UML products, but the UML situation is always murky. In theory anyone should be able to share models saved in XMI format. Historically that never worked - each tool's XMI was broken in different ways, the XMI specification itself is unclear and vastly over-complicated (as is the underlying meta-model for UML). So let's say the openEHR community would like some proper computable UML models... what do we do? The most recent attempt was done in a tool called BOUML http://bouml.fr/, which was free and is now a pay-for tool (about EUR50). It output generation of XMI and code is superior from what I can work out and it has good support. So I took the work of Eric Browne who built most of the RM in that tool, finished it (more or less) and you can see the XMI files online in the GitHub reference-models repository https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.2/UML. This XMI file was used as the original input to EA, which more people seem to use, in CIMI, and it nearly worked. There were some errors, and the BOUML vendors fixed that very quickly. EA's XMI import was the main problem however, but to their credit, Sparx also made fixes to improve it in the last 12 months. I think the Rational tool was also able to import this XMI. So it appears that we are getting closer to XMI becoming a trustworthy format, and if we continue to publish an XMI file from a reliable tool, and put pressure on vendors whose XMI doesn't work (along with everyone else in the world who is in a similar situation), the various tools should eventually converge on being able to talk the same XMI. I think that's about the best we can do. Do you have other suggestions? Let me explain my problems and what I wish and what I think about doing about that, and than what my problem is with the BMM-solution - I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. - Both are not configurable. I would like to have an archetype editor which can be feeded with some RM-definition, and configured to use it, and then is being able to create archetypes following that definition. - That does not exist, I like to build it myself, (when I have time). It is not very difficult, there is already code which can be used for understanding, from LiU, so half of the wheel is already invented. I think I need three months to do so. So I want to to build any RM depending on the feed-file. I would, like LinkEHR, build in in Java, in a eclipse-framework is easy. The archetype-editor should export to ADL, but also export to an XML-schema language, probably Relax NG. - Until now LinkEHR used XML-Schema, which is good enough for expressing an master-RM. I am satisfied with any other way too, XMI, for example. I know there is a lot of bad XMI-software, this is because vendors try to put all kind of things in it, which should not be in it, and in this way they make it incompatible. But XMI itself, it is a well defined standard from OMG. It is also a very succesful standard. I think it must be possible to validate and use it in a standardized way. I never studied the software-vendors well, but I think there must be good XMI-producing software. You mention BOUML, I know the product, it has a plugin-interface, at least i - My problem is, when you are going to use software which can only run from Windows and you need to create parsers to understand the output (like LinkEHR has published a grammar-file), it will be a stony road, with hard to solve bugs and incompatibility situations. We have seen that until now, only two archetype-editors on the market, and after five years, still not compatible. As I understand you are planning to use a niche definition, which can only be created by one vendor (Enterprise Architect) and let important software (archetype-editors) rely on that. Does not seem wise to me. It would be a big improvement if the BMM-files were in XML, even (but not directly necessary) with a schema to validate them. Then anyone can created them, and it is easy to build tooling, a Reference Model editor, next to an archetype editor. - Do you know how I create archetypes (I don't if I can someone else having to do it :), but I work my way in LinkEHR or the Ocean editor, and edit them manually in a text-editor, with syntax-highlighting. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/4c97e5e3/attachment-0001.html
About openEHR BMM
On 05/01/2013 03:24 PM, Peter Gummer wrote: Bert Verhees wrote: I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. - Both are not configurable. I would like to have an archetype editor which can be feeded with some RM-definition, and configured to use it, and then is being able to create archetypes following that definition. ... Do you know how I create archetypes (I don't if I can someone else having to do it :), but I work my way in LinkEHR or the Ocean editor, and edit them manually in a text-editor, with syntax-highlighting. Hi Bert, Problems with the Ocean Archetype Editor should be reported to http://www.openehr.org/issues/issues/?jql=project%20%3D%20AEPR . The Ocean Archetype Editor only gets worked on when we have spare time, or if there is a pressing business requirement for us to fix something in it, so mentioning a problem on a mailing list is not likely to get it fixed. If you have examples of archetypes generated by LinkEHR that are not handled properly by the Ocean Archetype Editor, please attach them to your problem report. Alternatively, you could try fixing it yourself. I recall that you compiled it under Mono a few years ago, but you had a problem that there were dependencies on some DLLs that only worked under Windows. We have removed those dependencies, so you should be able to build it successfully under Mono these days. But I understand that you're a very busy guy yourself, so submitting a problem report would probably be best ;-) Thanks Peter, I will investigate the problem again, so I can write a problem report. Thanks for removing those dependencies, good that you remember that ;-) Bert
About openEHR BMM
On 01/05/2013 10:28, Bert Verhees wrote: Let me explain my problems and what I wish and what I think about doing about that, and than what my problem is with the BMM-solution - I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. - Both are not configurable. I would like to have an archetype editor which can be feeded with some RM-definition, and configured to use it, and then is being able to create archetypes following that definition. - That does not exist, I like to build it myself, (when I have time). It is not very difficult, there is already code which can be used for understanding, from LiU, so half of the wheel is already invented. I think I need three months to do so. So I want to to build any RM depending on the feed-file. I would, like LinkEHR, build in in Java, in a eclipse-framework is easy. The archetype-editor should export to ADL, but also export to an XML-schema language, probably Relax NG. all these criticisms are fair, and need to be addressed. I am hoping that we can get some combined effort from various vendors and others to work on a more coherent new generation of tools. The tool space is changing a lot, and it may be that the strategy is to target Eclipse with a group of plug-ins that together provide a good quality integrated modelling experience. I don't believe this is that hard to achieve - most of the difficult algorithms have been worked out in existing tools, so a fair bit of logic can be ported or re-used. Expect some announcements on this in the near future, and be prepared to contribute! - Until now LinkEHR used XML-Schema, which is good enough for expressing an master-RM. I am satisfied with any other way too, XMI, for example. I know there is a lot of bad XMI-software, this is because vendors try to put all kind of things in it, which should not be in it, and in this way they make it incompatible. But XMI itself, it is a well defined standard from OMG. It is also a very succesful standard. I think it must be possible to validate and use it in a standardized way. actually this is not true to date; I happen to be in communication with some of the relevant OMG people, and XMI has been recognised as a 'historically serious problem' by OMG at a recent board meeting, and is being treated as almost an emergency situation. This was because many tools did not respect the spec, made implementation choices where the spec was lacking, possibly as well as adding things of their own. My impression is that now, i.e. 2013 going forward, things should improve reasonably rapidly. But prior to now, XMI has been a nearly unusable format for practical purposes. I never studied the software-vendors well, but I think there must be good XMI-producing software. You mention BOUML, I know the product, it has a plugin-interface, at least i - My problem is, when you are going to use software which can only run from Windows and you need to create parsers to understand the output (like LinkEHR has published a grammar-file), it will be a stony road, with hard to solve bugs and incompatibility situations. We have seen that until now, only two archetype-editors on the market, and after five years, still not compatible. You mean EA I presume? I think the next step is to see if we can replicate the EA plug-in in other UML tools. BOUML for example runs on all 3 major platforms, and Rational Software Architect must as well, since it's Eclipse based. So this is just a piece of work for someone to do. I am sure Michael will publish his plug-in for use by others. As I understand you are planning to use a niche definition, which can only be created by one vendor (Enterprise Architect) and let important software (archetype-editors) rely on that. it's what we did so far, because at the point when we needed a solution, there simply was nothing working that we could just use. For a future plan... there isn't a defined plan yet, I think it is up to people here to help define it. The two things I think are important are a) that the /semantics/ of the BMM schemas can be supported by other solutions and tools and b) that a schema file is human readable and writable. We might be able to migrate to using some Ecore syntax, and/or XMI. I personally have not had the time to go and look at this. One thing the BMM format has achieved which we could not in any other way has been to connect the following tools together: * at least one UML tool (so far: EA) * the ADL 1.5 Workbench * the LinkEHR tool * tools that Intermountain health are developing to produce
About openEHR BMM
Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 30 Apr 2013 19:09:15 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: About openEHR BMM On 30/04/2013 18:30, Diego Bosc? wrote: I think Thomas created it from scratch. There is a page on the wiki discussing it (http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR), but we studied mostly to the bmm files included on the archetype workbench in order to understand it. yep. That link explains why I did it. Simple summary: XMI is a horror and hardly works between tools that implement it (and there is no hope of hand-writing an XMI schema). And Ecore was broken for generic types. We might converge to some Ecore/EMF format at some point, but right now, BMM is a nice lightweight format, and works ok. Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect that traverses a UML model in memory and pumps out a BMM schema for it. So now we have a nice way of having a primary UML model expression and a generated tool-consumable format (BMM schemas), which will help tool chains components to communicate - right now the ADL workbench and now LinkEHR can consume it. The converter is pretty good right now, but David Moner's group has obviously found a few more bugs than I found, which is good - hopefully we can converge on a very tight version of the EA converter soon. Then the same thing can be done with openEHR, 13606, any other model in EA, which means we have a way of representing a RM in UML, and driving archetype tools from that. I'm just putting together a GitHub repo now for it on which I'll post a spec, the class models I use (in UML) and pointers to every implementation we can find. - 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/20130501/ea76cb21/attachment.html
About openEHR BMM
We don't. I had a look to XMI back in the day, but discarded it for being a mess (too vendor specific). On the other hand generating a clean XMI from archetypes could be a good idea. 2013/5/1 pablo pazos pazospablo at hotmail.com: Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 30 Apr 2013 19:09:15 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: About openEHR BMM On 30/04/2013 18:30, Diego Bosc? wrote: I think Thomas created it from scratch. There is a page on the wiki discussing it (http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR), but we studied mostly to the bmm files included on the archetype workbench in order to understand it. yep. That link explains why I did it. Simple summary: XMI is a horror and hardly works between tools that implement it (and there is no hope of hand-writing an XMI schema). And Ecore was broken for generic types. We might converge to some Ecore/EMF format at some point, but right now, BMM is a nice lightweight format, and works ok. Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect that traverses a UML model in memory and pumps out a BMM schema for it. So now we have a nice way of having a primary UML model expression and a generated tool-consumable format (BMM schemas), which will help tool chains components to communicate - right now the ADL workbench and now LinkEHR can consume it. The converter is pretty good right now, but David Moner's group has obviously found a few more bugs than I found, which is good - hopefully we can converge on a very tight version of the EA converter soon. Then the same thing can be done with openEHR, 13606, any other model in EA, which means we have a way of representing a RM in UML, and driving archetype tools from that. I'm just putting together a GitHub repo now for it on which I'll post a spec, the class models I use (in UML) and pointers to every implementation we can find. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
About openEHR BMM
On 01/05/2013 14:48, pablo pazos wrote: Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? wait time = 5 days - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/baa33b21/attachment.html
About openEHR BMM
Yep XMI is tough... A short time ago I thought about adapting the .DIA * XML format to represent UML diagrams (cleaning the graphic part and leaving only the structure of the model). My idea was to do some code generation targeting Java/Groovy from the DIA diagrams directly to simplify my development process. This can be easily done using something like FreeMarker **. The problems are: 1. .DIA is not a standard and is more for graphical information than information structures and 2. there is no clear standard to represent UML class models in XML. E.g. this can be used to generate reference implementations of any openEHR spec targeting multiple programming languages, so when specs change, we can generate our implementations automatically. Obviously this strongly depends on the tools used to create UML diagrams, and I suspect the tools currently used are propietary as the current tools/formats for spec documentation. * DIA is an open source UML modeller I use a lot, and it's output format is XML: https://live.gnome.org/Dia** http://freemarker.sourceforge.net -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com From: yampeku at gmail.com Date: Wed, 1 May 2013 16:02:21 +0200 Subject: Re: About openEHR BMM To: openehr-technical at lists.openehr.org We don't. I had a look to XMI back in the day, but discarded it for being a mess (too vendor specific). On the other hand generating a clean XMI from archetypes could be a good idea. 2013/5/1 pablo pazos pazospablo at hotmail.com: Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 30 Apr 2013 19:09:15 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: About openEHR BMM On 30/04/2013 18:30, Diego Bosc? wrote: I think Thomas created it from scratch. There is a page on the wiki discussing it (http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR), but we studied mostly to the bmm files included on the archetype workbench in order to understand it. yep. That link explains why I did it. Simple summary: XMI is a horror and hardly works between tools that implement it (and there is no hope of hand-writing an XMI schema). And Ecore was broken for generic types. We might converge to some Ecore/EMF format at some point, but right now, BMM is a nice lightweight format, and works ok. Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect that traverses a UML model in memory and pumps out a BMM schema for it. So now we have a nice way of having a primary UML model expression and a generated tool-consumable format (BMM schemas), which will help tool chains components to communicate - right now the ADL workbench and now LinkEHR can consume it. The converter is pretty good right now, but David Moner's group has obviously found a few more bugs than I found, which is good - hopefully we can converge on a very tight version of the EA converter soon. Then the same thing can be done with openEHR, 13606, any other model in EA, which means we have a way of representing a RM in UML, and driving archetype tools from that. I'm just putting together a GitHub repo now for it on which I'll post a spec, the class models I use (in UML) and pointers to every implementation we can find. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ 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/20130501/a77bf7da/attachment.html
About openEHR BMM
Great! BTW, it will be really useful to have multi-model tools. I was thinking if multi-model apps could be also useful, e.g. to have different persistent structures. My guess is that app can implement one canonical model (e.g. openEHR RM) and then map to other models e.g. for instance transformation and output purposes. My idea: what do you think about creating some kind of mapping language, to specify correspondences between BMM models? (e.g. using semantic mappings/relationships to tell if one class in model A is equivalent/more generic/more specific/... to other class in model B). There are many kinds of semantic correspondence between models, e.g. a class in one model can map to a property in another model, etc... The idea behind that is that using the mapping information and an input instance schema (in the canonical model), and maybe some input or cursomization from the user/designer, a complete transformation definition can be created, so automatic transformation from an instance in the canonical model to some output model (13606, CDA, ...) can be done. Is this idea to crazy or do you think it can be useful to have something like that?Anyone is working on something like that? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com Date: Wed, 1 May 2013 16:07:08 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: About openEHR BMM On 01/05/2013 14:48, pablo pazos wrote: Hi Thomas, having a small spec would be great, thanks! BTW, does anyone use XML representation of UML diagrams to process class models? wait time = 5 days - 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/20130501/1c5ce1f6/attachment.html
About openEHR BMM
On 30/04/2013 23:45, Bert Verhees wrote: Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect Stupid product, EA, cannot be used in an environment based on international standards, but is even when used on Mac of Linux depending on Internet Explorer and Microsoft Database Access Extensions. Probably to lazy to develop their products in a vendor-independent way. If in this way EA gets the status of preferred third party tooling for modeling in OpenEhr context, I think, that it is a very bad evolution. Hi Bert, we're not in the business of endorsing UML products, but the UML situation is always murky. In theory anyone should be able to share models saved in XMI format. Historically that never worked - each tool's XMI was broken in different ways, the XMI specification itself is unclear and vastly over-complicated (as is the underlying meta-model for UML). So let's say the openEHR community would like some proper computable UML models... what do we do? The most recent attempt was done in a tool called BOUML http://bouml.fr/, which was free and is now a pay-for tool (about EUR50). It output generation of XMI and code is superior from what I can work out and it has good support. So I took the work of Eric Browne who built most of the RM in that tool, finished it (more or less) and you can see the XMI files online in the GitHub reference-models repository https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.2/UML. This XMI file was used as the original input to EA, which more people seem to use, in CIMI, and it nearly worked. There were some errors, and the BOUML vendors fixed that very quickly. EA's XMI import was the main problem however, but to their credit, Sparx also made fixes to improve it in the last 12 months. I think the Rational tool was also able to import this XMI. So it appears that we are getting closer to XMI becoming a trustworthy format, and if we continue to publish an XMI file from a reliable tool, and put pressure on vendors whose XMI doesn't work (along with everyone else in the world who is in a similar situation), the various tools should eventually converge on being able to talk the same XMI. I think that's about the best we can do. Do you have other suggestions? - thomas BTW I will regenerate the online XMI with the latest BOUML tool. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/325234f1/attachment.html
About openEHR BMM
Hello all, We have just implemented the support of Basic Meta Model files (BMM) in LinkEHR Editor as a format to import new reference models into the tool. First of all, I think that it is necessary to clarify some erroneous ideas or misunderstandings about LinkEHR that have been recently published. Until now, LinkEHR used XML Schema as an input format to define reference models. It is analyzed to create the internal information structures needed to edit archetypes based in that model. Internally, LinkEHR follows a pure implementation of the AOM 1.4 model so that the only limits of the tool are what can be expressed as an archetype. The decision to support XML Schema as an input format is based on the fact that many reference models are only or normatively expressed in that way (for example HL7 CDA, HL7 CCD or CDISC ODM). This has nothing to do with the discussion about the expressiveness of the XML Schema language, but just a solution needed to support some daily used and well established models such as CDA. That said, we decided to implement the support of BMM definitions as an additional input format to XML Schema, in order to extend the possibilities of the tool. That implementation took around three days and the only problems came from the interpretation of the BMM format. Some doubts arose and we want to share them for discussion. - Schema identification. This is just a curiosity. The BMM identification includes the following information. It is curious that here the RM release is required as part of the identification schema (which is completely logical), but it is not used for the generation of the archetype identifier or archetype header to make its localization safer, as we have requested some time in the past ( http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005943.html ). rm_publisher = openehr schema_name = rm rm_release = 1.0.2 - Order of the properties. It is not specified if there is an order of appearance of all reserved words and sections of the BMM. Depending on this, the implementation strategy of the parser varies. Is the order relevant? We assumed that it is relevant for the header sections, but it is not at the definition of the classes. - Cardinality property of Single attributes. Testing the CIMI BMM we have found several places where a P_BMM_SINGLE_PROPERTY had a cardinality property defined. We interpreted that as an error, since a monovalued attribute has no cardinality. - Is_abstract as string. Also at the CIMI model we found several definitions as is_abstract = True. We interpreted it as an error since it should be a boolean value without double quotes. - Definition of generic properties. They are defined by using the P_BMM_GENERIC_PROPERTY reserved word. What it is not clear is if those properties can be SINGLE or CONTAINER ones. In other words, is it possible to define a container attribute(with its cardinality) of the type GENERIC_PROPERTY? - Generic_parameters property of P_BMM_GENERIC_PROPERTY should be a list. Since a generic class can be defined to support one or more parameters, the generic_parameters used when that class is called should be defined as a list of strings. Currently, all examples define it as a single string value. - Need of visualization information. There are two properties defined related to visualization of the model. The archetype_data_value_parent_class property is defined at the documentation as a base class from the Reference Model whose descendants are considered to be 'logical data types [...] is only used to help tooling provide more intelligent display. The archetype_visualise_descendants_of property is used to designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. In order to repeat some of the problems of existing model representation, such as XMI, we should avoid polluting the pure RM definition from visualization or user-oriented metainformation. At the end that only complicates the BMM format. The representation of that metainformation should not be part of the BMM requirements. We have uploaded the JavaCC specification of the BMM grammar to the openEHR wiki: http://www.openehr.org/wiki/display/dev/BMM+grammar+and+parsers Feel free to use or modify it. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130430/e6d695a4/attachment.html
About openEHR BMM
Hi David, I saw the BMM format mentioned on previous threads, but I really don't know what it is or where it came from. Searching on the web, BMM is almost unknown (there is the OMG Business Motivation Model), so I think the BMM is something developed by Ocean or by CIMI partners (?). Anyone knows where is the spec of the format? It would be nice to understand what BMM in order to participate on these threads. Thanks! -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com From: dam...@gmail.com Date: Tue, 30 Apr 2013 17:33:08 +0200 Subject: About openEHR BMM To: openehr-technical at lists.openehr.org Hello all, We have just implemented the support of Basic Meta Model files (BMM) in LinkEHR Editor as a format to import new reference models into the tool. First of all, I think that it is necessary to clarify some erroneous ideas or misunderstandings about LinkEHR that have been recently published. Until now, LinkEHR used XML Schema as an input format to define reference models. It is analyzed to create the internal information structures needed to edit archetypes based in that model. Internally, LinkEHR follows a pure implementation of the AOM 1.4 model so that the only limits of the tool are what can be expressed as an archetype. The decision to support XML Schema as an input format is based on the fact that many reference models are only or normatively expressed in that way (for example HL7 CDA, HL7 CCD or CDISC ODM). This has nothing to do with the discussion about the expressiveness of the XML Schema language, but just a solution needed to support some daily used and well established models such as CDA. That said, we decided to implement the support of BMM definitions as an additional input format to XML Schema, in order to extend the possibilities of the tool. That implementation took around three days and the only problems came from the interpretation of the BMM format. Some doubts arose and we want to share them for discussion. - Schema identification. This is just a curiosity. The BMM identification includes the following information. It is curious that here the RM release is required as part of the identification schema (which is completely logical), but it is not used for the generation of the archetype identifier or archetype header to make its localization safer, as we have requested some time in the past (http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005943.html). rm_publisher = openehr schema_name = rmrm_release = 1.0.2 - Order of the properties. It is not specified if there is an order of appearance of all reserved words and sections of the BMM. Depending on this, the implementation strategy of the parser varies. Is the order relevant? We assumed that it is relevant for the header sections, but it is not at the definition of the classes. - Cardinality property of Single attributes. Testing the CIMI BMM we have found several places where a P_BMM_SINGLE_PROPERTY had a cardinality property defined. We interpreted that as an error, since a monovalued attribute has no cardinality. - Is_abstract as string. Also at the CIMI model we found several definitions as is_abstract = True. We interpreted it as an error since it should be a boolean value without double quotes. - Definition of generic properties. They are defined by using the P_BMM_GENERIC_PROPERTY reserved word. What it is not clear is if those properties can be SINGLE or CONTAINER ones. In other words, is it possible to define a container attribute(with its cardinality) of the type GENERIC_PROPERTY? - Generic_parameters property of P_BMM_GENERIC_PROPERTY should be a list. Since a generic class can be defined to support one or more parameters, the generic_parameters used when that class is called should be defined as a list of strings. Currently, all examples define it as a single string value. - Need of visualization information. There are two properties defined related to visualization of the model. The archetype_data_value_parent_class property is defined at the documentation as a base class from the Reference Model whose descendants are considered to be 'logical data types [...] is only used to help tooling provide more intelligent display. The archetype_visualise_descendants_of property is used to designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. In order to repeat some of the problems of existing model representation, such as XMI, we should avoid polluting the pure RM definition from visualization or user-oriented metainformation. At the end that only complicates the BMM format. The representation of that metainformation should not be part of the BMM requirements. We have uploaded the JavaCC specification of the BMM grammar to the openEHR wiki: http://www.openehr.org/wiki/display/dev/BMM+grammar+and+parsers Feel free to use or modify
About openEHR BMM
I think Thomas created it from scratch. There is a page on the wiki discussing it (http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR), but we studied mostly to the bmm files included on the archetype workbench in order to understand it. 2013/4/30 pablo pazos pazospablo at hotmail.com: Hi David, I saw the BMM format mentioned on previous threads, but I really don't know what it is or where it came from. Searching on the web, BMM is almost unknown (there is the OMG Business Motivation Model), so I think the BMM is something developed by Ocean or by CIMI partners (?). Anyone knows where is the spec of the format? It would be nice to understand what BMM in order to participate on these threads. Thanks! -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com From: damoca at gmail.com Date: Tue, 30 Apr 2013 17:33:08 +0200 Subject: About openEHR BMM To: openehr-technical at lists.openehr.org Hello all, We have just implemented the support of Basic Meta Model files (BMM) in LinkEHR Editor as a format to import new reference models into the tool. First of all, I think that it is necessary to clarify some erroneous ideas or misunderstandings about LinkEHR that have been recently published. Until now, LinkEHR used XML Schema as an input format to define reference models. It is analyzed to create the internal information structures needed to edit archetypes based in that model. Internally, LinkEHR follows a pure implementation of the AOM 1.4 model so that the only limits of the tool are what can be expressed as an archetype. The decision to support XML Schema as an input format is based on the fact that many reference models are only or normatively expressed in that way (for example HL7 CDA, HL7 CCD or CDISC ODM). This has nothing to do with the discussion about the expressiveness of the XML Schema language, but just a solution needed to support some daily used and well established models such as CDA. That said, we decided to implement the support of BMM definitions as an additional input format to XML Schema, in order to extend the possibilities of the tool. That implementation took around three days and the only problems came from the interpretation of the BMM format. Some doubts arose and we want to share them for discussion. - Schema identification. This is just a curiosity. The BMM identification includes the following information. It is curious that here the RM release is required as part of the identification schema (which is completely logical), but it is not used for the generation of the archetype identifier or archetype header to make its localization safer, as we have requested some time in the past (http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005943.html). rm_publisher = openehr schema_name = rm rm_release = 1.0.2 - Order of the properties. It is not specified if there is an order of appearance of all reserved words and sections of the BMM. Depending on this, the implementation strategy of the parser varies. Is the order relevant? We assumed that it is relevant for the header sections, but it is not at the definition of the classes. - Cardinality property of Single attributes. Testing the CIMI BMM we have found several places where a P_BMM_SINGLE_PROPERTY had a cardinality property defined. We interpreted that as an error, since a monovalued attribute has no cardinality. - Is_abstract as string. Also at the CIMI model we found several definitions as is_abstract = True. We interpreted it as an error since it should be a boolean value without double quotes. - Definition of generic properties. They are defined by using the P_BMM_GENERIC_PROPERTY reserved word. What it is not clear is if those properties can be SINGLE or CONTAINER ones. In other words, is it possible to define a container attribute(with its cardinality) of the type GENERIC_PROPERTY? - Generic_parameters property of P_BMM_GENERIC_PROPERTY should be a list. Since a generic class can be defined to support one or more parameters, the generic_parameters used when that class is called should be defined as a list of strings. Currently, all examples define it as a single string value. - Need of visualization information. There are two properties defined related to visualization of the model. The archetype_data_value_parent_class property is defined at the documentation as a base class from the Reference Model whose descendants are considered to be 'logical data types [...] is only used to help tooling provide more intelligent display. The archetype_visualise_descendants_of property is used to designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. In order to repeat some of the problems of existing model representation, such as XMI, we should avoid polluting the pure RM
About openEHR BMM
On 30/04/2013 16:33, David Moner wrote: Hello all, We have just implemented the support of Basic Meta Model files (BMM) in LinkEHR Editor as a format to import new reference models into the tool. First of all, I think that it is necessary to clarify some erroneous ideas or misunderstandings about LinkEHR that have been recently published. Until now, LinkEHR used XML Schema as an input format to define reference models. It is analyzed to create the internal information structures needed to edit archetypes based in that model. Internally, LinkEHR follows a pure implementation of the AOM 1.4 model so that the only limits of the tool are what can be expressed as an archetype. The decision to support XML Schema as an input format is based on the fact that many reference models are only or normatively expressed in that way (for example HL7 CDA, HL7 CCD or CDISC ODM). This has nothing to do with the discussion about the expressiveness of the XML Schema language, but just a solution needed to support some daily used and well established models such as CDA. That said, we decided to implement the support of BMM definitions as an additional input format to XML Schema, in order to extend the possibilities of the tool. That implementation took around three days and the only problems came from the interpretation of the BMM format. Some doubts arose and we want to share them for discussion. - Schema identification. This is just a curiosity. The BMM identification includes the following information. It is curious that here the RM release is required as part of the identification schema (which is completely logical), but it is not used for the generation of the archetype identifier or archetype header to make its localization safer, as we have requested some time in the past (http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005943.html). rm_publisher = openehr schema_name = rm rm_release = 1.0.2 If we see the multi-axial identifier not as a fixed string, but a computed output from a bunch of identifying meta-data, as per the recent knowledge identification proposal update http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts, then we should consider adding the rm_release to these items. Then it is just a case of defining a function that includes it in one of (possibly many) ids. I didn't think to include it in this draft, but we can do that. I still don't believe it's useful in the primary multi-axial ontological identifier, because there is no certain computational relationship between an archetype and a given release of the RM. Some archetypes will be valid for many releases, others for only one. But having it in the archetype meta-data is a good idea, because that nails down at least the release at which the archetype was created. Then it can be interrogated by some sort of compatibility testing tools. David, can I suggest you add a comment in the feedback table on that page, so I don't forget to do this. you probably should also report a relevant summary of these points on the CIMI list and/or to Michael van der Zel so he can fix his generator. - Order of the properties. It is not specified if there is an order of appearance of all reserved words and sections of the BMM. Depending on this, the implementation strategy of the parser varies. Is the order relevant? We assumed that it is relevant for the header sections, but it is not at the definition of the classes. Good point. My default assumption in these kinds of things is to order the properties in the way we want them. In my software, I consume those structures straight into HashTables, which in Eiffel, remember the chronological input order. I'll have to check if my visual rendering respects this or not... anyway, it seems to me that a BMM specification should say that the order found in the input schema is intended to be significant. - Cardinality property of Single attributes. Testing the CIMI BMM we have found several places where a P_BMM_SINGLE_PROPERTY had a cardinality property defined. We interpreted that as an error, since a monovalued attribute has no cardinality. that's most likely because Michael van der Zel's generator is pulling this info straight off UML structures (or whatever EA's internal representation is) and UML is pretty dumb - it thinks everything has a cardinality. I had not actually noticed this, so it means my tools at least are just ignoring this (I use a parse = DOM-tree = object structure chain, and anything in the DOM-tree that doesn't exist on the object just gets ignored). - Is_abstract as string. Also at the CIMI model we found several definitions as is_abstract = True. We interpreted it as an error since it should be a boolean value without double quotes. Also correct. It looks like my BMM schema mini-compiler isn't checking that properly.
About openEHR BMM
On 30/04/2013 18:30, Diego Bosc? wrote: I think Thomas created it from scratch. There is a page on the wiki discussing it (http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR), but we studied mostly to the bmm files included on the archetype workbench in order to understand it. yep. That link explains why I did it. Simple summary: XMI is a horror and hardly works between tools that implement it (and there is no hope of hand-writing an XMI schema). And Ecore was broken for generic types. We might converge to some Ecore/EMF format at some point, but right now, BMM is a nice lightweight format, and works ok. Michael van der Zel at Results4Care put together a great little plug-in for Enterprise Architect that traverses a UML model in memory and pumps out a BMM schema for it. So now we have a nice way of having a primary UML model expression and a generated tool-consumable format (BMM schemas), which will help tool chains components to communicate - right now the ADL workbench and now LinkEHR can consume it. The converter is pretty good right now, but David Moner's group has obviously found a few more bugs than I found, which is good - hopefully we can converge on a very tight version of the EA converter soon. Then the same thing can be done with openEHR, 13606, any other model in EA, which means we have a way of representing a RM in UML, and driving archetype tools from that. I'm just putting together a GitHub repo now for it on which I'll post a spec, the class models I use (in UML) and pointers to every implementation we can find. - thomas
