json-ld/json-ld.org — Issue #84: Support for controlled probing of unlinked objects
Author: niklasl
Created: 2012-03-06 13:24:14+00:00
State: open

Currently, JSON-LD allows for undefined or null-bound terms, to make it possible to mix in plain old JSON in documents. This is to support e.g. legacy, annotation or application-specific purposes. We have looked into the possibility to "probe" values for such terms for more JSON-LD, but concluded that it would be to uncontrollable, given that data in such values may have entirely local meaning. Trying to parse that could result in unintentional gleaning of unexpected or strange data.

However, there is an opportunity here to let contexts declare that certain null-bound terms must be probed. Specifically, we could use `@container` for this purpose. Consider a term declaration like:

"isReferencedBy": {"@id": null, "@container": "@set"}

This would instruct a parser both to *not* intrepret `isReferencedBy` as a property (and thus not link from the current resource to the value), *and* to parse the value as if it was JSON-LD.

The specific value for `@container` must be decided of course. Here I use `@set`, which is under discussion and not currently part of JSON-LD. We could imagine `@object` here as well (or perhaps just `true`), to state that the value should be one specific object (and even `@list` to create a disconnected rdf:List).

A real use case where this might be applied is to allow for application-specific encoding of reverse relations (i.e. "things which links to this resource"). Here is an example of that:

{
"@context": {
"@language": "en",
"title": "http://purl.org/dc/terms/title",
"references": "http://purl.org/dc/terms/references",
"isReferencedBy": {"@id": null, "@container": "@set", "_inverseOf": "references"},
},
"@id": "http://example.org/doc/core",
"title": "Core",
"isReferencedBy": [
{
"@id": "http://example.org/doc/primer",
"title": "Primer",
"references": {"@id": "http://example.org/doc/core"}
}
]
}

Notice that if `isReferencedBy` is probed, the related object would be parsed, along with its link to the top-level resource. In other words, this makes for very usable JSON as well as a formal representation of the relevant underlying graph. (The `_inverseOf` is an example of how a non-standard, application-specific serializer extension which triggers this special representation form may look. That's really orthogonal to this issue though.)