The main discussion today was around the potential use of JSON-LD to
achieve our FHIR RDF mapping. I gave an update on what I have learned
and my conclusions to date. Slides I used:
http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
Main take-aways:
- Most of the issues previously identified are not major problems.
- It seems best (to me) to take a very direct transliteration approach
in mapping to RDF. (This is what EricP and Josh Mandel had concluded
from there work also.) This means that the resulting RDF will look very
much like the original JSON (or XML) but with different syntax. This
approach eliminates lots of potential problems in round tripping, but it
also means that the resulting RDF may not be ideal for SPARQL or inference.
- The main remaining technical issue is that JSON-LD has no way with a
single @context to differentiate between different uses of a term,
because (for example) both Observation.code and Coding.code simply
appear as "code" properties in the JSON, though at different places in
the hierarchy. The main problem that this causes is that some may hold
@list values and others not. One potential solution is to generate all
values in RDF lists. Another was suggested by Grahame in email:
https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0065.html
- We'll try to figure out how much of a gap there would be, between
"direct RDF" and "ideal RDF", to see if the direct approach (whether via
JSON-LD or a custom mapping) can be close enough to the ideal to be
acceptable. EricP will suggest a use case for analysis.
Full meeting record:
http://www.w3.org/2015/03/17-hcls-minutes.html
David Booth
