Support of {@type:{@id:xxx}} constructs

[cygri]

According to the Expansion algorithm, this is illegal because the value of @type is an object and is not empty:

{
  "@type":{"@id":"A"}
}

But the Playground allows it.

[lanthaler]

We still have this in the JSON-LD grammar section

A JSON-LD processor should process non-conforming documents having @type values including node definition or node reference entries but must discard everything except for the value of the @id key.

Gregg introduced this some time ago as a way to work around the automatic conversion from rdf:type to @type but since we now have a flag for this it wouldn't be needed anymore. Quite some time ago I filed #114 for exactly the same reason but we didn't really resolved that specific issue. Instead we

RESOLVED: In general, if the author's intent is clear, we should transform the input into proper JSON-LD (keeping the processor mode, if any, in mind - in strict mode, throw exceptions, in lax mode, attempt to interpret the value).

I would certainly be in favor of removing this from the spec as it doesn't bring any advantages and just complicates things by allowing more variations.

[gkellogg]

There were some corner cases, where a document could be represented using an "rdf:type" property, expanded and re-compacted to use @type by aliasing "rdf:type" to @type. For this to work, compaction needs to take this into account.

I think @niklasl had this issue. I'm ambivalent about keeping this.

[lanthaler]

PROPOSAL: Do not support constructs like "@type":{"@id":"A"} in the spec as that would suggest to developers that they could include other properties of the type there as well.

[niklasl]

+1. My use case is solved by the useRdfType flag to compaction. That handles the (probably rare) cases where rdf:type needs to be preserved as a regular relation to an object.

(The usage scenario came from a situation in ElasticSearch, containing RDF as compact JSON-LD, to support search for resources based on type labels or other properties, and not the type symbol itself.)

[cygri]

+1 to proposal

[gkellogg]

+1

[lanthaler]

RESOLVED: Do not support constructs like "@type":{"@id":"A"} in the spec as that would suggest to developers that they could include other properties of the type there as well.

[lanthaler]

The statement was removed from the grammar section in c4649c9.

As this issue is now solely related to the playground I remove the milestone and the spec labels.

@dlongley, could you please ensure that the playground throws an error. I think you have a strict mode in your processor, right?

[dlongley]

This has been fixed on the playground. (22c9210)