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 > 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) > > _______________________________________________ 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
