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>
