Closed dbooth-boston closed 11 months ago
We discussed this on 28-Jul-2022
ACTION: jim to look into whether rdf:value would work instead of fhir:value
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.
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.
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 .
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)
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.
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.
This does not seem likely to conflict with any property that FHIR might invent in the future.
This does not seem likely to conflict with any property that FHIR might invent in the future.
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.
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
Done and implemented in R5
In FHIR JSON, a scalar property such as Patient.gender is represented directly:
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:
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.