FHIR RDF Mapping - Potential Strategies
- Return to ITS Main Page | ITS RDF Minutes 2014 | All ITS RDF Pages | ITS Email Archives | W3C HCLS Email Archives | Issues List
Contents
Option 1: Custom Mapping with ShEx
This strategy would use a custom FHIR XML<->RDF mapping, defined using ShEx. In practice, it would be mostly generated from the FHIR specification (as EricP and Josh Mandel did), with some customizations to produce the desired RDF result.
Description:
Pros/Cons:
- (PRO) This strategy gives us the most latitude in the style of RDF that we can choose.
@@ TODO: Add an example @@
Option 2: JSON-LD with @lists
In this strategy, FHIR would adopt JSON-LD instead of plain JSON, by adding a single @context line to the beginning of the existing FHIR JSON. The referenced @context would use @list to ensure that ordering information is retained in the corresponding RDF. Because JSON-LD offers no way in a single @context to distinguish between differ uses of the same term in different places with a JSON document, @list would use pretty much everywhere.
Description:
- Slides 8-10 of http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
Pros/Cons:
- (PRO) No need to define a third FHIR representation: standard JSON-LD parsers could interpret FHIR JSON-LD instance data as RDF.
- (CON) The resulting RDF would have RDF lists wrapped around single items when they otherwise would not need to be in lists, because the @context would not be able to distinguish cases that need list to retain ordering and cases that do not.
@@ TODO: Add example @@
Option 3: JSON-LD use of @context
In this proposal, just add @context at the root of each resource (next to 'resourceType'). The @context refers to content on the HL7 website that provides the information to build and RDF form from the JSON.
Pros/Cons:
- (CON) This requires JSON-LD to adopt proposal [[1]]. The likelihood and timing of this are unknown
- (PRO) This is reasonable to ask all implementers to add to every instance (even more reasonable if we can use it to replace 'resourceType', though that would need another JSON-LD proposal)
- (PRO) If all implementers do it, all json is json-LD
Example:
{
"@context" : "http://hl7.org/fhir/Patient/json-ld",
"resourceType": "Alert",
"id": "example",
"status": "active",
"patient": {
"reference": "Patient/example",
},
"author": {
"reference": "Practitioner/example",
},
"note": {
"text": "Patient has a big dog at his home. Always always wear a suit of armor or take other active counter-measures"
}
}
Option 4: Transform to JSON-LD
Actually, the transform from existing JSON to json-ld is algorithmic. There's an direct 1:1 relationship between resourceType and the @context. If the json-ld @ proposal in the previous option is not adopted, then the only option for json-ld is to stick @context everywhere
Pros/Cons:
- (CON) overhead in the exchanged form; production systems will not use it
- (CON) this is what the json-ld spec is 'bad design'
- (PRO) well, it'll work
Example:
{
"@context" : "http://hl7.org/fhir/Patient/json-ld",
"resourceType": "Alert",
"id": "example",
"status": "active",
"patient": {
"@context" : "http://hl7.org/fhir/Reference/json-ld",
"reference": "Patient/example",
},
"author": {
"@context" : "http://hl7.org/fhir/Reference/json-ld",
"reference": "Practitioner/example",
},
"note": {
"@context" : "http://hl7.org/fhir/CodeableConcept/json-ld",
"text": "Patient has a big dog at his home. Always always wear a suit of armor or take other active counter-measures"
}
}
Note: actually, it's not clear whether the inner @contexts should be path or class based (class in this example). Hard nasty problem to solve; you actually want both depending on your perspective.
But, you know, you can do the transform to this form anyway, but if you can do that, you can just transform directly to triples using the same data anyway; it seems kind of pointless to even use json-ld
