Hi All,
While attempting to implement the ArchetypeOntology I have ran into some
confusion.
The attributes term_codes and constraint_codes are documented as being a
List of strings.
However, it seems to me that they should be a List of ArchetypeTerms. So
that the code is associated with the Hash (or Tuple) of the
text/description etc.
how is everyone else implementing this?
--Tim
Hi Tim,
term_codes and constraint_codes are really just codes not ArchetypeTerms as indicated by the AOM specification. But you do need other attributes to keep the mapping between different language, codes and ArchetypeTerms in order to implement the methods.
In the Java implementation, a nested Map (Hash in Java) is used to keep all the mappings. The key of the outer map is language and the key for inner map is the code.
Cheers,
Rong
Hi Tim,
search for term_definitions - see the HASH_TABLEs about 2/3 of the way down.
- thomas
Tim Cook wrote:
Hi Tim,
This is also how the AOM XML schema is represented.
My understanding is that ArchetypeOntology is a functional class (like the EHR and VERSIONED_OBJECT classes) rather than a data object class, hence it does not necessarily directly reflect the data model and its serialisation.
Heath
Hi Heath (& Rong),
My perspective is that the ArchetypeOntology class is very much
functional and as such is a data class.
Certainly others, especially Ocean Informatics, has more experience in
implementation than I have. That is the reason for my question.
But I still contend that there is confusion between the class
definitions and the text. Please review 7.2 of the AOM and then 7.3.x
The text states: "Local term and constraint definitions are modelled as
instances of the class ARCHETYPE_TERM"...
Whereas the class definitions (section 7.3) clearly define these
attributes as Lists of strings.
So, my original question is; how did you implement these attributes of
the ontology?
--Tim
Tim,
We have generated a set of data classes from the openEHR Archetype.xsd. We
have not implemented (in c#) a functional class (what I mean by functional
is that the class has behaviour rather than data attributes only)
representing the ARCHETYPE_ONTOLOGY class as yet. We currently work with
the ARCHETYPE_ONTOLOGY data class generated from the schema directly without
the functions specified in the spec.
So your problem is the ambiguity of the specification?
Your trying to determine whether to implement the UML or the text?
Personally I have gone with the UML in these cases, mainly because I read
UML better than English (even though I only speak English) but also knowing
Tom, he usually keeps the models more up to date than the text.
Heath
From: openehr-implementers-bounces@openehr.org
[mailto:openehr-implementers-
In the next version of ADL, I think we will probably put the hash tables of terms in as data items, since Rong also asked for this a while ago, and I don’t see any major reason not to do it.
The specification could be as follows - this is what we use in the reference implementation in Eiffel; I presume you can use nested Hash tables in the other languages? If not we can of course work to find a commonly acceptable representation, or else an agreed ITS mapping for each language.
term_definitions: HASH_TABLE[HASH_TABLE[ARCHETYPE_TERM, STRING], STRING]
-- table of term definitions, keyed by code, keyed by language
constraint_definitions: HASH_TABLE[HASH_TABLE[ARCHETYPE_TERM, STRING], STRING]
-- table of constraint definitions, keyed by code, keyed by language
term_bindings: HASH_TABLE[HASH_TABLE[CODE_PHRASE, STRING], STRING]
-- tables of bindings of external terms to internal codes, keyed by external terminology id
constraint_bindings: HASH_TABLE[HASH_TABLE[URI, STRING], STRING]
-- table of constraint bindings in the form of strings "service::query", keyed by terminology
Heath Frankel wrote:
Thanks, Thomas!
This is almost exactly how it is done in the Java implementation. Such nested Hash_table structure is well supported in Java. Only that in the Java syntax, the key of the Hash_table goes before the value, e.g. Map<String, Map<String, ArchetypeTerm>> termDefinitionMap.
Cheers,
Rong
Hi Thomas,
Thanks for this. It is very close to how I was envisioning the Python
implementation. But thinking more about this I wonder if implementation
would be more generic if we added a language attribute to
ARCHETYPE_TERM
language <CODE_PHRASE>
and then ARCHETYPE_ONTOLOGY would look like:
term_definitions: LIST<ARCHETYPE_TERM>
constraint_definitions: LIST<ARCHETYPE_TERM>
The HASH_TABLE (dictionary) approach is MUCH faster in Python so I would
definitely be happy with that. Though I think that with the current
format of the ADL it is better to create structures (easier parsing)
that are keyed by language and then a nested structure keyed by
at_code/ac_code.
Feedback from other implementers and end users (application developers)
will be helpful in doing this 'the right way'.
I created a CR on this issue (not having found one from Rong). Maybe I
need to delete or expand it?
--Tim