W3C home > Mailing lists > Public > public-openannotation@w3.org > July 2013

RE: Framing and @graph

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 31 Jul 2013 22:41:34 +0200
To: "'Robert Sanderson'" <azaroth42@gmail.com>, "'Linked JSON'" <public-linked-json@w3.org>, "'public-openannotation'" <public-openannotation@w3.org>
Message-ID: <004501ce8e2e$59c07cf0$0d4176d0$@lanthaler@gmx.net>
Hi Robert

On Wednesday, July 31, 2013 9:45 PM, Robert Sanderson wrote:
> Dear lists,
> We've been looking at framing as a method to easily arrive at a json
> developer friendly serialization for Open Annotation, and other
> projects, from a set of triples.
> In Open Annotation, currently, we do not push for the use of @graph in
> the serialization, and in fact don't even mention it [1].  However
> framing seems to always insert the @graph keyword when it wasn't
> present before [2].  This means that either every client needs to know
> that it should look inside @graph or at the top level for the
> annotation, or we could simply specify that @graph must be present for
> consistency.

Right, framing always returns an object with an @graph at the top-level to
ensure that results always have a deterministic shape.

> The issue that I (at least) have with this is that the JSON-LD docs
> bury @graph in a "Named Graph" section rather than being up front and
> saying that you need to worry about it all the time, even if you don't
> have a named graph.

I don't see this as a problem. You are reading a JSON-LD document so you
have to expect every keyword unless you have some out-of-band contract with
the publisher which allows you to rely on a specific structure.

> Or am I missing an option that allows @graph to be omitted?

You could compact the framed result. That would eliminate the @graph if
there's a single item in that array. If there are multiple items, @graph
would be preserved. The reason for this behavior is that developers
typically prefer an object at the top-level and not an array. Furthermore,
it allows us to include the context just once instead of having to add it to
every item.

> Equally,
> not naming blank nodes would also be another nice output option,
> rather than generating explicit bnode names?  Or ... am I missing the
> point of framing entirely? :)

That's a side effect of how the algorithm works. Internally the whole
document is flattened and indexed by @id and thus every node needs to have
an identifier.

Please keep in mind that framing (unfortunately) isn't part of JSON-LD 1.0.
So things may change a lot in the future.

> (Also many thanks for the work on the list issue!)

You are welcome,

Markus Lanthaler
Received on Wednesday, 31 July 2013 20:42:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 31 July 2013 20:42:05 UTC