Support for @set coercion about json-ld.org

[niklasl]

I very much support this! Even without frames I have many cases where I need to specify that values for certain terms always comes in multiples (also acknowledged by demands from users of our service). This makes the shape of the data predictable. This means that I want this to be supported in any JSON-LD context, not just in frames.

On the mailing list we discussed that @container may be a better name than @structure though. Also we concluded that if this were to be, we should change the current method of specifying that a term yields an RDF list (using "@list": true) to use this form as well, i.e.: by saying"@container": "@list"`.

(It may also be interesting to compare this to the mechanics of the proposed microdata vocabulary registry structure.)

[lanthaler]

This is related to issue #60

[lanthaler]

Just as in issue #60 I think an extensible @attribute could do the job.

[msporny]

I think we should switch the "@list": true syntax to "@container": "@list". However, I don't think we need to put the feature proposed by Josh in there during this iteration of the spec. It is a useful in this particular case, but I'm uncertain how often it will be used by people. That is, I don't know if the added complexity to the spec is worth it based on the number of people that might use the feature. If we have to, we can always add the feature in later. However, if we add the feature in now and it isn't used, then we will never be able to get rid of it.

So,

+1 for "@container": "@list".
-1 for "@container": "@list" doing anything special in frames for now

[msporny]

PROPOSAL: Adopt "@container": "@list" syntax to specify type coercion to an ordered list when used in the @context.

PROPOSAL: Do not support "@container": "@set" at present, but ensure that it's use isn't prevented in the future.

[niklasl]

+1 for "@container": "@list".
+1 for "@container": "@set" (that is for full support, since I use it a lot).

One caveat is that this mechanism should perhaps also affect the "indentity" of a term. That is, just as different coercion values in @type differentiates two terms with the same value for @id, it might be proper to also take any value of @container into account (so that you can use e.g. creator and creators as different terms). Either that, or that we clearly state that this is not the case (since it might otherwise be expected).

(Note that this point brings to mind the alternate suggestion of folding the @container declaration into the @type declaration, e.g. like "@type": {"@list": "@id"}. I'm not convinced that that would be simpler though. Nor that it supports the general case, i.e. where you declare the container but don't use any "scalar" type coercion. So I'm still in favor of @container.)

[lanthaler]

Stupid question, but what's the advantage of having a separate @container instead of putting that @list or @set keyword into @type? Since it is an @-keyword it's handled differently anyways.. So I would still prefer the following syntax:

{
"@context": {
"property1": { "@id": "something1", "@type": "@list" },
"property2": { "@id": "something2", "@type": [ "@list", "xsd:date" ] }
}
...
}

[niklasl]

It is true that @list and @set being special keywords removes the strict necessity of @container. The remaining question is then whether a flat structure with @container is preferred over either "@type": ["@list", "xsd:date"] (type list) or, perhaps better, "@type": {"@list": "xsd:date"} (type object).

I wouldn't oppose the "type object" form. It's mostly about perceived simplicity (and/or style), since logically the three forms are equal. (Apart from the "identity" of a term, which seems better solved by the latter two.)

Note though that the latter forms would have to define what conflict resolution takes place if somebody uses both @list and (e.g.) @set in the same @type value. (I'd say it's either an error or that there is some precedence order.)

[jmandel]

Being able to provide consistently structured data (despite cardinality that varies across instances) is important to me -- from my perspective @container: { "@set" } in a context and @type: { ["@set", ...] } in the data are both okay.

(Of course -- getting unavoidably meta here -- if the @type convention is adopted, I'd want a way to ensure that @type itself is always represented as a set, so I don't always have to check if an element's @type is a single element or an array. Was this parenthetical at all clear? Because it's important.)

[lanthaler]

What exactly do you mean by

I'd want a way to ensure that @type itself is ALWAYS represented as a set

Does the always there would mean that documents that don't use an array are completely valid or does it just mean that the result of expansion, compaction (?), normalization and framing always use @type as an array?

[jmandel]

It means I'd want a way to specify that, when normalizing or framing a document, @type should always appear as an array. (By default, @type is an array only when 2 or more types are present for a given element. After all, the reason I raised issue 44 is to avoid a situation where a property I consider 'multiple cardinality' is inconsistently enclosed in arrays within a given payload.)

[lanthaler]

IMO it would make sense in normalization but not in framing (you specify the frame so you would also know the result). We might just want to specify that no such "optimizations" occur when framing.

[lanthaler]

RESOLVED: Adopt the "@container": "@set" syntax when used in a JSON-LD context to specify that a term is associated with a set of values.
(we clarified that at this point this is merely annotational - i.e. introduces the @set keyword)

[lanthaler]

RESOLVED: When the "@container": "@set" syntax is used in a JSON-LD context for a term definition within the framing algorithm, the resulting term will be associated with a JSON array.