search

w3c / hcls-fhir-rdf

Sketching out an RDF representation for FHIR
38 stars 15 forks source link

Should target R5 require bnode and fhir:value (to accommodate FHIR extensions)? #85

Closed dbooth-boston closed 1 year ago

dbooth-boston commented 4 years ago

FHIR/RDF R4 uses this idiom:

fhir:Person.active [ fhir:value "true"^^xsd:boolean ] .

The extra bnode is there to allow for FHIR extensions. But the extra bnode is a pain for the 99.99% of cases that will not put a FHIR extension on that boolean value. RDF users would rather access the data as:

fhir:Person.active "true"^^xsd:boolean .

Indeed, this is what a naive JSON-LD 1.1 processor will produce from FHIR/JSON. But if we allow that RDF to stand, how should we handle the case where someone DOES want a FHIR extension on that boolean value?

To indicate an extension, FHIR/JSON uses underscore at the beginning of the property name. So if a FHIR extension is used in this example, the FHIR/JSON would look something like this:

 "active": true,
 "_active": {
   "extension" : [ {
      "url" : "http://example.org/fhir/boolean/Certainty",
      "valueDecimal" : 0.75
   }]
 }

If this is naively processed as JSON-LD it would then come through as RDF something like this:

[] fhir:active   true ;
   fhir:_active  [
     fhir:extension [
       fhir:url  "http://example.org/fhir/boolean/Certainty" ;
         fhir:valueDecimal  0.75
     ]
   ] .

Therefore, the path of least resistance might be to allow this as conforming FHIR/RDF. (Note that we would probably also want to declare an explicit relationship between fhir:active and fhir:_active, as described in w3c/hcls-fhir-rdf#84.)

Would this approach work? If not, how should we handle FHIR extensions in RDF, while still enabling easy RDF processing in the 99.99% of cases where extensions are not used?

hsolbrig commented 4 years ago

In my opinion, this solution has several drawbacks:

1) It requires two predicates for every primitive value -- fhir:p and fhir:_p. We need to put both of them into fhir.ttl, give them different ranges and explain that, semantically, they are the same thing. 2) It means that the processing for primitive values and compound values is different. If primitive, there are two predicates. If compound, there is one predicate.

The JSON "_" solution, IMO, was a hack specifically for JSON, because the same key could not appear twice. I don't see propagating a JSON-only kludge as the "path of least resistance"

I prefer:

[] fhir:active   true ,
   [
     fhir:extension [
       fhir:url  "http://example.org/fhir/boolean/Certainty" ;
         fhir:valueDecimal  0.75
     ]
   ] .
hsolbrig commented 4 years ago

We also need to look at making good on one of our earlier promises: Can we consider:

[] fhir:active   true ,
    [  <http://example.org/fhir/boolean/Certainty> "0.75"^^xsd:decimal . ] .

or

[] fhir:active   true ,
    [  <http://example.org/fhir/boolean/Certainty> "0.75"^^xsd:decimal ;
       a fhir:Extension . ] .
hsolbrig commented 4 years ago

As an added thought, it should be noted that both options above (fhir:active true, fhir:_active [] and fhir:active true, []) meet the monotonicity requirement in issue w3c/hcls-fhir-rdf#84

dbooth-boston commented 1 year ago

Done in R5.