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

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

From: Richard Cyganiak <richard.cyganiak@deri.org>
Date: Tue, 22 May 2012 18:42:24 +0100
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
Message-Id: <8BD6EA86-E90C-4A57-A5A6-6ECAE7C8F101@deri.org>
To: Gregg Kellogg <gregg@greggkellogg.net>
Hi Gregg,

On 22 May 2012, at 17:54, Gregg Kellogg wrote:
> As Markus noted, at this point, it's only the Syntax spec that we're submitting. The API spec could potentially be done in a different group, when the time comes.

I feel about this like Ivan. There is a line about producing a JSON syntax for RDF in the RDF-WG charter. The JSON-LD syntax spec, on its own, is not sufficient to be called a JSON syntax for RDF. I'm sure you see the problem with saying that the missing piece (to- and from-RDF algorithms) will be delivered by some other WG at some future date.

> The use of terms such as _Statement_ closely follows the RDF Interfaces spec [3] (Triple renamed to Statement), which has been dormant.

If they were not dormant, I'd have a word with them. Still, this document is quite a bit closer to RDF Concepts than the JSON-LD API document.

> I think it's reasonable that these terms echo definitions in RDF Concepts, but note that a Statement may be either a triple or a quad; triple seems too narrow for this. I don't believe the concepts doc discusses triples with a context.

It doesn't yet, but it will. (This is the “RDF dataset”/“named graphs” stuff consumes 75% of this WG's traffic.) Opinions differ on whether we want quads. Personally I'm opposed, and prefer a view where we have multiple graphs, each made up of triples, that are associated with a IRI (graph name), like SPARQL's RDF datasets. This is what's currently in the RDF 1.1 Concepts Editor's Draft, but it will still go through some iterations:
http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-multigraph

Are there specific use cases that you have considered in order to design the quads/context feature of JSON-LD? We might want to add them to our list of use cases for the multigraph stuff.

> For the context of the RDF WG, we could create a separate document describing the normative requirements for RDF transformations; we intentionally kept the discussion of RDF to a minimum in the Syntax document.

Just speaking for myself, and without having considered the issue deeply, I'd prefer having everything that is required to convert between JSON-LD and an RDF graph in a single document.

> JSON-LD can pretty fully represent everything that can be represented in TriG, with the exception of lists containing other lists.

Cool.

>>> 2. Examples would be great.
>> 
>> There are a couple of example in the syntax spec [2], don't know if you
>> already saw them.
> 
> A good source of examples is the Test Suite [4], [5]. We should probably create links from the test suite to each individual test and result, to make them easier to access.

JSON-LD is all about linked data, right? So I'd expect to see hyperlinks (that is, full URLs) in [4] and [5].

> The fact that manifests are all represented using JSON should make this a fairly easy thing to do within the HTML page itself, perhaps using the <script type="application/ld+json"> similar to that used in the Turtle spec.

Sounds useful.

Thanks,
Richard



> 
> Gregg
> 
>>> 3. Is it possible to serialize an RDF graph into a "pretty" JSON-LD
>>> document using a context? I presume the answer is "yes" and involves
>>> Compaction of the basic serialized output.
>> 
>> Yes, exactly either by compacting or by framing.
>> 
>> 
>> [1] https://github.com/json-ld/json-ld.org/issues/125
>> [2] http://json-ld.org/spec/latest/json-ld-syntax/#markup-examples
> [3] http://www.w3.org/TR/2011/WD-rdf-interfaces-20110510/
> [4] http://json-ld.org/test-suite/tests/fromRdf-manifest.jsonld
> [5] http://json-ld.org/test-suite/tests/toRdf-manifest.jsonld
> 
>> --
>> Markus Lanthaler
>> @markuslanthaler
>> 
>> 
>> 
>> 
>> 
> 
> 
Received on Tuesday, 22 May 2012 17:43:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 17:43:20 GMT