2013/4/25 Thomas Beale <thomas.beale at oceaninformatics.com>:
> On 25/04/2013 18:44, Diego Bosc? wrote:
>>
>> 2013/4/25 Thomas Beale <thomas.beale at oceaninformatics.com>:
>>
>>> 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.
>
>
> Nevertheless, the unreadable examples from the list above are all infamous
> for their difficulty of learning, difficulty of understanding, complexity,
> and for being things everyone wants to (and eventually does) replace. It's
> not by accident that this happens.
>
>
I disagree, everything has a place in this world. You would not be
programing in eiffel it that wasn't the case ;D
>>>
>>> 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)
>
>
> only if you think it has to be a class model. But in fact, 99% of all codes
> on the planet are just single codes. A small number have some qualifiers /
> modifiers, and the standard way to do this in both the ontology and
> terminology communities is with different kinds of syntax - either OWL-based
> or IHTSDO based. CLass models always fail in this area, because they can
> never predict what new things terminology code phrases need to be able to
> represent.
>
> I am not saying that you could not keep using the explicit CODED_TERM
> model-based approach as well, just that it's getting in the way 99% of the
> time.
>
>
If getting in the way means write 5 lines instead of 1 then I give you that.
I don't really see which is the big gain of this
CODED_TEXT matches {[local: at0111, at0012, at0013, at0014, at0015]}
over making it completely generic and leaving headaches behind with this
CODED_TEXT matches {
terminology_id matches {
TERMINOLOGY_ID matches {
value matches {"local"}
}
}
code matches {"at0111", "at0012", "at0013", "at0014", "at0015"}
}
>>>
>>>
>>> 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)
>
>
> well the normal way to do that is with terminology bindings. The following
> example would be a pretty dangerous thing to do, especially in health, and
> in any case, it would be hard to find any real world example that could look
> like this, because LOINC and SNOMED-CT don't really overlap or code for the
> same things at all. The better way to do that is definitely with bindings.
>
>
Was a quick example, if you one a little more real take SNOMED and
RxNorm for example. Something like "valid medications for a given
disease".
I don't really think that the requirement could be done with bindings
by the way. If I have in my an object that supports codes with
mappings then archetyping that to require one and only one mapping is
trivial in ADL.
>>
>> 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.
>
>
> actually, you can set at-codes on the DV_QUANTITY blocks above, but it's
> kind of ugly. But the proposals I am suggesting make all this go away.
>
I'm curious how. codePhrase can also have a node id? Some domain types
can and others can't?
>
>> 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
>
>
> it's very simple: with a plug-in constrainer type, you can have all kinds of
> special constraining attributes that are not in the RM at all. E.g. here
> 'property' is not actually a property of DV_QUANTITY (arguably it should be
> but that's another argument).
>
> Similar thing happens with things like C_STRING - there is the regex and the
> list way of constraining a String value. There is nothing called 'pattern'
> in the String type.
>
Well, doesn't feel the same way. I would use a binding to a local
openEHR terminology to represent 'property' instead of putting that on
a attribute.
> - thomas
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
