Discussion: JSON-LD

[cbizon]

Here's a place to discuss JSON-LD readings. Maybe not the best place, but it's convenient.

I think that the 1.1 spec we pulled up on the call is a current draft & might change. The 1.0 version is here:
http://www.w3.org/TR/json-ld/

[bpow]

In response to questions about JSON-LD and JSON Schema relationship/interoperability, I can refer to https://lists.w3.org/Archives/Public/public-linked-json/2014Oct/0010.html and related discussions. Quoting from that email:

They serve different purposes. The short version is: JSON-LD give JSON messages a well-defined meaning by mapping most things to IRIs. JSON Schema describes the syntactic structure of a JSON document. Both work with JSON so you can use them together

[cbizon]

One observation: In the context, one can map from strings to IRIs. But I don't see that you can map from strings to keywords like @id or @type. Based on this, I think we want to change "cg:id" to "@id" and "cg:type" to "@type".

Updated: Turns out this is wrong. You can alias keywords (see 6.15). I would still argue against it though.

However! It turns out that aliasing these is "best practice":
w3c/activitystreams#232 (comment)

[cbizon]

We are going to have something like

variant:

And sometimes we will want the value to be a node with properties like

variant: {
  @id: http://alleleregistry/CA001
  reference_sequence: NM_000384.1
  ref: A
  alt: C
}

(or whatever, I just made up properties). But other times, we want to just refer to this by id, and not include all of the information. I think that we can do it like this:

variant: { "@id": " http://alleleregistry/CA001"}

but not like this:

variant:  "http://alleleregistry/CA001"

You can do this latter version, but then you have to say in the context that the whole value is an IRI, and then it's hard to interchange with the fully-described node.

Another option, you might think, is to have different contexts in different nodes, and that could work for the main variant, but it will become hard to figure out when we have arbitrarily many variants in the evidence.

...Updated...

It really depends on what goes into the context and what goes into the schema. So for instance, take a look at this
http://json-ld.org/spec/latest/json-ld-api-best-practices/
In example 10, there is a spouse key which has a person as a value, and the nested person has a spouse, which has the id of the nesting person for its value. The context
(located here: http://schema.org/docs/jsonldcontext.json ) has this entry:
"spouse": { "@id": "schema:spouse"},
So it just maps the name "spouse" to the qualified "http://schema.org/spouse". It doesn't specify the type, so you can put anything you want. If this included "@type": "@id" then I think I would be right. I'm not sure what kind of flexibility the schema gives you.

[cbizon]

The context can be external or inline. Do we have a preference?

[tnavatar]

External probably. Especially if we choose not to use curie identifiers (i.e. reference_sequence: "NM_12345" vs cg:reference_sequence: "NM_12345".) Both can be valid, but the latter requires us to list every single field in the context, which is going to bloat the message like crazy.

[tnavatar]

Also regarding the aliasing discussion: I've found the @ in json-ld to be at least a minor pain; I would be perfectly content to alias it if it's considered best practice. I think if we do, it simply becomes id and type, and not cg:id and cg:type.

[larrybabb]

Here's the http://build.fhir.org/fhir.jsonld context and the allele registry http://reg.genome.network/schema/allele.jsonld context for informative purposes.
The fhir.jsonld model is actually coming along fairly quickly, and there seems to be a definite method to their madness.
Should we consider following one or the other's approach?
I do agree with Tristan. The external context is a good approach and I'm fine with aliasing everyting including the id and type terms.

[cbizon]

I think it certainly makes sense to use the parts of fhir around codable concepts rather than re-invent it. Otherwise, I'm not sure what exactly it would mean to follow one or the other's approach?

[cbizon]

When it comes to validation, JSON schema is probably the most sensible, but there is also SHACL to consider:
https://www.w3.org/TR/shacl/

It is still evolving, and I don't know how much tooling there is, but it looks interesting.

[cbizon]

Also shex:
https://shexspec.github.io/spec/

[cbizon]

Discussion Closed