Re: Two-step JSON-LD possibility for FHIR [was Re: Proposed RDF FHIR syntax feedback]

> I don't think an @context can produce any implied triples

oh? damn. no, but hang on, if the @context says what resourceType currently
says, then surely that information makes it's way into RDF, and you don't
need a triple for resource type.

I'll illustrate what I'm proposing by taking a nice short existing example,
from http://hl7-fhir.github.io/substance-example.json.html. Here's what the
full (verbose) json-ld form would look like:

{
  "@context" : "http://hl7.org/fhir/StructureDefinition/Substance",
  "id": "example",
  "text": {    "@context" :
"http://hl7.org/fhir/StructureDefinition/Resource#text",    "status":
"generated",
    "div": "<div>!-- Snipped for Brevity --></div>"
  },
  "type": {
    "@context" : "http://hl7.org/fhir/StructureDefinition/CodeableConcept",
    "text": "apitoxin"
  }
}


The minimal form would be:

{
  "@context" : "http://hl7.org/fhir/StructureDefinition/Substance",
  "id": "example",
  "text": {
    "status": "generated",
    "div": "<div>!-- Snipped for Brevity --></div>"
  },
  "type": {
    "text": "apitoxin"
  }
}


using this method, a system that consumes the minimal form (the production
usage form) can process the full json-ld form without needing to do
anything special - it's the same stuff to them. A system that consumes the
full json-ld form would need to run a transform to convert the second form
to the first. (I'd add this to the reference implementations as a property
verbose = true on the json serialiser, and we could provide a javascript
convertor too)

This has the advantage that json-ld can easily be integrated into a
production system without imposing the metadata overhead on both
programmers and operational systems, and a simple completely automatic
transformation to proper json-ld

Alert readers will note some problems in my choice of URLs, but I'm
assuming that if we wanted to pursue this general approach, we could work
the URL thing out.

Grahame


On Wed, Mar 18, 2015 at 8:27 AM, David Booth <david@dbooth.org> wrote:

> I had some conversation with Grahame today on the ITS call, and I think I
> got a clearer idea of what he was suggesting for JSON-LD, which I'll
> summarize (with some liberties).
>
> The basic idea is to allow two forms of JSON: brief and verbose.  The
> brief form would basically be the same as the existing FHIR JSON (though
> possibly with a single @context at the top).  The verbose form would also
> be the same *except* that it would have lots of @context statements
> interspersed throughout the nesting structure, to allow it to be processed
> as JSON-LD while differentiating between different uses of the same JSON
> properties.  A simple standard script could expand the brief form to the
> verbose form prior to translating it to RDF.  The @context statements would
> be allowed in either case (or maybe not -- either way would work), but if
> allowed they would be ignored by regular JSON processors if they were
> present.
>
> The reason for interspersing lots of @context statements in the verbose
> JSON is to allow different uses of the same term to be differentiated by
> the term's position in the JSON hierarchy.  For example, the following
> brief JSON uses "code" in two different ways:
>
> {
>   "resourceType": "Observation",
>   "code": {
>     "coding": [
>       {
>         "system": "http://loinc.org",
>         "code": "3141-9"
>       }
>     ]
>   }
> }
>
> This might be represented in the verbose style by adding two @context
> statements that map "code" different, one for the Observation.code case and
> one for the Coding.code case:
>
> {
>   "@context": "http://...fhir/Observation",
>   "resourceType": "Observation",
>   "code": {
>     "coding": [
>       {
>         "@context": "http://...fhir/Coding",
>         "system": "http://loinc.org",
>         "code": "3141-9"
>       }
>     ]
>   }
> }
>
> I believe Grahame originally suggested *replacing* the "resourceType" line
> with an @context line, but I think both lines will be needed in order to
> generate an RDF triple that indicates the resource type, since I don't
> think an @context can produce any implied triples.
>
> Another choice point for this idea is whether to allow @context lines in
> the brief JSON.  Two downsides of allowing them: (a) regular JSON
> processors would have to ignore them; and (b) it may be confusing to allow
> brief FHIR JSON to contain @context statements because someone putting it
> through a JSON-LD processor would generate the wrong RDF if it had not yet
> been fully expanded into the verbose version first.   I think Grahame
> mentioned that there may also be a plus side but I've lost track of what
> was.  Maybe Grahame can jump in to explain that.  On the other hand, if
> @context lines are *not* allowed in the brief JSON then this approach is
> somewhat similar to using a custom mapping to RDF, though simpler to
> implement.
>
> In short, this overall approach seems like a viable option that we should
> consider.
>
> Thanks,
> David Booth
>
> On 03/06/2015 04:50 AM, Grahame Grieve wrote:
>
>> I'm not sure that I undestand this discussion. Every Fhir structure
>> defintion and value set (and other definitional resource) already has an
>> IRI.- it's an inherent part of the design. So the IRI for the structural
>> definition of patient is
>> http://hl7.org/FHIR/StructureDefinition/Patient. All valuesets have a
>> clearly defined IRI right in the valueset.
>>
>> I don't understand why anything else is required. At least in terms of
>> linked data, I've always thought of FHIR as inherently linked data ready.
>>
>> Operational data will be more of a challenge. The pseudo authoritative
>> way that identity is asserted without really thinking it through in most
>> of the linked data work I see is quickly exposed as wishful thinking for
>> those of us who deal with production healthcare data with its inherent
>> slipperiness. Still, we've done what we can - every FHIR resource has an
>> inherent IRI built right into it (if you know the server). The resource
>> address doesn't change, even If its not the same as the identity of the
>> thing it refers to.
>>
>> So resource.id <http://resource.id> is the tail of the @id attribute for
>> the resource from json-ld. ResourceType is the same as @context, and if
>> json-ld could infer structure deeply, all we'd have to do is add @id
>> (the full id), rename resourceType to @context, and use the IRI for the
>> resource instead of its name (which is the tail anyway), then the FHIR
>> format would be json-ld. Well, if we also produced a json-ld format
>> for the structure defintiion. That, at least, looks like a fairly
>> straight forward transform I could do as part of publishing the spec.
>>
>> However since it appears that json-ld doesn't dive into the type
>> definitions recursively, it seems as though a @context will be needed at
>> every level. The IRI for that is obvious too - [root]#path e,g.
>> Http://hl7.org/fhir/StructureDefinition/Patient#
>> Patient.contact.identifier
>>
>> Grahame
>>
>
>


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065