W3C home > Mailing lists > Public > public-rdf-comments@w3.org > May 2012

Re: JSON-LD Syntax request for FPWD via RDF WG

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 22 May 2012 15:32:38 -0400
Message-ID: <4FBBE9D6.50302@digitalbazaar.com>
To: RDF WG Comments <public-rdf-comments@w3.org>
CC: Linked JSON <public-linked-json@w3.org>
On 05/22/12 09:53, Richard Cyganiak wrote:
>>> * Given a JSON-LD document, how do I get an RDF graph from it?
>> The answer is that this is a bit hidden in the document though, 
>> when reading it, the conversion is fairly clear. But I agree is it
>>  not explicit. Manu, it may be worth having a separate section that
>>  makes that mapping absolutely explicit and formal.
> This should be a normative section. The current spec doesn't 
> normatively reference RDF.

Nor should it... the JSON-LD Syntax document has more to do with JSON
and Linked Data than it does with RDF. Unless somebody can make a very
solid argument for why people need to understand RDF before they can use
JSON-LD, I don't think we should put any normative links to the RDF
specification in the JSON-LD Syntax specification.

That said, the JSON-LD API does need to have a normative link to the RDF
spec because of the toRDF() and fromRDF() API calls. That normative
reference is already in the JSON-LD API.

> I think it would be great to:
> 1. document how to serialize an RDF graph, given a pre-defined 
> context

If we do this, it should be done in the JSON-LD API specification. We
should barely mention RDF in the JSON-LD Syntax document - RDF is not
the focus of that document.

> 2. document how to serialize an RDF graph without a context

This is sort-of covered here:


Would you want more to be said about this in the JSON-LD API spec?

> In both cases, the more predictable the output, the better.

This is what JSON-LD Framing is for - creating a developer-requested
layout for the data such that you can write code against a known data


> This predictability is absolutely important. Without predictability, 
> it would be the RDF/XML train wreck all over again, where you end up
>  with something that isn't a good RDF serialization (because it hides
>  the triples) and isn't a good XML format either (because there's a 
> myriad ways of saying the same thing with different XML, so you can't
> use XML tools).


> For the second case, I guess there would be bonus points for making 
> the triples really obvious, even if it makes the JSON ugly. If you 
> want pretty JSON, provide a context.

There are two options for getting a deterministic data structure out of

1. Framed output - where you specify the exact JSON data structure you
want and the JSON-LD document is "re-framed" to match that data
structure. To see this in action, go here:
http://json-ld.org/playground/ and click on the "Library" example button
and then on the "Framed" tab at the bottom. You will see the input
document on the left, the frame on the right, and the output below.

2. Normalized output - where the entire graph is flattened into regular
structure, bnodes are deterministically named, and all output is
deterministically sorted (even in the face of graph isomorphisms). This
form is useful for doing things like graph diff'ing, digital signatures,
etc. To see this in action, go here: http://json-ld.org/playground/ and
click on any of the examples. Then click on the N-Quads tab (the
colorization is a bit off right now, but we're working on it.

> JSON-LD may already do all these things, but I find it hard to tell 
> from the spec

We may need a section in the JSON-LD Primer that explains how JSON-LD
documents can be massaged using the JSON-LD API. That would probably be
the best introduction to how all of this stuff is supposed to work together.

> it apparently tries hard to avoid any association with RDF.

Yep, by design. :)

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
Received on Tuesday, 22 May 2012 19:33:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:53 UTC