This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR RDF Mapping - Potential Strategies"
Jump to navigation
Jump to search
| Line 3: | Line 3: | ||
== Option 1: Custom Mapping with ShEx == | == Option 1: Custom Mapping with ShEx == | ||
| − | In practice, | + | 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: | Description: | ||
*http://www.w3.org/2014/Talks/1125-fhir-rdf-egp/#%281%29 | *http://www.w3.org/2014/Talks/1125-fhir-rdf-egp/#%281%29 | ||
| + | |||
| + | 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 == | == 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. | ||
| + | |||
Description: | Description: | ||
* Slides 8-10 of http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf | * 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 brief/verbose use of @context == | == Option 3: JSON-LD brief/verbose use of @context == | ||
Description: https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0064.html | Description: https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0064.html | ||
Revision as of 19:03, 24 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.
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 brief/verbose use of @context
Description: https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0064.html
