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

Difference between revisions of "FHIR RDF Mapping - Potential Strategies"

From HL7Wiki
Jump to navigation Jump to search
Line 26: Line 26:
 
@@ TODO: Add example @@
 
@@ TODO: Add example @@
  
−
== Option 3: JSON-LD brief/verbose use of @context ==
+
== Option 3: JSON-LD use of @context ==
−
This strategy attemps to work around the @list problem of option 2 by using different @contexts at different points in the JSON hierarchy.  It would use JSON-LD as a mechanism for mapping to RDF in a two-step process.  Plain FHIR JSON (perhaps with a single @context statement) would be transmitted on the wire, but this would be considered the "brief" form.  To propertly interpret the data as RDF, it would first have to be transformed into the "verbose" form by a standard JSON transformation that would insert lots of @context statements into different points in the JSON hierarchy, so that different uses of the same JSON term could be mapped differently to RDF.
 
  
−
Description: https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0064.html
+
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:
 
Pros/Cons:
−
* (PRO) @@ TODO: Ask Grahame to fill in @@
+
* (CON) This requires JSON-LD to adopt proposal [[https://github.com/json-ld/json-ld.org/issues/247]]. 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
  
−
@@ TODO: Add example @@
+
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

Revision as of 12:03, 25 March 2015

Return to ITS Main Page | ITS RDF Minutes 2014 | All ITS RDF Pages | ITS Email Archives | W3C HCLS Email Archives | Issues List

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:

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

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