2013/4/25 Thomas Beale <thomas.beale at oceaninformatics.com>:
> On 25/04/2013 11:47, Diego Bosc? wrote:
>
> As you know, I'm not a big fan of domain types, so take my comments
> with a grain of salt ;)
> I understand that back in the day when archetypes were hand crafted
> domain types could serve a purpose. But in my opinion ADL should not
> be written by hand nowadays. Tools should be the ones that 'hide' the
> 'verboseness' and provide the user with a simple interface to simulate
> domain types if you want/need that. Also, the difference in file size
> is negligible (if archetypes pass from 16kb to 20kb I wouldn't worry
> that much...).
> If you ask me I would get rid of them completely and make ADL
> completely model agnostic.
>
>
> I'm not worried about size, up to a point. But there some truisms about
> formalisms - the main one is that if the context free grammar of a formalism
> only has a complicated way to do something, then any structural
> representation will also be complicated. Additionally, if it's complicated
> to express a simple thing in the formalism, it's probable that no users or
> developers understand it clearly.
>
> Consider these dichotomies:
>
> OWL (readable) v RDF (hideous)
> JSON (simplistic, but readable) v XML (hard to read, tricky inheritance
> model, tricky containment semantics, ...)
> Ruby / Python (readable, according the young generation at least ;-) v C++
> (much harder than it should be)
> Ecore syntax (human readable and computable) v XMI (no need to say anything
> here).
>
> One thing we can learn from this is that where clear abstract syntaxes are
> not found, there you find confusion.
>
"readability" seems like a too subjective measure, and depends mostly
of the person/program writing it on the first place.
>
>
> This is why I can agree with the second point completely: There you
> are making ADL better, more powerful.
> But I see a problem with the first point as it still requires an
> external definition of the 'mappings' between how we understand codes
> in each one of the standards (and which information we can constraint
> about them).
>
>
> well that's true, but it's already true for types like Date, Time, DateTime
> and Duration. Note that a Datetime with timezone has 7 pieces of
> information in it, and a lot of implied validity rules. Is it a leaf type or
> a complex type? We just use ISO8601 strings for all of these, and let other
> tools work out the obvious mappings between various RMs with TS (HL7),
> DATE/TIME types (openEHR), XSD gXXX types (FHIR), and so on.
>
Dates are mostly represented as strings with more or less
restrictions. The classes to represent the codes are more complicated
than that (codes, terminology, mapping(s), qualifiers, etc)
> Proposing the idea of a 'terminology code' made up of a terminology id and a
> code or code-phrase (as a string expressed in e.g. the SNOMED CT
> Compositional grammar) as a built-in type doesn't seem a great leap in the
> semantic age.
>
>
> With this new syntax, can we constraint mappings between
> codes? ( How do I say that I don't want to allow the mappings in
> certain coded text?)
>
>
> I'm not exactly sure what constraint you want to express here: can you be
> more precise?
>
Have a template or specialized archetype that the codes in my target
system will have exactly one mapping (from a standard terminology to a
local one, for example)
>
> and what about the code qualifiers? What if your
> RM defines another kind of attribute for codes interesting to be put
> into the archetypes but not supported by this code syntax?
> If both visions (codes as a type and codes as a full structure)
> coexist then we have the same problem as we have now (or worse).
>
>
> well in openEHR we have always modelled code terms as syntax, not a complex
> model of qualifiers. See the CODE_PHRASE type.
>
>
I know how openEHR does it, but others may or may not model it like that.
>
>
> PS: BTW, by definition a leaf constraint type (the new proposed
> 'C_TERMINOLOGY_CODE' or whatever) does not have node id, I don't see
> how one would be able to define alternatives of codes from different
> terminologies or specialize that...
> PPS: ...which is the exact same problem that domain types have (as
> they also lack node id)
>
>
> it depends on what are trying to do. The 'normal' thing that 90% of
> archetypes need to do is this:
>
> ELEMENT[at0021] occurrences matches {0..1}
> matches { -- Certainty
> value matches {
> DV_CODED_TEXT matches {
> defining_code matches {
> [local::
> at0022, -- Suspected
> at0023, -- Probable
> at0024] -- Confirmed
> }
> }
> }
> }
>
> If this is written without the 'custom syntax' then you have:
>
> ELEMENT[at0021] occurrences matches {0..1}
> matches { -- Certainty
> value matches {
> DV_CODED_TEXT matches {
> defining_code matches {
> CODE_PHRASE matches {
> terminology matches {
> TERMINOLOGY_ID matches {
> value matches
> {"local"}
> }
> code_string matches {
> "at0022", --
> Suspected
> "at0023", --
> Probable
> "at0024" -- Confirmed
> }
> }
> }
> }
> }
> }
>
> Either way, there is no at-codes on the possibilities, and there's no need.
>
> Of course, you can always do this:
>
> ELEMENT[at0021] occurrences matches {0..1}
> matches { -- Certainty
> value matches {
> DV_CODED_TEXT [atNNNN] matches {
> defining_code matches {
> ...
> }
> }
> DV_CODED_TEXT [atNNNN] matches {
> defining_code matches {
> ...
> }
> }
> }
> }
>
> which might possibly make sense in some situation.
>
> - thomas
>
>
Sure, you can make alternatives of coded_text, the domain type here is
the codePhrase...
I think this could be a perfect valid example (ignore random codes)
defining_code existence matches {1..1} matches {
[SNOMED-CT::
123456,
11234561,
1002123456,
61234563,
98752;
233233]
[LOINC::
72693-5,
1234-5,
3254-8,
6548-1,
44563-7;
3254-8]
[local::
at1000,
at1001,
at1002,
at1003,
at1014;
at1001]
}
You cannot define a node id for each defining code. But specializing
it should be allowed (define a subset of the parent seems like an
obvious thing to do on codephrases)
The same thing applies to C_DV_QUANTITY for example
ELEMENT[at1005] occurrences matches {0..1} matches { -- Tilt
(degrees and radian)
value existence matches {1..1}
matches {
C_DV_QUANTITY <
property = <[openehr::497]>
list = <
["1"] = <
units = <"?">
magnitude =
<|-90.0..90.0|>
precision = <|0|>
>
>
>
C_DV_QUANTITY <
property = <[openehr::497]>
list = <
["1"] = <
units = <"c">
magnitude =
<|-2PI..2PI|>
precision = <|0|>
>
>
>
}
}
C_DV_QUANTITY[atXXXX]<...> is not correct.
And looking at the example, after all this years I have yet to find a
good explanation of why domain types can have things like "property"
which cannot be defined in standard ADL
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
