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

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

Received on Tuesday, 17 March 2015 21:27:57 UTC