This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR RDF Mapping - Potential Strategies

From HL7Wiki
Jump to navigation Jump to search
Return to ITS Main Page | ITS RDF Minutes 2014 | All ITS RDF Pages | ITS Email Archives | W3C HCLS Email Archives | Issues List

UPDATE

This page was created when the joint HL7-W3C working group was initially deciding how to approach the creation of an RDF representation of FHIR. At the time (early 2015) we decided not to use JSON-LD instead of plain JSON, but about a year later we decided to offer JSON-LD in addition to plain JSON. See:

All FHIR resource examples in the FHIR specification are now available in JSON-LD and Turtle as well as XML and plain JSON. Thanks to Grahame Grieve's efforts they are automatically generated by the FHIR specification build process. For example, here are a few of the FHIR resource examples in JSON-LD:

The JSON-LD serialization of FHIR offers two main benefits, though the plain JSON serialization is more compact:

  • All properties are unambiguous, fully qualified names, so they are not context sensitive. (In contrast, in JSON the meaning of a property name depends on its context.)
  • JSON-LD is directly interpretable as RDF, which supports automated inference, aids in large-scale data integration and is a step toward semantic interoperability across standards. See also:

The remainder of this page is OBSOLETE but retained for historical purposes.

FHIR RDF Mapping - Potential Strategies (OBSOLETE)

These are potential strategies for mapping FHIR instance data between FHIR XML or JSON and FHIR RDF.

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.
  • (PRO) May allow simulation of desired, but still missing JSON-LD features in the interim.
  • (CON) ShEx isn't a widely known/used/standardised technology, so unlikely to have well-tested libraries in many FHIR implementation languages. Uptake of SHACL (Data Shapes) as an alternative for many scenarios could potentially make ShEx less common too.
  • (CON) Requires generating intermediate XML first, which would be expensive & slow (undesirable in an API scenario).

@@ TODO: Add an example @@

(INACTIVE) Option 2: JSON-LD with @lists

We are dropping this option (at least for the time being), because the resulting RDF does not seem good enough, due to the inability from a JSON-LD @context to map the same JSON term to different RDF URIs depending on its JSON context, such as for nested JSON objects. -- Dbooth (talk) 15:40, 31 March 2015 (EDT)

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:

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.
[] fhir:resourceType 
            fhir:Observation ;
   fhir:code ( [
      fhir:coding 
      [
        fhir:system "http://loinc.org" ;
        fhir:code ( "3141-9" )
      ]
   ] ) ;
   fhir:foo [
      fhir:code ( "aaa" "bbb" )
   ] ;
   fhir:bar [
     fhir:code ([fhir:ccc "ddd"])
   ] .

(INACTIVE) Option 3: Extend the JSON-LD standard and then use of @context

We are dropping this option (at least for the time being), because it requires adding new features to JSON-LD, but the JSON-LD working group has closed. -- Dbooth (talk) 15:41, 31 March 2015 (EDT)

This proposal requires the JSON-LD standard to be extended to adopt proposal [[1]] to allow the same JSON property to be mapped to different RDF properties depending on the property's hierarchical context in the JSON document. Once this is done, 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 [[2]]. The likelihood and timing of this are unknown. (This is not likely to happen anytime soon, because it would require the W3C JSON-LD working group to be re-chartered. -- David Booth 25-Mar-2015)
  • (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"
  }
}

(INACTIVE) Option 4: Transform to JSON-LD

We are dropping this option (at least for the time being), because ultimately it just uses JSON-LD as a vehicle to translate regular JSON to RDF, but if we're transformingn regular JSON to RDF then we might as well use a less restricted vehicle to do a more tailored mapping (such as ShEx0. -- Dbooth (talk) 15:43, 31 March 2015 (EDT)

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) considered 'bad design' (undesirable) in json-ld spec to use scoped contexts within node objects like this ([3]). The context is also only partially redefined by this syntax.
  • (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

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_RDF_Mapping_-_Potential_Strategies&oldid=128628"