TriplesInJSON

From W3C Wiki
Revision as of 13:44, 2 September 2011 by Dayers2 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

Here is a RDF-in-JSON format aiming at the N-Triples-in-JSON space derived very directly and simply from Serializing SPARQL Query Results in JSON. (It's also an obvious candidate for SPARQL CONSTRUCT results in JSON). (JTriples is another format intended play a role like N-Triples but expressed in JSON. However this doesn't take full advantage of JSON's trivial access to structure.)

It works out about as close to the aims of N-Triples (i.e. minimal spec, easy to parse/serialize) as you can get in JSON while supporting intuitive Javascript access paths. Plus you get a serializer and parser for free.

Contact: DannyAyers

Description

Serializing SPARQL Query Results in JSON uses a fairly direct translation of the XML results format into JSON. It's very easy to derive a practical J-Triples format from it.

If we run the query:

SELECT ?s ?p ?o WHERE { ?s ?p ?o }

over an arbitrary graph, we get something like:

{
 "head": {
   "vars": [ "s" , "p" , "o" ]
 } ,
 "results": {
   "bindings": [
     {
       "s": { "type": "uri" , "value": "http://hyperdata.org/seki/Hello" } ,
       "p": { "type": "uri" , "value":
"http://purl.org/dc/elements/1.1/date" } ,
       "o": { "type": "literal" , "value": "2011-08-30T19:00Z" }
     } ,
     {
       "s": { "type": "uri" , "value": "http://hyperdata.org/seki/Hello" } ,
       "p": { "type": "uri" , "value": "http://xmlns.com/foaf/0.1/maker" } ,
       "o": { "type": "uri" , "value": "http://dannyayers.com/me#" }
     } ,
...

If we stick such a result set into a JSON/Javascript object -

var sr = // results //

it's possible to access the values through paths like -

sr.results.bindings[0].o.value

which in the above is "2011-08-30T19:00Z"

but there's stuff here that's redundant, so let:

var jt = sr.results.bindings;

effectively making jt an array of triples, so now, e.g.:

jt[0].o.value == "2011-08-30T19:00Z"
jt[0].o.type == "literal"

There's still a bit of redundancy because :

  • s.type can only be "uri" | "bnode"
  • p.type can only be "uri"
  • though o.type can be "uri" | "bnode" | "literal"

but if you wanted to serialize without using SPARQL, you could just leave the redundant pairs out.

There's also xml:lang and xsd typed literals to consider, but again those are effectively already spec'd out in SPARQL results, e.g. :

       "o": { "type": "literal" , "value": "2011-08-30T19:00Z",
"datatype": "http://www.w3.org/2001/XMLSchema#integer"}

and

       "o": { "type": "literal" , "value": "hello", "xml:lang":"en" }

The only question for which there wasn't already an answer was whether to use "s" or "subject" for the node labels. I've chosen the shorter form here on the basis that it's fewer bits and anyone using a format like this will recognize the s, p, o pattern.

Implementations

  • Parsing in Javascript (or any other language with JSON libs) is automatically supported
  • Serialization is straightforward using a SPARQL engine which supports JSON results format, as described above
  • Java/Jena model JSON serializer : description on github
  • XML SELECT results format to JSON for node.js : srx2maps (work in progress)

See Also