Remarkably straightforward (and shiny!) browser UIs for SPARQL store-based apps

I’ve spent a lot of time around SPARQL stores, a big proportion of it doing user interface bits. Usually this has involved a bunch of server-side code, templating, transformations or whatever, but recently I stumbled a way of avoiding this entirely, putting all the work client-side, in conventional browser Javascript. I doubt this is original (once you’ve seen it, it’s almost a no-brainer), but it’s so nifty I thought I’d show off my version…

Two caveats : first, if someone else is hosting the store, you may have to bug them to look at CORS to get around same origin policy issues. Second, I’m not really that experienced with jQuery etc, so chances are my code is far from optimal.

Ok, first, a screenshot :

I’ve posted this example as a gist, but it isn’t syntax-highlighting. For now at least the original is prettier in the main repo.

How it works

Ok, it’s a bog-standard HTML+CSS+Javascript page using jQuery.

The first bit of code of note is around line 20. A regular SPARQL query appears in the Javascript, with funny line endings. There are a lot of OPTIONALs in this one, my particular data may well be gappy. The line endings can be explained by Javascript’s multi-line string syntax, and line 44 : I’m logging it to console, it really speeds debugging having a general query form open next door, copy & paste from the log. Line breaks make it more readable.

Line 46 composes a URL for the query (I’m running against a Fuseki store, it likes “&output=xml”).

Oh yeah, two things to note at this point : although many stores can now supply JSON format results, I’m using the traditional XML results syntax, as you will see, that’s no major overhead.

The other thing is that this technique isn’t limited to SPARQL (GET) queries. SPARQL 1.1 Update can just as easily be done (e.g. with buttons hooked to Ajax POSTs). There’s an example here (around line 181).

Lines 48-62 aren’t app-specific, it’s just to show one of those whirly things while the data is being retrieved from the store.

Next comes getLinks(), the operational bit of the code. It does an Ajax GET on the URL created above, then processes the XML results. Depending on the store you might have to do a bit of trial & error on the headers (around line 67).

The XML results format is fairly trivial, though when I first thought about this, I expected to need a relatively full-blown XML parser. Nope, jQuery is really handy in this regard. Line 87 grabs all the <result> blocks and loops through them. Then to pull out each value,

<binding name="href">

there’s e.g. line 91 :

 $(this).find("binding[name='href']").each(function() {
href = $(this).text().trim();
It’s effectively looping through the DOM subtree, but only actually getting the one value. There may well be a neater way of doing this, but it works and isn’t likely to be a bottleneck. What’s rather nice is that you don’t need to worry about the type of the data URI/literal/bnode – you know those in advance anyway, only really interested in the text value. The trim() is needed to remove the whitespace between the elements in the XML doc.
So now you have the values of interest, it’s just a matter of sticking them into the page. In this example I’ve got it generating a HTML table row for each SPARQL <result>. The generateLinkRow() function further down should be self-explanatory. I’m accumulating those inside the results loop, then shoving the subtree produced in the HTML DOM via regular jQuery (line 122).
The rest of the code is specific to this app. Finally around line 223 you get the HTML skeleton of the page, in this case just a table (which will be populated by the stuff above).
So basically it’s potentially possible to build a full-blown app based around just a standard SPARQL store and relatively straightforward browser Javascript. 
Once I’d got one page like this working, it was really easy to do the next : tweak query, tweak HTML layout, done. What might be nice would be a little mini-app to generate code like this…
Please ping me (@danja) if you do anything with this, have any suggestions or whatever.


3 Responses

  1. It would be much shinier, and would be more elegant done in ExtJS.

    I’ll try to cobble up an example this lunch break, and post it on Farcebook.

    • wh00h00! so glad to see that ExtJS ain’t dead! Though I knew it now goes by Sencha** I had no idea how active it was in the wild. Real glad to see your comment, George!


Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment