RE: Clarification of @set and expansion

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

Good.. maybe we could briefly discuss that at the beginning of tomorrow's
telecon to see if everyone else agrees as well.


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

Do you think so? I'm not sure yet what to think.. on one hand it surely
makes processing more complicated as there are more cases to handle, on the
other hand it would allow some constructs to be much more terse and
concise.. but of course that can be achieved as well by leveraging the
context.
So I'm probably more inclined to agree with you than proposing to allow
arrays for @value. In any case, we should add a note to the spec though to
explicitly define it.


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

I'm not really sure either what the use case is. I always thought of
expansion as a way of creating a explicit, self-contained representation of
a document. An alternative would be to use the expanded from but instead of
converting numbers to strings we'll leave the value of @value as number. So
something like

{
  ...
   "term4": [ {
     "@value": 4     <---  it's still a number --
     "@type": "xsd:integer"
    } ]
}


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

I'm arguing for consistency, either expand everything (numbers, strings,
booleans) or nothing.


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

Thanks. OK, good to know.. Was also wondering if the reviews by Oracle and
W3C would be worth mentioning. Maybe you could post them to the mailing
list.



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 19 March 2012 10:42:07 UTC