Support JSON values that aren't mapped

[lanthaler]

This has already been discussed several times usingvarious terms.. the most recent request has come from David Janes on the mailing list. The basic idea is to support JSON values/subtrees that aren't mapped to an IRI in the context. They should survive algorithmic transformations (basically without being touched at all).

[gkellogg]

Perhaps something like @container: @literal to treat it something like the way RDFa treats rdf:XMLLiteral or rdf:HTML. To support RDF transformations, it probably deserves its own datatype IRI.

[dlongley]

Might need to be more specific about the type of literal to allow for different types of processing/passthrough like: @container: @json.

[gkellogg]

See http://geojson.org/geojson-ld/ for a motivation for use in GeoJSON.

[gkellogg]

Thinking about this some more, it's important to consider the desired expanded representation. IMO, allowing values of @value to include objects and arrays (framing has some use of this now, so we need to be somewhat careful) is the natural way I would see data to be expanded, along with an appropriate datatype. For example:

[{
  "@id": "http://exaple/foo",
  "http://example/json-value": [{
    "@value": [{"native": "json"}],
    "@type": "http://www.w3.org/ns/jsonld#JSON"
  }]
}]

This allows the JSON {"native": "json"} to be represented as the value of http://example/json-value. When compacted, it might look like the following:

{
  "@context": {
    "@vocab": "http://example/",
    "@base": "http://example/",
    "jsonld": "http://www.w3.org/ns/jsonld#",
    "json-value": {"@type": "jsonld:JSON"}
  },
  "@id": "foo",
  "json-value": {"native": "json"}
}

Using @container: @set could be used to force the compacted version to be in array form.

Transforming to RDF would preserve the jsonld:JSON datatype, and perform a canonical JSON serialization of the content, deserializing when going back from RDF to JSON-LD. There may be implications for RDF L2V.

[niklasl]

For the record, as discussed in the call, we might consider supporting all possible JSON values (i.e. strings, booleans, numbers, and null as well as objects and arrays).

[gkellogg]

Discussed on the call today:

RESOLUTION: adopt solution defined in #333 (comment) as an interum solution, with final selection of the datatype to a future WG.

We may experement with using @type: @json to signal this, and leave the datatype IRI for the RDFa conversion.

[gkellogg]

Deferred to WG due to https://json-ld.org/minutes/2018-04-10/#resolution-3.

[gkellogg]

Closed in favor of w3c/json-ld-syntax#4.