On 16-02-19 13:16, Thomas Beale wrote:
Bert,

if you serialise a AOM archetype to any object dump format, you need typing information for the simple reason that there is polymorphism in the model, mainly places where the static type is C_OBJECT, C_DEFINED_OBJECT or C_PRIMITIVE_OBJECT but the attached type in a real archetype can be a number of descendant types.

W.r.t. the naming convention of RM types, attributes etc, I assume you are referring to the fact that openEHR archetypes use the published RM type and attribute name format, which is so-called 'snake-case' rather than 'camelCase'. To make archetypes that refer to data objects usable across software written in different languages using different case conventions, it may make sense to add an option to OPT generation which indicates the flavour of RM casing. I had not thought of this before but it would be easy to implement in an OPT generator.

BMM is getting more powerful by the way. I have recently extended it so that it allows types to be annotated with a 'value-set' identifier, which can be used to limit the values of e.g. data fields of type CodePhrase or TerminologyCode to particular terminologies. \


I understand that you need type information to make an archetype understandable for humans, but you don't need it for validating datasets, because in validating only the in the archetype defined properties/constraints are important and the JSON or XML datasets also do not have type-information. The constraint in the leaf-node indicates which type the leaf-node is of. So type-information is unnecessary load in the validation-part (definition) of an archetype.

Here you see a JSON and an XML having the same information. No explicit type information is in it.

{
    "glossary": {
        "title": "example glossary",
                "GlossDiv": {
            "title": "S",
                        "GlossList": {
                "GlossEntry": {
                    "ID": "SGML",
                                        "SortAs": "SGML",
                                        "GlossTerm": "Standard Generalized Markup 
Language",
                                        "Acronym": "SGML",
                                        "Abbrev": "ISO 8879:1986",
                                        "GlossDef": {
                        "para": "A meta-markup language, used to create markup 
languages such as DocBook.",
                                                "GlossSeeAlso": ["GML", "XML"]
                    },
                                        "GlossSee": "markup"
                }
            }
        }
    }
}
<!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
 <glossary><title>example glossary</title>
  <GlossDiv><title>S</title>
   <GlossList>
    <GlossEntry ID="SGML" SortAs="SGML">
     <GlossTerm>Standard Generalized Markup Language</GlossTerm>
     <Acronym>SGML</Acronym>
     <Abbrev>ISO 8879:1986</Abbrev>
     <GlossDef>
      <para>A meta-markup language, used to create markup
languages such as DocBook.</para>
      <GlossSeeAlso OtherTerm="GML">
      <GlossSeeAlso OtherTerm="XML">
     </GlossDef>
     <GlossSee OtherTerm="markup">
    </GlossEntry>
   </GlossList>
  </GlossDiv>
 </glossary>

But for humans, it must be available to understand an archetype, that is the semantic part, and must be taken care of. For that problem are several solutions. There can be a documentation-file, separate, or included, another solution is that the ontology can be extended with "type", next to "text" and "description", and maybe more ontology items. I think I favor an ontology-based solution.

Important for the JSON solution to work is that the JSON must not reflect beyond the extend of the classes, there may not be something in the JSON, which is not in the classes, because in that case, you might lose the advantages which are in JSON when flattening or creating templates, which can be done just by filling up AOM-object properties with objects from other archetypes and then serialize again for validation purpose.

I have not thought all through, but I think that there will be very many advantages in handling AOM objects/JSON instead of fiddling around with paths and finding ways to find the type of a path-node.

Regarding the naming conventions is always discussion. In ISO13606 properties have two different name-conventions for properties, snake-case and camelCase, and that in one standard, even in one class. In DATA_VALUE there is "nullFlavor" and in URI which descents from DATA_VALUE, there is "fragment_id". But then again, it is up to the reference-model designer. Some property-names came from HL7 and the desire to be in line with HL7 regarding properties with the same name made them keeping the same property-name-convention.

So the tooling and definition for reference-model-design must be agnostic to this.

Regarding your third line, I don know if I understand well, but for me it is best when BMM is domain-neutral, and bringing in terminology-information could harm this idea, except for when it is made completely voluntary to use. But I don't know why it should be there, and I don't see it as powerful. Sometimes, less is more.

Bert


_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to