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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
