Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dbooth-boston opened this issue Jan 16, 2019 · 2 comments

Comments

@dbooth-boston
Copy link

commented Jan 16, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

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

This comment has been minimized.

Copy link
Author

commented Jan 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.