Enable @context to map a property differently depending on its hierarchical path

[dbooth-boston]

In mapping a JSON property to an RDF URI, it is not currently possible (in JSON-LD 1.0) to use a single @context to map the same property name to different RDF URIs depending on that property's position in the JSON hierarchy. It would be helpful to be able to do this, perhaps by using the hierarchical path of the property. For example, in the following JSON, notice that the "code" property appears twice, at different levels of the hierarchy, and its value is an object in one case and a string in another. (See slide 9.)

{ "resourceType": "Observation",
  "id": "example",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "3141­9",
        "display": "Weight Measured"
      }
    ]
  }

If the @context could allow a path-dependent mapping, then this problem could have been solved. For example, these two paths would allow the above "code" properties to be distinguished:

code
code/coding/code

BACKGROUND This issue derives from an important use case that we faced in healthcare. In 2015 as part of a collaboration between HL7 and W3C we were trying to figure out an acceptable way to provide a JSON-LD serialization for FHIR. (FHIR is the latest up-and-coming HL7 standard for exchanging healthcare data.) FHIR already offered XML and plain JSON serializations, and the goal was to add support for RDF. Since JSON-LD can be used either as plain JSON or as RDF, we were hoping that we could figure out a JSON-LD @context and serialization that would be friendly to plain JSON users but also provide the desired mapping to RDF. We explored possibilities but reached a show-stopper when we discovered the above limitation, because the only work-arounds that we were able to figure out would have put too much burden on plain JSON users.

For example, one potential work-around would have been to include an addition @context nested in the instance data whenever the nested use of the "code" property appears. This would have achieved the RDF compatibility goal, but it would have been too onerous for plain JSON users who would have seen no good reason for having it there.

Another potential work-around would have been to change the JSON property names to make them unique, such as using "code" and "codeValue". But the design philosophy of FHIR did not allow this much central control over different parts of a FHIR data object, and the FHIR/RDF camp did not have the clout to convince plain JSON users of the need, since we are far outnumbered.

Because of this limitation we had to abandon the option of using a single JSON-LD serialization for both plain JSON users and RDF users. That seemed quite unfortunate given that a major goal of JSON-LD is to bridge these worlds. We are hoping that this limitation can be addressed in the next version of JSON-LD.

[gkellogg]

Hi @dbooth-boston, JSON-LD 1.1 introduces the notion of scoped contexts, which sounds like what you're looking for. In your example, the term definition for "coding" could introduce a scoped context that re-defines the URI associated with "code. For example, look at the playground link.

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "coding": {
      "@context": {"code": "http://something-else.example.com/code"}
    }
  },
  "resourceType": "Observation",
  "id": "example",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "31419",
        "display": "Weight Measured"
      }
    ]
  }
}

[dbooth-boston]

Excellent! This looks like it is exactly what we needed. Sorry I did not find this feature when I searched the issues list. I will close this issue now.