Clarify sets and lists

[gkellogg]

From Peter Patel-Schneider:

• no idea of what an array of sets or lists is
• no link from array property values to 4.9
• no idea of how to handle @set or @list values

[gkellogg]

Arrays of sets are allowed as a way of providing meaning to legal JSON constructs. It's not called out explicitly within the syntax document. When converted to RDF, the arrays are effectively flattened, making them all objects of the same subject and predicate.

Lists of lists is specifically not supported, and there's an API exception LISTS_OF_LISTS_DETECTED when this is encountered through various API methods. There are also tests which test for this, although we probably need more coverage.

We should probably describe the interpretation within the syntax document, and explicitly defer to the API for interpretation.

We might consider flattening arrays of arrays interpreted as @set during expansion, which matches the RDF data model.

[niklasl]

It may make sense to rename @set to @multiple, and not allow it in the body of a JSON-LD document.

[lanthaler]

-1 to renaming @set to @multiple as it suggest that without that, only a single value can be attached to a property.

[msporny]

Spoke with Ivan about this - he thinks we should remove @set - I agree, it's unnecessary.

[niklasl]

Entirely? That would remove the ability to make predictable compact JSON, so -1. Unless compaction always put values in arrays.

[niklasl]

There may be other ways do declare how to compact single values though. Perhaps "@container": true? Or instead, if the default behavior is changed to always use arrays, the use of "@container": false could force "shrinking" of arrays with one value into just the value.

I would actually value the ability to use that directly in the context (i.e. outside of term definitions), to set the default behavior. I've come across both kinds of situations: certain contexts are full of multiple values for the majority of the terms (e.g. bibliographical data), whereas others have been almost void of such. Most of them have at least a couple of "functional properties" though, which are never repeated. But I don't think there's a general way to determine which is the more common.

What I do know is that the consumption of JSON where you don't know if the value for a specific term will be an array or not is very costly, both in JS in general (given that typeof [] === 'object') and in many template languages.

[lanthaler]

We have a compactArrays flag but that works globally, i.e., it affects all values. That being said, I share Niklas' concerns and am -1 on this for the same reasons.

[msporny]

Ah, I forgot about this technical use case for @set - so, removing it comes at a cost. /cc @iherman

PROPOSAL 1: Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form.

PROPOSAL 2: Remove the @set keyword, as we have a compactArrays flag that allows the developer to specify that they always want property values to be placed into arrays.

[msporny]

PROPOSAL 1: +0.5
PROPOSAL 2: +1

[lanthaler]

PROPOSAL 1: +1
PROPOSAL 2: -0.9

[niklasl]

PROPOSAL 1: +1
PROPOSAL 2: -1

[cygri]

PROPOSAL 1: +1
PROPOSAL 2: -0.1 (not a fan of algorithm flags in general)

[gkellogg]

PROPOSAL 1: +1
PROPOSAL 2: -1

[tidoust]

PROPOSAL 1: +1
PROPOSAL 2: -1

[lanthaler]

RESOLVED: Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form. For the avoidance of doubt, @set is allowed in the body of a JSON-LD document and the spec should explain it's use within the @context and the body of the document.