Clarification of @set and expansion

[lanthaler]

Hi all,

I went through the resolved issues and tried to update the specs
accordingly. I wasn't 100% sure what to do with @set so I thought it might
be better to check if have consensus on this first here.

So, let me just ask a couple of questions based on a few examples. For
instance, is the following allowed?

{
  "@context": {
    ..
  },
  "test": { "@set": [ ... ] }
}

I would say yes to keep the "symmetry" with @list.

What about

{
  "@context": {
    ..
  },
  "test": { 
    "@value": [ ... ],
    "@container": "@set"
  }
}

Is it even allowed to have an arrays as the value of @value?

The other thing I wasn't really sure about was how expansion now works in
detail. E.g., what would be the expanded version of the following document?

{
  "@id": "id1",
  "@type": "t1",
  "term1": "v1",
  "term2": { "@value": "v2", "@type": "t2" },
  "term3": { "@value": "v3", "@language": "en" },
  "term4": 4,
  "term5": [ 50, 51 ],
}

Would it be (plus IRI expansion)

{
  "@id": "id1",
  "@type": [ "t1" ],
  "term1": [ "v1" ],
  "term2": [ { "@value": "v2", "@type": "t2" } ]
  "term3": [ { "@value": "v3", "@language": "en" } ]
  "term4": [ { "@value": "4", "@type": "xsd:integer" } ]
  "term5": [
    { "@value": "50", "@type": "xsd:integer" }
    { "@value": "51", "@type": "xsd:integer" }
  ]
}

Same question as above, can the value of @value be an array?
Shouldn't strings also be converted to the expanded form (term1 and term2)?
Looking at the result above, I wouldn't be opposed to keep numbers as
numbers in the expanded form instead (term4 & term5) and leave that
automatic typing to normalization.

Originally raised on the mailing list

[lanthaler]

RESOLVED: Using @list and @set as keys in JSON-LD values that are expressed in expanded form is allowed.

RESOLVED: During compaction @set expressed in expanded form MUST be optimized away if it is not coerced to a @list. During expansion @set MUST be optimized away.

RESOLVED: The use of @container is ignored in the body of a JSON-LD document.

[lanthaler]

RESOLVED: The value of the @value key is always transformed to a string by the JSON-LD processor.

RESOLVED: Unless there are type coercion rules in the @context that apply, native JSON numbers and strings are not modified in compacted or expanded form.

[gkellogg]

More things unclear (similar to comment in #81): what about coercions between boolean, integer and double? Previously, my implementation would presume that the version specified is what's used:

boolean(1) => 1
boolean(1.1) => 1.1
boolean(true) => true
boolean("foo") => {"@value": "foo", "@type": "xsd:boolean"}
integer(1) => 1
integer(1.1) => 1.1
integer(true) => true
integer("foo") => {"@value": "foo", "@type": "xsd:integer"}

It's only for xsd:double that we made the claim about converting to string form with %1.16E.

[lanthaler]

Gregg, I close this issue. Let's create a separate one for this stuff.