Stream: ontology
Topic: RDF Paths for Element References
Harold Solbrig (Sep 11 2017 at 19:24):
@Grahame Grieve - I'm building a FHIR to RDF conversion for Python use and encountered a a disparity in interpretations. Taking the valueset resource as an example, the "exclude" element references (has the same definition as) the "include" element. The question is whether we use "include" or "exclude" in the inner path names. My interpretation shows an exclude as:
fhir:ValueSet.compose [
fhir:ValueSet.compose.exclude [
fhir:index "0"^^xsd:integer ;
fhir:ValueSet.compose.exclude.concept [
fhir:index "0"^^xsd:integer ;
fhir:ValueSet.compose.exclude.concept.code [
fhir:value "5932-9"
] ;
while the FHIR rendering has "exclude" in the outermost tag, but then reverts to "include" in the inner tags:
fhir:ValueSet.compose [
fhir:ValueSet.compose.exclude [
fhir:index 0;
fhir:ValueSet.compose.include.system [ fhir:value "http://loinc.org" ];
fhir:ValueSet.compose.include.concept [
fhir:index 0;
fhir:ValueSet.compose.include.concept.code [ fhir:value "5932-9" ];
Before I try to fix my utility, I wanted to double check that you are certain that the FHIR rendering is what was intended.
Grahame Grieve (Sep 11 2017 at 19:26):
the fhir rendering is what is intended - the element is only defined once, and then erused
Grahame Grieve (Sep 11 2017 at 19:26):
reused
Harold Solbrig (Sep 11 2017 at 19:33):
But that rule applies in both situations, as it is just a question whether the outermost label "include" or "exclude" persists through the definition or reverts. Another example would be in testscript -- where a "setup.action" is contained in a test.action.operation by the FHIR interpretation:
fhir:TestScript.test.action.operation [
fhir:TestScript.setup.action.operation.type [
fhir:Coding.system [ fhir:value "http://hl7.org/fhir/testscript-operation-codes" ];
fhir:Coding.code [ fhir:value "update" ]
];
fhir:TestScript.setup.action.operation.resource [ fhir:value "Patient" ];
It seems a bit confusing to me, but if this is what you think it should be...
Harold Solbrig (Sep 11 2017 at 19:34):
I would think it would still be a test.action.operation, even if it reuses the setup model
Grahame Grieve (Sep 11 2017 at 21:13):
both which situations?
Harold Solbrig (Sep 11 2017 at 22:21):
"The element is only defined once and then reused..." -- it can be reused whether it is compose.exclude throughout or exclude in the outermost and include within -- this is going to confuse the dickens out of folks
Grahame Grieve (Sep 11 2017 at 23:08):
if you say that it has to be .exclude, then you have to track the alternative names into the tree below it
Grahame Grieve (Sep 11 2017 at 23:09):
that's the sort of thing that sounds less confusing but it more confusing structurally. And I thought that would matter more for RDF
Harold Solbrig (Sep 12 2017 at 14:34):
We'll bring it up in the next HCLS RDF meeting to make sure that everyone understands the issues, but I suspect we'd like to change it.
Grahame Grieve (Sep 12 2017 at 15:23):
At the meeting here? I'm very opposed to changing it. It would mean that all my serialisers would have to remember state. I can't see how this is practical for anyone else either
Harold Solbrig (Sep 12 2017 at 15:26):
No - the meeting isn't occurring there. It would be later. This should only impact the RDF serializer but, if you feel strongly about it, we've got some extra work to do on our side and will need to be able to explain why we've got an "include" in the interior of the "exclude" node and why it isn't parallel with xpath or json path expressions
Grahame Grieve (Sep 12 2017 at 15:32):
Well, that's inherent in the content model. The serialiser should not try to backpatch it
Harold Solbrig (Sep 12 2017 at 15:41):
Not sure I understand. The xpath for an excluded concept is something like "ValueSet.compose.exclude.concept". Why should it be ValueSet.compose.exclude Valueset.compose.include.concept in RDF? And why should the identity depend on which was defined first. You could have just as easily defined "exclude" and then said "include" --> see "exclude".
Harold Solbrig (Sep 12 2017 at 15:42):
That said, again, if you feel strongly about it, we can figure out how to deal with and explain it. Not worth a major battle.
Grahame Grieve (Sep 12 2017 at 15:57):
identity depends on what the definition says. It's true that definitions must be backwards only but that's for convenience.
Grahame Grieve (Sep 12 2017 at 15:58):
but the key thing here is that the RDF identifer is the element identifier, not the path identifier
Grahame Grieve (Sep 12 2017 at 15:58):
this also applies to recursive elements like ValueSet.expansion.contains.contains
Harold Solbrig (Sep 12 2017 at 16:18):
The only place where this is an issue is the relatively few items where the reference is (arguably) structural rather than semantic. Recursive definitions are fine, as the semantics should be the same. It is just the couple of places where, in one context "Valueset.compose.include.concept" identifies a concept to be included and, in another, the exact same tag identifies a concept to be excluded. At the moment, these all appear to be in structural elements so they won't impact how we represent clinical data. Again, if you feel strongly about it, I'll change the code on our end and add an explanation that sometimes "include.concept" is included and sometimes it is excluded.
Grahame Grieve (Sep 12 2017 at 16:29):
yeah well, the naming is not an optimum outcome, that's for sure.
Grahame Grieve (Sep 12 2017 at 16:29):
but the problem is in the definitions, not the streaming
Grahame Grieve (Sep 12 2017 at 16:31):
talking about it in ITS now
Grahame Grieve (Sep 12 2017 at 16:48):
possible resolution... I will describe later
Harold Solbrig (Sep 12 2017 at 16:54):
Excellent. Will hold off until I hear back.
Grahame Grieve (Sep 13 2017 at 14:19):
so with regard to this... if you look at the UML for value set, you'll see that the elements in question live in a named class
Grahame Grieve (Sep 13 2017 at 14:20):
"ConceptSet"
Harold Solbrig (Sep 13 2017 at 16:47):
Yes -- with two associations, one named "include" and one named "exclude"
Grahame Grieve (Sep 13 2017 at 16:56):
right. so the thing is, the name on the properties should not be either '.include' or 'exclude', it should be '.conceptSet'
Harold Solbrig (Sep 13 2017 at 21:00):
That is exactly how it would have worked had we built a complex type for ConceptSet rather than embedding its definition inline, no?
Grahame Grieve (Sep 13 2017 at 21:44):
yes. but we don't have to build a complex type for that- we just have to use the supplied name properly
Harold Solbrig (Sep 14 2017 at 17:59):
Makes sense. Looks like it comes from the structuredefinition-explicit-type-name extension. A possible issue -- if it were a complex type, its name would necessarily be unique. Here, no guarantee. Do we ( a ) prefix ValueSet onto it or ( b ) just assume that it will be unique or ( c ) your're just confused, Solbrig, stop overthinking it??
Grahame Grieve (Sep 14 2017 at 18:08):
prefix ValueSet on it, i think. But we don't always do that. Next week I'll look into the conditions under which we can assume it's unique
Harold Solbrig (Sep 14 2017 at 18:33):
No big hurry. I'm testing a python based JSON to RDF conversion utility and this is one of the issues I've encountered.
Harold Solbrig (Sep 14 2017 at 18:33):
The other is just a 24 caret bug, most likely on my part. I filed a report on it, but I think I'll just go ahead and fix it...
Last updated: Apr 12 2022 at 19:14 UTC
