Properties with both scalar and object range: fhir:value inside of fhir:value
Closed this issue · 4 comments
When a FHIR property such as fhir:valueQuantity becomes de-Curried and changed to fhir:value by parsing "Quantity" out of the property name and expressing it as the type of that value, then it causes the fhir:value property to sometime be an object property and sometimes a datatype property. Is this a problem? Do we want to allow that in R5?
Example before de-Currying:
. . .
fhir:valueQuantity [
fhir:value 6.3;
fhir:unit "mmol/l";
fhir:system "http://unitsofmeasure.org"^^xsd:anyURI;
fhir:code "mmol/L"
];
Example after de-Currying:
. . .
fhir:value [
a fhir:Quantity;
fhir:value 6.3;
fhir:unit "mmol/l";
fhir:system "http://unitsofmeasure.org"^^xsd:anyURI;
fhir:code "mmol/L"
];
Here is the section of the OWL specification which states that an IRI cannot be used as both an object property and a datatype property: https://www.w3.org/TR/owl2-syntax/#Typing_Constraints_of_OWL_2_DL
It concludes:
The typing constraints thus ensure that the sets of IRIs used as object, data, and annotation properties in O are disjoint and that, similarly, the sets of IRIs used as classes and datatypes in O are disjoint as well. These constraints are used for disambiguating the types of IRIs when reading ontologies from external transfer syntaxes.
We discussed this on today's call, and decided to use fhir:value_x as the property name when it is an object property. But then we realized that FHIR's value[x] is not only for object properties -- it's used when there is a choice of types. So we need to figure this out further. Rob Hausam will discuss it with Eric to try to figure it out, and report back.
Eric and I further discussed this issue, and Eric noticed that the common thread in three issues (#102, #69 and #77) is that if we hoist scalars (to remove the intervening bnode and fhir:value property), then we run into the issue of properties being both datatype and object properties -- #102. But if we abandon the idea of hoisting scalars, then the problem goes away. The reason it goes away is because in R4 EVERY FHIR property (except fhir:value and I think fhir:index) is an object property in order to be extensible. Issue #69, about shortening property names, also ties in, because if property names were not shortened, then the problem would partially go away, though it would still exist for the fhir:value[x] properties if we change those to fhir:value. Last week we discussed changing that to fhir:value_x instead, but then realized that even that would still have the same problem, because some of the x types are object types and some are scalar types.
All in all, Eric and I came up with five potential solutions to address #102:
Option 1: Defy OWL, and let properties be both object and datatype properties.
Option 2: Offer two flavors of FHIR RDF: OWL-friendly vs SPARQL-friendly.
Option 3: Keep the long, fully-qualified property names.
Option 4: Rename all scalar properties, perhaps by adding a special suffix.
Option 5: Not hoist scalars.
I think options 2-5 would still require us to figure out how to handle fhir:value[x] properties, to avoid having them be both object and datatype properties. I've made a separate issue #103 for that.
Bottom line is that I think we should seriously consider abandoning the idea of hoisting scalars ( #77 ).
AGREED: option 5, not hoist scalars (same as R4)