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.
>>
>> 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.
>>
>>
>> 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.
>
> 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.
> 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.
- thomas
