Stream: ontology
Topic: SNOMED Expressions
Grahame Grieve (May 09 2017 at 15:38):
take this example from STU3 (http://build.fhir.org/observation-example-bmd.ttl.html)
fhir:Observation.bodySite [
fhir:CodeableConcept.coding [
fhir:index 0;
a sct:71341001%3a272741003%3d7771000;
fhir:Coding.system [ fhir:value "http://snomed.info/sct" ];
fhir:Coding.code [ fhir:value "71341001:272741003=7771000" ]
];
fhir:CodeableConcept.text [ fhir:value "Left Femur" ]
] .
Grahame Grieve (May 09 2017 at 15:38):
the sct:link is garbage. What is the right representation @Harold Solbrig @Eric Prud'hommeaux @David Booth
Harold Solbrig (May 09 2017 at 15:56):
Two answers, depending on context. The one we need for classification is a conversion into OWL:
a sct:71341001,
rdfs:subClassOf [a owl:Restriction;
owl:onProperty sct:272741002;
owl:someValuesFrom sct:7771000];
The second is that there actually is a proposed SNOMED URL for this as well:
http://snomed.info/scg/71341001%3a272741003%3d7771000
Not sure how useful this second form is...
Grahame Grieve (May 09 2017 at 16:01):
the first form is the useful one. Really. What use would the URL be? it's a concept reference, not a secret URL with semantics buried inside it
Grahame Grieve (May 09 2017 at 16:01):
I mean, that's what we want: a concept reference.
Grahame Grieve (May 09 2017 at 16:01):
but if I'm going to fix that, I'll be doing the general case.... so what would an expression like this become?
Grahame Grieve (May 09 2017 at 16:03):
say:
128045006|cellulitis (disorder)|:{363698007|finding site|=56459004|foot structure|}
Grahame Grieve (May 09 2017 at 16:03):
or
64572001|disease|:{116676008|associated morphology|=72704001|fracture|,363698007|finding site|=(12611008|bone structure of tibia|:272741003|laterality|=7771000|left|)}
Harold Solbrig (May 09 2017 at 22:54):
a sct:128045006,
rdfs:subClassOf [
a owl:Restriction;
owl:onProperty sct:609096000 ;
owl:someValuesFrom [
a owl:Restriction;
owl:onProperty sct:363698007 ;
owl:someValuesFrom sct:56459004 ] ] ;
and
a sct:64572001,
rdfs:subclassOf [
a owl:Restriction ;
owl:onProperty sct:60909600 ;
owl:someValuesFrom [
a owl:Class ;
owl:intersectionOf ( [
a owl:Restriction;
owl:onProperty sct:116676008;
owl:someValuesFrom sct:72704001 ]
[ a owl:Restriction;
owl:onProperty sct:363698007
owl:someValuesFrom [
a owl:Class ;
owl:intersectionOf(
sct:12611008
owl:someValuesFrom [
a owl:Restriction;
owl:onProperty sct:272741003;
owl:someValuesFrom sct:7771000
] ) ] ] ) ] ]
(an approximation -- I'll have to feed it into a translator to be sure I've got it 100% right)
Michael van der Zel (May 10 2017 at 22:02):
But if we decide on the verbose version it means I have to also add a sct compositional grammar parser and writer to a FHIR RDF implementation. So I would hope for the simple url form.
Grahame Grieve (May 11 2017 at 06:18):
but that makes the expression - which is important content - opaque to any processor. So I think that we should have the verbose version. sorry
Grahame Grieve (May 11 2017 at 06:20):
I'll write you a C# snomed compositional parser if you want - I have it in both pascal and java, so that's only a short thing to do
Peter Jordan (May 11 2017 at 10:18):
I'd also be interested in that parser, or the Java code that should, as you say, be easy to transpose to C#.
Grahame Grieve (May 11 2017 at 10:20):
looks like I only have it in pascal:
Grahame Grieve (May 11 2017 at 10:20):
https://github.com/grahamegrieve/fhirserver/blob/master/Libraries/snomed/SnomedExpressions.pas
Michael van der Zel (May 11 2017 at 22:32):
It would make sense to use the parser infrastructure that is in the .Net FHIR API. It probably also has something for FHIRPath. Maybe I can even use that to parse the turtle. Is @Ewout Kramer listening in on this chat?
Michael Lawley (May 12 2017 at 02:37):
@Harold Solbrig I'm not an OWL:RDF expert, but those rdfs:subClassOf bits don't feel right -- the postcordinated expression is an anonymous class equivalent to the intersection of the focus concept and each of the refinements. I would expect something like:
a owl:Class ;
owl:intersectionOf(
sct:128045006
rdfs:subClassOf [
a owl:Restriction;
owl:onProperty sct:609096000 ;
owl:someValuesFrom [
a owl:Restriction;
owl:onProperty sct:363698007 ;
owl:someValuesFrom sct:56459004 ] ]
)
Michael Lawley (May 12 2017 at 02:45):
Note also that any converter from post coordination syntax to a description logic form needs to apply the appropriate rules to add in implicit role grouping (ie implicit nesting inside the property sct:609096000), as well as applying the rules for laterality -- that is, refining a Finding, Procedure, or Situation that contains (lateralisable) body stuctures means that the refinement acutally applies to (all) the body structures.
46866001|fracture of lower limb| : 272741003 |laterality| = 7771000 |left|
is equivalent to (transformed to)
46866001 |fracture of lower limb| : {363698007 |finding site| = (72001000 |Bone structure of lower limb| : 272741003 |laterality| = 7771000 |left| ) }
Grahame Grieve (May 12 2017 at 04:54):
why is this necessary? the implication is that the only way to convert from a post-coordinated expression to a valid RDF equivalent requires deep knowledge of the relationships in snomed.
Grahame Grieve (May 12 2017 at 04:55):
if you can infer it from the short form, based on the triples, then a reasoner should be able to do it. If you can't, then the short form shouldn't be legitimate; I don't see why you have to say more than the expression says
Grahame Grieve (May 12 2017 at 05:00):
@Michael van der Zel see also these 2 java classes: http://gforge.hl7.org/svn/fhir/trunk/build/implementations/java/org.hl7.fhir.r4/src/org/hl7/fhir/r4/utils/SnomedExpressions.java and http://gforge.hl7.org/svn/fhir/trunk/build/implementations/java/org.hl7.fhir.r4/src/org/hl7/fhir/r4/test/SnomedExpressionsTests.java
David Booth (May 12 2017 at 11:36):
While the long form that Harold suggests certainly seems the most useful for inference purposes, I'm not sure that it should be directly a part of the FHIR/Turtle. I've added this to our weekly teleconference agenda to discuss.
Harold Solbrig (May 12 2017 at 14:17):
a sct:128045006,
rdfs:subclassOf [
a owl:Restriction ;
owl:onProperty sct:60909600 ;
owl:someValuesFrom [
a owl:Restriction ;
owl:onProperty sct:363698007 ;
owl:someValuesFrom sct:56456004
] ] .
Harold Solbrig (May 12 2017 at 14:28):
Michael - in this context, we are using individuals (see https://github.com/BD2KOnFHIR/BLENDINGFHIRandRDF) - in this context, x a sct:12345, sct:67890 . should be equivalent to x a [owl:intersectionOf (sct:12345 sct:67890)] - no?
Grahame Grieve (May 12 2017 at 16:07):
@David Booth I agree that it's not of obvious benefit, but the URL form is not valid (afaik) and so I think there's not much choice here
Michael Lawley (May 16 2017 at 11:40):
@Harold Solbrig okay, clearly I have no idea about this syntax (liekly) and/or I am missing some motivating context here (regarding individuals) - I was assuming that the goal was to render snomed expressions in their corresponding DL (OWL) form an then serialise to RDF. This makes sense to me because they can then be directly used with the DL (OWL) representation of SNOMED in a reasoner.
@Grahame Grieve yes - the only was to get to a DL representation of a post coordinated expression is with deep knowledge of how SNOMED works. Yes, this should be the business of a Terminology Server and not code that only needs to serialise FHIR in one of several syntaxes. Hence it seems to me that trying to render SNOMED expressions semantically in the FHIR RDF serialisation is a mistake and also not particularly useful (it makes the serialiser's job hard and doesn't really help anyone else).
Grahame Grieve (May 17 2017 at 05:51):
well, let's be clear here - the property we are describing is not part of the mandatory FHIR RDF, but an optional extra to allow OWL processors to process the content more efficiently. We generally expect it to be added as a post-processing step. I am adding it to my RDF in the serialization step as a convenience to users - to drive discussions like this
Michael Lawley (May 17 2017 at 09:22):
Ok, then if it is to be consumed directly by OWL processors (presumable for reasoning about subsumption in SNOMED), then it needs to be a proper DL rendering which requires the extra knowledge of how SNOMED works -- it has to come into the usage chain somewhere!
Michael Lawley (May 17 2017 at 09:24):
I'm also concerned that if it looks OWL-like but hasn't had the SNOMED-specific transformations applied, then naive (of SNOMED) users (the majority) will see something that looks like it can be just thrown into a DL reasoner and get bad (incorrect, unsafe) results. The easy path should also be the path that leads to correctness
Grahame Grieve (May 17 2017 at 10:37):
"The easy path should also be the path that leads to correctness" - there's a certain amount of irony when you say that anywhere in the snomed CT space. But I agree with the point - this property should be right
Michael Lawley (May 17 2017 at 13:13):
I think we can agree that the "certain amount" is in fact extremely large.
Last updated: Apr 12 2022 at 19:14 UTC
