Hi David,
On my reading there are actually two problems with the approach you've
suggested:
1. (Which you call out explicitly) there are extra Lists wrapping the data
in various places with no particular semantics attached. This is annoying
clutter but potentially viable.
2. (Which I don't think you've addressed) the two uses of "code" in the
FHIR JSON payload you described are quite different, and shouldn't map to
the same RDF predicate. Specifically, when we see:
"resourceType": "Observation",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "3141-9"
}
]
},
The outer-most "code" would map to a predicate like <
http://hl7-fhir.github.io/observation-definitions.html#Observation.code>
(meaning "a coded term naming the thing observed", or follow the link to
see FHIR's official definition for the meaning of this property), whereas
the innermost "code" would map to a predicate like <
http://hl7-fhir.github.io/datatypes-definitions.html#Coding.code> (meaning
"a symbol in syntax defined by the system").
I think it would be a mistake to map both <
http://hl7-fhir.github.io/observation-definitions.html#Observation.code>
and
<http://hl7-fhir.github.io/datatypes-definitions.html#Coding.code> to
"fhir:code". (Apologies if you had already noted this and were just trying
to use this as an example to make a different point -- if so, I got
distracted!)
Best,
Josh