RE: Multiple graphs syntax (ISSUE-68)

> Certainly, JSON-LD can be used as a simple dump format, similar to N-
> Triples, where everything is expanded. In my case of serializing RDF to
> JSON-LD, and where I think Ivan is coming from, is that it would be
> good to have a nice "out of the box" experience, similar to what you
> can get with Turtle, without resorting to compaction. My own
> implementation makes use of provided prefix definitions along with an
> RDF graph to do a best-effort in creating a readable JSON-LD document,
> construction the @context on the fly. IMO, this is a perfectly
> legitimate use of JSON-LD as a serialization format. Restricting JSON-
> LD to operate only on graphs with a single root seems like an
> unnecessary restriction. Requiring that the context be repeated for
> each root also seems needlessly complicated.

OK, I see the need for this


> It's really just a matter of describing what the value of an array is
> when used with @id. In the top-level case, it is not the value of
> anything, so there is no issue, the issue is when it is used as the
> value of a property, for which I don't see any reasonable use case, and
> so think that defining the value as being the last value of the array
> solves the issue.

Well, the thing that I don't like is that the form

  @id: [ { @id }, { @id } ]

looks extremely weird. I wouldn't know how to explain that construct to
someone without an RDF background.. How would you?

The way JSON developers usually handle this is (and they just have to do it
if they want to be sure that a document is always an object at the
top-level) is to introduce a root node like Ivan's @data. But since we
create a general approach, there are certain corner cases to address [1].



[1] http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0086.html

Received on Wednesday, 1 February 2012 03:12:25 UTC