finally a bnode with a uri

Posts tagged with: jsonp

JSONC, JSONI, JSONP: Creating tailored JSON from SPARQL query results

Returning SPARQL results as optimized JSON string
Update (2006-02-05): Elias Torres sent me a pointer to a draft of a related tech note he is working on with other DAWG members. I've adjusted my serialiser, so that its output is closer to their proposal now. After testing the different serialisation options, I've also updated the JSONI format. The examples below show the changes already.

My current sparqlet (SPARQL-driven portlet) implementations mostly use queries generated server-side, the results are returned as application-specific JavaScript. While this approach allows certain bandwidth and convenience optimisations, it always needs custom code on the server.

For generic operations, SPARQL endpoints offer an XML format which can be consumed by in-browser applications via XHR techniques. However, the SPARQL result XML format makes things quite bloated, and what I learned from Web 2.0 coders is that JSON results are often preferred.

It's rather straightforward to generate JSON code equivalent to the XML structure. I know that several people are working on this, but I couldn't find any public versions. I hope my ARC stuff isn't too different, but I can easily tweak it later. Here is a sample of a default SPARQL JSON result returned from an ARC server:
SELECT DISTINCT ?s ?p ?o
WHERE { ?s ?p ?o }
LIMIT 20
{
 head: {
  vars: ["s", "p", "o"]
 },
 results: {
  distinct: true,
  ordered: false,
  compact: false,
  indexed: false,
  bindings: [
   {
    s: {
     type: "bnode",
     value: "b2490b2520bf2872200093194ff36f465_id2245308"
    },
    p: {
     type: "uri",
     value: "http://xmlns.com/foaf/0.1/weblog"
    },
    o: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/"
    }
   },
   {
    s: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/"
    },
    p: {
     type: "uri",
     value: "http://www.w3.org/2000/01/rdf-schema#seeAlso"
    },
    o: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/wp-rdf.php?cat=9"
    }
   },
     ...

  ]
 }
}  
(I'm using associative arrays for the bindings in order to reduce bandwidth a bit. Didn't put too much work into this default serialisation, it's probably going to change when there is a recommended format available.)

However, like the XML result, this JSON alternative is not the most efficient when a consuming app doesn't need the typing info of the individual bindings (uri/bnode/literal). I played around with some pre-defined "compact" JSON formats, but looking at the queries I'm using in my stuff, there are often cases, where I want the typing info for one or two of the bindings, but not for the rest. The solution I implemented for the ARC RDF Store looks like this: The user can specify an optional jsonc argument which defines whether a binding should be serialised entirely or if it can be flattened:
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT DISTINCT ?p1 ?p1_name ?p2_name ?p2_mbox_sha1 WHERE { ?p1 foaf:name ?p1_name ; foaf:knows ?p2 . ?p2 foaf:name ?p2_name ; foaf:mbox_sha1sum ?p2_mbox_sha1 . } ORDER BY ?p1_name LIMIT 30
jsonc="p1(),p1_name,p2_name,p2_mbox_sha1";
{
 head: {
  variables: ["p1", "p1_name", "p2_name", "p2_mbox_sha1"]
 },
 results: {
  distinct: true,
  ordered: true,
  compact: true,
  indexed: false,
  bindings: [
   {
    p1: {
     type: "bnode",
     value: "b2e9ddd5ebb264646b852dcd207e13d8a_bn1"
    },
    p1_name: "Jim Ley",
    p2_name: "Jeremiah McElroy",
    p2_mbox_sha1: "f0d988b33153f21479cffa647cbe6faac65a98f8"
   },
   {
    p1: {
     type: "bnode",
     value: "b2e9ddd5ebb264646b852dcd207e13d8a_bn1"
    },
    p1_name: "Jim Ley",
    p2_name: "Mart Sanderson",
    p2_mbox_sha1: "ce3165ecf98cdb6d8153503949b320e24a6138a0"
   },
   ...
 ]
Appending parentheses to a result variable activates the complete serialisation, the other vars will be flattened. The jsonc parameter can also be used to remove selected result variables from the returned JSON. This may be helpful in in cases when they were needed to retrieve the SPARQL result set (e.g. in combination with DISTINCT), but aren't actually used in the client app.

JSONC can help reduce bandwidth and browser memory consumption, but it doesn't really add too much to the front-end developer's convenience. The RDF model is graph-based and resource-oriented, but SPARQL results are tabular with usually a lot of repeated values. Therefore a developer has to process the code before resource-centric views can be displayed. What's missing (if we want to avoid custom, server-side code or heavy pre-processing on the client) is a way to tell the SPARQL endpoint to arrange and index the tabular results before they are serialised as JSON: JSONI. The jsoni parameter works similar to the jsonc one, but it allows nesting of result vars to specify index structures:
jsoni="p1_name(p2_name)";
[codeblock { head: { variables: ["p1_name"] }, results: { distinct: true, ordered: true, compact: false, indexed: true, index: { p1_name: [ { value: "Jim Ley", type: "literal", index: { knows: [ "Jeremiah McElroy", "Mart Sanderson" ] } }, { value: "Leandro Mariano L

Archives/Search

YYYY or YYYY/MM
No Posts found

Feeds