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.
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.
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 , 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. 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. 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). Also correct. It looks like my BMM schema mini-compiler isn’t checking that properly. this is the way to define a container property. Obviously containers are always ‘generic’ types, but I created the BMM_CONTAINER_PROPERTY type to make it more obvious that it was a container, so as you can see below, there is a ‘container_type’ property and a ‘type’ property, which makes it easy to know where to put your ‘List’ and where to put your ‘THING’ for a type List. [“CLUSTER”] = < name = <“CLUSTER”> ancestors = <“ITEM”, …> properties = < [“items”] = (P_BMM_CONTAINER_PROPERTY) < name = <“items”> type_def = < container_type = <“List”> type = <“ITEM”> > cardinality = <|>=1|> is_mandatory = > > > indeed. I haven’t implemented nested or multi-parameter generic types yet because none of the RMs we enocunter have them. To do it properly, it’s not just a list of Strings, but a ‘type list’, i.e. allows things like: HashTable <SortedList <Dictionary <Thing, Integer>>, String> This is a fair bit of work in the main BMM library, and won’t buy us anything right now for CIMI, 13606, openEHR, etc. 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. - thomas
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.
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 , which was free and is now a pay-for tool (about €50). 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 . 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.
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, which was free and is now a pay-for tool (about €50). 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.
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.
...
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
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! 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. 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. 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 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: you can generate any BMM file in XML by choosing the last item on the context menu of any compiled schema in the ADL workbench. There is no schema yet for that, but I’ll be very happy to include one if someone wants to write it depends on what exactly you are doing at the moment. I generally pull them into the ADL Workbench and edit them by hand (gvim syntax highlight mode) from a context menu option, and recompile to debug. I am working on visual editing, but it’s not done yet.
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.
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.
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?
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. maybe ‘tool preferences’ is the way to go.. 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
