Consider the inverse of @container:@set?

[azaroth42]

We should consider whether or not the opposite of @container:@set is sufficiently valuable to include. This would be when there is exactly one entry in an @list, instead of compacting to an array, compact to a single item.

It is valid as input already (http://tinyurl.com/yccbfl9j) but compaction will always create the JSON array.

The context might say:

{
  "listy": {"@id": "eg:steps", "@container": ["@list", "@single-item-is-value"]}
}

For example, the schema.org recipeInstructions for a single step could just be a string, not an array containing a string. Such as this very simple guacamole https://www.allrecipes.com/recipe/14231/guacamole/ could be compacted to:

"recipeInstructions": "In a medium bowl, mash together the avocados, lime juice, ..."

even if recipeInstructions was an @list.

(/ht @danbri)

[gkellogg]

I don't really see this, given that it's a list, an array seems to be implied to me. I'd hate to add another keyword, too. All this to make compaction less normalized. As you note, it's legal input.

[azaroth42]

Expanding the discussion to include the parsing side than just the serialization, if the intent is that the predicate should take either a string or an rdf:List as the range and the parser should respect that internally.

Discussion on 2018-05-07 call:

• Clarify exact requirements in WG with @danbri.
• Shouldn't be opinionated at the format level as to whether the data /should/ be a single item array or just a single value, but allow the context designer to be specific.
• All other RDF syntaxes can express a predicate that sometimes has an rdf:List and sometimes has a single value.

[gkellogg]

Closed in favor of https://github.com/w3c/json-ld-syntax/issues/17.