Misc Thoughts
CONSTRUCT JSON

I’ve been going on a lot about CONSTRUCT JSON for a while, trying to persuade people to implement it, at the moment it’s just a thought experiment but I think it’s at least worth blogging about…

So the idea is that it’s pretty common that you have a SPARQL store containing some interesting RDF, and you’d like to expose it to JS developers as JSON data. We’ve done this in Garlik a few times with FOAF and the like, using PHP scripts, but I think there’s an easy way to generalise it.

Imagine there was a CONSTRUCT syntax for RDF, that instead of constructing RDF graphs, constructed arrays of JSON object, one per solution, e.g.:

CONSTRUCT JSON {
  {
    "name": ?name,
    "age": ?age 
  }
} 
WHERE {
  ?x a <Person> ;
      <name> ?name ;
      <age> ?age ;
}

So, what this will do is execute the following query:

SELECT ?name ?age 
WHERE {
  ?x a <Person> ;
      <name> ?name ;
      <age> ?age ;
}

And substitute the variable bindings from each row into a JSON array, with one member per solution, e.g.:

[
    {
        "name": "Alice",
        "age": 23 
    },
    {
        "name": "Bob",
        "age": 24 
    }
]

The obvious use for this would be as a config in an HTTP server that sits between a user and a SPARQL endpoint, and does a literal transform from the CONSTRUCT JSON syntax to SPARQL, but ultimately it could be a syntax spoken directly by SPARQL endpoints.

The user would name some RESTful API request like

http://example.com/service/cat/moggy.json

The parameters (“moggy” in this case, see below) would be filled out in a JSON CONSTRUCT template, exectued, and the results returned as JSON.

The intermediary service could also implement stuff like developer API keys / OAuth / whatever else you need to make a public API on the internet, then you could just configure a service like this with some templates, point it at a SPARQL endpoint, and you have a custom JSON API, for very little effort.

I see this as sitting between things like the Linked Data API and full SPARQL in terms of capability, and ease of configuration.

Each service would require two templates, one that specifies how varaibles are parsed from a RESTful URI, and the SPARQL-ish query form like in example one, e.g.:

/service/cat/$NAME.json

PREFIX a: <http://example.com/animal#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
CONSTRUCT JSON {
  {
    "name": ?name,
    "breed": ?breed,
    "colour": ?colour
  }
}
WHERE {
   ?cat a a:Cat ;
       a:name ?name ;
       a:breed [
         rdfs:label ?breed ;
         a:colour ?colour ;
       ] .
   FILTER(REGEX(?name, $NAME, "i"))
}

Note: I’m abusing SPARQL $ variables a bit, but they’re pretty uncommon in the wild, so I think using them as parameter substitution variables in config files is fine.

There’s probably lots of corner cases to worry about, an obvious one is what to do with OPTIONALs which don’t bind. The “natural” thing is probably to omit any pair where either the key or value is unbound, but it’s probably not that simple w.r.t JSON syntax, so sending the empty string or something is probably easier.

You could also apply the same idea to XML, or whatever else, but JSON is more useful to people writing javascript apps.

Just as a quick addendum, incase anyone is worried, I’m not proposing to add this to SPARQL 1.1, it’s just an experiment that I’d like to encourage someone else to implement!

  1. parallax-scroll reblogged this from steveharris
  2. szlafroki reblogged this from steveharris
  3. prawnik-warszawa reblogged this from steveharris
  4. pozycjonowanie-czestochowa reblogged this from steveharris
  5. dagoneye reblogged this from steveharris
  6. steveharris posted this