feature request: support `$schema` as an alias for `@context`

[pchampin]

More precisely, I suggest that JSON-LD processors do the following:

• if a document contains "$schema": "URI1" and no "@context", it behaves as if the document contained "@context": "URI1"
• if a document contains "$schema": "URI1" and "@context": [ ... ], it behaves as if the document contained "@context": [URI1, ...]
• if a document contains "$schema": "URI1" and "@context": ... (a string or an object), it behaves as if the document contained "@context": [URI1, ...]

The rationale is the following:

• one big advantage of JSON-LD based formats is that developers can chose to treat them as RDF or as plain JSON. The current narrative is something like "this "@context": "..." key is mandatory to be compliant, but you can ignore it if you are only interested in plain JSON". Nevertheless, this "@context" key is perceived as unusual and possibly harmful by many JSON developers.

• What JSON developers are used to, on the other hand, is a "$schema" key indicating a JSON-Schema that the JSON document is supposed to be complying with. As an aside, I consider it good practice to provide a JSON-Schema for any JSON-LD based format. It defuses the misconception that JSON-LD contexts and JSON-Schema are competing technologies, it is useful for documenting and validating the JSON-LD based format, and it strengthen the argument that the format is usable as plain JSON.

• So the suggestion is that JSON-LD based format mandate the use of "$schema": "..." instead of "@context": "...", which requires that JSON-LD processor understand this (hence this feature request). The URL of the schema could behave in two different ways:

  • it could return the JSON-Schema OR the JSON-LD context based on content negociation (application/json vs. application/ld+json), or
  • it could return a JSON document containing both the context and the JSON-Schema. The JSON-Schema specification accepts a "@context" key (and will plainly ignore it) while JSON-LD processor will only be interested in the content of "@context" and ignore the rest.

Caveats: the proposed behavior might break some documents that already point to a "normal" JSON-Schema (i.e one that does not contain a @context key). We might want to add a special case for contexts loaded via "$schema", so that they don't raise an invalid default context in that case.

[BigBlueHat]

The confusion definitely needs solving, but horses and unicorns are different...despite their similarities.

[BigBlueHat]

It is, however, totally conceivable to create a more expressive context file which could potentially work as both--though I think we leave the key name as @context if that's it's current primary purpose. The Web of Things group mapped JSON Schema to RDF: https://www.w3.org/2019/wot/json-schema

It's possible to turn a context file into an actual JSON-LD document (and rather than the unique thing they are), and in that document more fully express vocabulary, schema, etc. I've seen it done a number of times (and ways...), but standardizing on an approach to that could be pretty epic. 😃

[pchampin]

@BigBlueHat

horses and unicorns are different...despite their similarities.

I totally agree that they are different, but schemas and context are also very complementary. When designing a JSON-LD context, we are making assumptions about how the instance data will be organized. When designing a JSON-Schema, we have an idea of the semantics of the attributes described by the schema...

I was aware of the WoT WG group you link to, but I had overlooked one of the use-cases they point to : Defining a JSON-LD context for data instances. While the technicalities are different from my proposal above, the general idea is the same : use the schema to convey the context that should be applied to the instance data. My proposal above would become something like that :

• if a document contains "$schema": "URI1", URI1 should be dereferenced as JSON-LD, and if it contains a triple <URI1> jsonld:context <some-context>; then some-context should be prepended to the (list of) context(s) of the current document

Would this be more acceptable? I admit that, although slightly more complicated, it is a cleaner solution.

[gkellogg]

This was discussed in a CG Meeting and it was decided to close the issue without prejudice.