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
