Context sensitive date data types

[hsolbrig]

The FHIR date and dateTime data types can map to one of xsd:date, 'xsd:dateTime,xsd:gYearorxsd:gYearMonth` depending on the actual value.

This seems like possible overkill from the RDF, especially when one considers the fact that only xsd:dateTime is recognized by most OWL processors (see: https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#IRIs)

Would propose that the RDF specification unconditionally map fhir:date and fhir:dateTime types to xsd:dateTime

[ericprud]

That would require inventing up to a half year's precision when mapping e.g.

{
  "resourceType": "Observation",
  "id": "obs1",
  "effectiveDateTime": "2016"
}

to e.g.

<obs1> a fhir:Observation;
  fhir:Observation.effectiveDateTime "2016-06-15T12:00:00Z" .

(I also don't want to fall back to something loosely-typed. The un-typed expression of FHIR/JSON dateTimes requires every JSON processor to reinterpret every fhir:dateTime while the RDF processor can rely on the datatype.)

[dbooth-boston]

See also #62: xsd:date, xsd:time etc. do not work with OWL.

[gaurav]

I think we should just embrace the Seven Property Model and tell people to use the right type given how precise their date is. Yes, this will cause problems with OWL and with other systems that don't implement this properly, but they're wrong and should do better.

One terrible way of resolving this would be to require that values in xsd:dateTime are always required, and then additional, less precise options (such as xsd:gYearMonth) can be additionally provided, with any compliant implementation required to use the lease precise option provided. But that seems like it's just asking for trouble :)

[ericprud]

I think we should just embrace the Seven Property Model and tell people to use the right type given how precise their date is. Yes, this will cause problems with OWL and with other systems that don't implement this properly, but they're wrong and should do better.

I read this as supporting specifically-typed literals in FHIR/RDF. (I also support that.) The cost is that conversions have to inspect the scalar value to do the conversion. For instance, a single JSON-LD @context won't do these conversions:

"2021" -> "2021"^^xsd:gYear
"2021-10" -> "2021-10"^^xsd:gYearMonth
"2021-10-01" -> "2021-10-01"^^xsd:date
"2021-10-01T18:21:17+02:00" -> "2021-10-01T18:21:17+02:00"^^xsd:dateTime

If you have special knowledge of a particular data source, you might know that e.g. all of the Observations effectiveTiming/events are xsd:dateTimes, which might allow you to do some blanket casting with having to parse every value.

One terrible way of resolving this would be to require that values in xsd:dateTime are always required, and then additional, less precise options (such as xsd:gYearMonth) can be additionally provided, with any compliant implementation required to use the lease precise option provided. But that seems like it's just asking for trouble :)

agreed. RDF already does a perfectly good job of capturing this data. It's just that we have to pay attention when importing.

[gaurav]

I haven't gotten FHIRJsonLDAmiaPaper repository to work yet, but it does include code for preprocessing FHIR JSON files to add the right type for partial dates:

https://github.com/fhircat/FHIRJsonLDAmiaPaper/blob/eac62b6a5030fd82223a28bade05c14e1762b577/fhir_jsonld_amia/json_preprocessor.py#L87-L110

So adding that to the structural transforms does appear to be a good way to do this.

[dbooth-boston]

From minutes of 10/14/2021:

AGREED: close 78 with no changes to R4.

[dbooth-boston]

See also comments in issue #86 about how to handle this in JSON-LD 1.1

[tmprd]

Just want to point out here that 11 examples of SubscriptionStatus (all except the "bare" one) use xsd:datetime with 7 digits of fractional seconds. The HermiT reasoner didn't support this until v1.4.4