Hi Pablo,
in openEHR, a terminology id of 'local' normally refers to terms inside
an archetype; each archetype is its own terminology. This makes sense
for clinical terms in an archetype, but not, I don't think, for terms to
do with data formats. We can easily add these to the openEHR vocabulary,
then that provides a reliable single source of such terms, and doesn't
require archetype authors to re-invent (different) terms for the same
thing repeatedly.
- thomas
On 29/07/2015 01:04, pablo pazos wrote:
I think we can put the formalisms we know in the terminology, but
being flexible to allow local formalisms, like using "local" for the
terminology_id. If we don't do that, we'll need to maintain the
terminology for every new formalism.
Not sure about having two fields, it seems the role of both is the
same. We can do that with parameters or suffixes on MIME types (the
structure allows that): https://en.wikipedia.org/wiki/Internet_media_type
With CODE_PHRASE we can cover both cases, defined and non-defined MIME
types.
If the MIME type is String, we lose control over the values, I'm
considering trying to process something I receive and not
"understanding" that String. With terminology = local, I know that I
may not have the code (if "local" is another system), but for a MIME
type from IANA I will have it. Also this allow us to define our own
openEHR types without the need of registering those at IANA, like ADL
or OPT (e.g. text/opt+xml).
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
