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 > 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. > > 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>
