The absence of being

[gkellogg]

A standard model of emptiness

In summary, it would be useful if JSON-LD recognized the quantum duality of the empty list, in that it can be both value (rdf:nil) and list ([]). I would propose:

• Expansion standardizes what it does with empty lists whatever the form of the input. For consistency, rdf:nil might be best.
• Framing adapts to the needs of the frame. My current half-baked thought would be if i say "hasValue": {} in my frame, and the input is "hasValue": "rdf:nil", output would be a contextualized rdf:nil, unless "hasValue": {"@container": "@list"}, in which case output would be []. I realize this likely brings up other issues.

Finally, it would be good if the working group, once established, were to re-examine the definition of @null in the spec, or at least clarifies its relationship to RDF, and rdf:nil in particular. Currently, rdf:nil is not the same as @null, and framing treats @null as null in the output JSON, which is swallowed by at least Java deserializers, so just takes up space, and emptiness should never take up space. I touched on the this in issue 641: it would be better if a property were only set to @null if it actually meant something.

Original issue The absence of being #648

[azaroth42]

Reference for rdf:nil: https://www.w3.org/TR/rdf-schema/#ch_nil

I don't know what @null is being referred to in the issue. There isn't a @null keyword. @none is only used for indexing, not lists.

[] is a JSON syntax. rdf:nil is an RDF instance of an empty rdf:List, which could be serialized in JSON-LD to [].

Issue needs further clarification.

[gkellogg]

There is a @null keyword used in Framing:

@null Used in Framing when a value of null should be returned, which would otherwise be removed when Compacting.

As [] has special meaning in a frame, if you wanted hasValue to reference an empty list, the idiomatic way to do that would be "hasValue": {"@list": []}.

The spec (framing) is clear on the definition of @null and it bears no relation to rdf:nil; the JSON-LD syntax, compacted or expanded, as appropriate, is used for all list representations.

I believe there's nothing to do on this issue, and it can be closed with at most a mention in a best practices document.

[azaroth42]

On WG call of 2018-10-12, we resolved to close the issue without further change.

In particular, we do not process rdf terms with any more precedence than other ontologies. Witness the processing differences for rdf:type and @type. As such [] and rdf:nil is not in scope for managing.