We should not use fhir:value for non-hoisted scalar properties

[dbooth-boston]

In FHIR JSON, a scalar property such as Patient.gender is represented directly:

"gender": "male",

In R4 FHIR RDF we have an intervening blank node, and then used fhir:value (as an OWL datatype property) to hold the actual scalar value:

fhir:Patient.gender [ fhir:value "male" ] .

But FHIR uses the "value" property for other purposes that are not datatype properties. So we should use a different property name for this purpose.

[dbooth-boston]

We discussed this on 28-Jul-2022

ACTION: jim to look into whether rdf:value would work instead of fhir:value

[csisc]

Description of rdf:value:
rdf:value is an instance of rdf:Property that may be used in describing structured values.

rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example below:

EXAMPLE 1
http://www.example.com/2002/04/products#item10245
http://www.example.org/terms/weight [
rdf:value 2.4 ;
http://www.example.org/terms/units http://www.example.org/units/kilograms
] .
Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind.

The rdfs:domain of rdf:value is rdfs:Resource. The rdfs:range of rdf:value is rdfs:Resource.

[dbooth-boston]

It occurs to me that rdf:value might not solve the problem anyway, because we need something that would only be used as an OWL datatype property, but there is nothing in RDF to prevent rdf:value from being used as an object property.

[dbooth-boston]

Discussed on 2-Aug-2022.

I see that OWL has owl:topDataProperty. If we chose that we'd have:

fhir:Patient.gender [ owl:topDataProperty "male" ] .

which seems painfully long to type, given that it will be used for every scalar in FHIR RDF.

I don't see anything appropriate in the Relation Ontology either, plus they use unfriendly names for their properties, like:

obo:RO_0002029  rdf:type  owl:DatatypeProperty .

[matentzn]

Maybe @balhoff can comment more but semantically speaking using topObjectProperty is not ideal as it implies.. nothing. Every thing in the multiverse is connected to everything else with topObjectProperty! (Annoying lurker, out. Sorry :P)

[dbooth-boston]

(REJECTED) Option 0: Keep fhir:value

This option definitely would not play well with OWL, because in R5 fhir:value is already being used as an object property, so it would be used as both an object and datatype property in FHIR RDF data.

(REJECTED) Option 1: Use rdf:value

This option would force users to choose between playing well with OWL vs using rdf:value as an object property anywhere else in their data, which would restrict users beyond how rdf:value was originally defined.

(REJECTED) Option 2: Use fhir:scalar

This does not seem likely to conflict with any property that FHIR might invent in the future.

(REJECTED) Option 3: Use fhir:literal

This does not seem likely to conflict with any property that FHIR might invent in the future.

(AGREED) Option 4: Use fhir:v

Since FHIR uses full words in its property and class names, this does not seem likely to conflict with any property that FHIR might invent in the future.

(REJECTED) Option 5: Use prov:value

[dbooth-boston]

On today's call we agreed to use fhir:v as the property name for non-hoisted scalars, instead of fhir:value:

AGREED: choose fhir:v

[dbooth-boston]

Done and implemented in R5