Properties with both scalar and object range: fhir:value inside of fhir:value

[dbooth-boston]

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"
  ];

[balhoff]

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.

[dbooth-boston]

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.

[dbooth-boston]

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

[dbooth-boston]

AGREED: option 5, not hoist scalars (same as R4)

https://www.w3.org/2022/07/28-hcls-minutes.html#t01