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. > > - 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? 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<THING>. ["CLUSTER"] = < name = <"CLUSTER"> ancestors = <"ITEM", ...> properties = < ["items"] = (P_BMM_CONTAINER_PROPERTY) < name = <"items"> type_def = < container_type = <"List"> type = <"ITEM"> > cardinality = <|>=1|> is_mandatory = <True> > > > > > - 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. 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. > > - 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. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130430/84f7bb9e/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: jhjbddch.png Type: image/png Size: 90860 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130430/84f7bb9e/attachment-0001.png>
