Closed pchampin closed 5 months ago
The confusion definitely needs solving, but horses and unicorns are different...despite their similarities.
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. 😃
@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 :
"$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 documentWould this be more acceptable? I admit that, although slightly more complicated, it is a cleaner solution.
This was discussed in a CG Meeting and it was decided to close the issue without prejudice.
More precisely, I suggest that JSON-LD processors do the following:
"$schema": "URI1"
and no"@context"
, it behaves as if the document contained"@context": "URI1"
"$schema": "URI1"
and"@context": [ ... ]
, it behaves as if the document contained"@context": [URI1, ...]
"$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:application/json
vs.application/ld+json
), or"@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.