Re: Clarification of @set and expansion

On 03/18/2012 10:08 AM, Markus Lanthaler wrote:
> I went through the resolved issues and tried to update the specs
> accordingly.

Great! Thanks for doing that, Markus. Much appreciated.

> 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.

I agree.

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

I don't think we should allow this. The same goes for "@container":
"@list". That, or we should allow value to be an array if either
"@container": "@set" or "@container": "@list" is specified. We should be
consistent, and I don't think we should over-complicate @value.

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

I don't think we should do that as it makes @value a bit more difficult
to understand.

> 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" }
>    ]
> }

Yes, I believe this is correct... minor notes below.

> Same question as above, can the value of @value be an array?

No, I think that would make @value more complicated than we want it to be.

> Shouldn't strings also be converted to the expanded form (term1 and term2)?

Good question, I'd say no... but then we're being inconsistent with how
we treat strings and numbers. Maybe expanded form shouldn't expand
numbers either? It all boils down to what we expect people to do with
expanded form. We had been using it internally for achieving compaction.
Now, it seems as if we have a different use case for it, but it's not
clear to me what that use case is...

> 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.

I don't know if you're arguing for inconsistency here (which is fine) or
consistency (which is also fine).

> By the way, my JSON-LD paper got accepted for the WS-REST workshop at the
> WWW 2012 conference.

Congratulations! You should chat with Gregg Kellogg as he has put
together some presentation materials on JSON-LD as well.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Monday, 19 March 2012 02:26:08 UTC