@type as @container:@set?

[azaroth42]

The purpose of the @container:@set functionality (AFAIU) is to ensure that the output is consistent in shape. Thus if there can ever be multiple values, the structure is always an array.

There are two situations in which this functionality could be desirable but is currently not possible:

1. @type As it's a keyword, we can only alias it (e.g. as type) but not define it to have @container:@set functionality. Meaning that there's a gotcha waiting to happen for ontologies that require or use multiple classes for a single resource instance. See playground
2. @context Less useful, but @context will also compact to a single string/object when there might be multiple contexts. See playground

@context modifying itself seems particularly strange, but the inconsistency for @type seems solvable if the restrictions in its definition were loosened?

[davidlehn]

@gkellogg Any thoughts about this going into 1.1? I think the @type part could be worth supporting. Not sure about the @context part but may be worth looking at.

[gkellogg]

There is a provision in 3.3 of the Compaction Algorithm to make sure that values retain their array form if the container mapping includes @list or @set, which would come into affect when container mapping is ["@type", "@set"], so the Compaction Algorithm does ensure that values are always represented as an array in this case:

3.3) If result contains only one item (it has a length of 1), active property is not @graph or @set, or the container mapping for active property in active context does not include @list or @set, and compactArrays is true, set result to its only item.

However, there is a missing paragraph in the Syntax document, which is present for other uses, for example:

The value of @container can also be an array containing both @id and @set. When compacting, this ensures that a JSON-LD Processor will use the array form for all values of node identifiers.

We should add a similar paragraph for @type.

[azaroth42]

The question to me is that as @type is a keyword, and cannot be redefined only aliased (per https://www.w3.org/TR/json-ld/#aliasing-keywords), is it legal for a context to define it, or an alias, as a set? The form does fit into the definition of the keyword, of course (https://www.w3.org/TR/json-ld/#node-objects), but there might be further knock on effects of having to process context specific definitions of @type?

[gkellogg]

I was confusing this issue with container on other properties.
If you mean something like the following:

{
  "@context": {"@type": {"@container": "@set"}}
}

Then no, this has not been addressed yet.

[azaroth42]

Yep, exactly that to ensure the consistency of the JSON representation for @type, rather than type checking if it's an array or string. It's not the end of the world, it's just an exception to learn, especially when @type is aliased away to something else.

[Personally, I think best practice is to have exactly one type, and multiple instantiation is to be avoided like the plague ... but it's a feature of RDF that some systems do support]

[niklasl]

We did add @container: @set for this need in general, so it would be nice to support this for @type as well. Consistency in the use of arrays are more or less necessary in some contexts (say if using compact JSON-LD with a statically typed O/R-mapper). When using the JSON-support in Postgres, although it doesn't break on this variance, searches based on type become more cumbersome.

[gkellogg]

Transfered to WG.