rdf | Danny Ayers' Other Alternate Weblog

As a bit of variety from working on the server side of Seki I’ve been looking at a bit of client code. One thing I want to be able to do is create outlines, very much like Workflowy (I’ve been using that for a while now, very handy). It is part of a bigger picture, more on that later, but the immediate problem was to be able to make outlines in the browser and represent them in RDF.

I actually worked on something very similar nearly 10 years ago : XOW. That time around I worked with the DOM and serialised to RDF/XML using XSLT on the XHTML result.

This time I’ve been using HTML5, jQuery and Turtle. I’m pretty new to jQuery so it’s been slow progress, but I progress I have made. Still loads more UI work to do but I just tried a serialisation. Here’s the sample outline:

which on a first pass at serialisation looks like this:

@prefix dc: <http://purl.org/dc/terms/> . 
@prefix ts: <http://hyperdata.org/trellis/> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-255-0369> a ts:Node; 
 dc:title "Add priority number to each line 1-5" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-255-0000> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-261-8067> a ts:Node; 
 dc:title "Add copy and paste" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-255-0000> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-265-8865> a ts:Node; 
 dc:title "Three" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-261-8067> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-265-5134> a ts:Node; 
 dc:title "Four" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-265-8865> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-266-1939> a ts:Node; 
 dc:title "Five" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-265-8865> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-266-7852> a ts:Node; 
 dc:title "Six" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-265-8865> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-267-2310> a ts:Node; 
 dc:title "Seven" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-261-8067> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-268-9847> a ts:Node; 
 dc:title "Eight" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-261-8067> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-268-7935> a ts:Node; 
 dc:title "Nine" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-255-0000> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-269-7831> a ts:Node; 
 dc:title "Ten" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-268-7935> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-269-7830> a ts:Node; 
 dc:title "Eleven" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-268-7935> .
<http://hyperdata.org/nid-2013-11-06-17-46-54-269-7829> a ts:Node; 
 dc:title "Twelve" ; 
 ts:parent <http://hyperdata.org/nid-2013-11-06-17-46-54-268-7935> .

Hmm. So how do I check it, being lazy? Ran it through a Turtle-RDF/XML converter/validator, then into the W3C’s validator to get a visual.

Hmm. Guess I’ll check the Turtle after all.

It’s easy to see why people might get put off RDF, it does look pretty monstrous. But to get the same addressability e.g. using JSON would need pretty much an identical level of complexity, without the potentially for reusability without building from scratch.

Whatever, I haven’t yet decided on how ultimately I’ll do comms with the server. Workflowy appears to poll for changes then pushes diffs as JSON over a POST. I might well end up doing that too (though more likely as JSON-LD, or perhaps even RDFa) but did need to sort out the RDF representation.

tl;dr : three steps forward, two steps back

What?

Seki is my current pet project, a work-in-progress. Depending on perspective and level of optimism it’s either a node.js replacement for my previous blogging engine, a piece of Linked Data middleware or a Semantic Web application framework. The one possibly novel aspect is that it uses a potentially remote SPARQL store (yes, being able to address multiple stores is also on the list). Very loosely-coupled. My immediate priority app-wise is for it to work as a basic CMS (i.e. read/write content, user auth & management etc.).

Recently…

I’ve spent a fair bit of time coding on it in recent weeks, but on the surface there’s absolutely nothing to show for that. The main issue was it turning into spaghetti code, so I’ve been trying to rationalize the architecture.

Nest of Vipers

The cause of this was that one of the requirements I’m pretty firm on is supporting a variety of (HTTP-based) interfaces. So for virtually all HTTP methods I want create/read/update/delete supported wherever possible with:

HTML (with RDFa as available) + form-encoded POSTing
JSON (JSON-LD primarily, though I may well add more ad hoc support)
Turtle
SPARQL
Text, image blobs etc.

On top of that I want to support a variety of functionality – that’ll be partitioned via parts of the URL path. Basically that means lots of variables on both the input and output.

Templates FTW

I’m sure there are alternatives, but the easiest way of handling comms with the SPARQL server seemed to be templating on queries and results. With that in place it was obvious to follow (mostly) the same approach when handling other I/O. So add template selection to the variables mix. (I’m currently using freemarker.js templates, mostly because I used them a bit around Apache Stanbol, though tempted to change to something better known around node.js like underscore templates but there’s no pressing need right now).

Rules Rule

Guess what, a multitude of clumsily interwoven IF…THENs and quite a bit of duplicate code was the net result. I had a brief look at available libs for filtering/dispatching but didn’t find really suitable. Around the same time I encountered the nools rules engine (very nice JS with rules DSL, uses a Rete engine) and couldn’t resist trying that – after all, part of my motivation here is to have fun 🙂

It did occur to me that I could use RDF+SPARQL (perhaps on a local in-memory store) for things like the routing rules – it is after all just down to pattern matching. For now though I’ll see how I get on with nools. It does require expressing the routes in a declarative form, so it shouldn’t be difficult to recycle later if need be. (I’m also intrigued by the potential of using nools as a reasoning engine over the RDF – thence shifting the declarative stuff over to RDF tooling that way).

Another justification for a rules engine is that I also need authentication & access control (I have put together a model for this I’m happy with, implementation shouldn’t be too difficult). That’s yet another layer of potentially twisty wiring.

Disentanglement

So recently I’ve mostly been refactoring/rebuilding to do the routing and template selection via rules in nools. Of necessity, to keep sight of what I’m trying to achieve, I had to start writing tests. Functional tests calling a HTTP client were needed. To simplify that I’ve concurrently started writing a bunch of helper classes – effectively a client API no less – which may well come in handy elsewhere later.

Do I sound like a proper developer yet?

So by default now I’ve pretty much shifted toward (functional) Test-Driven Development for the server-side bits (using nodeunit). Must look into something similar for the in-browser bits.

Oh yeah, plus jQuery

A secondary problem was that the UI pieces I’d been using (VIE/Create.js) were making me feel like I was committing too much to a framework that didn’t really offer me much. No crit intended for that work, it’s great stuff, only that the bits I need I can more easily build myself customised to this project (I am still using one artifact from over there, the delightfully minimal WYSIWYG Hallo.js editor).

Coming soon!

So my upcoming dev path is more-or-less:

refactor existing functionality to be rule-based
add missing CMS content handling bits (HTTP API – rules & templates for all the variables mentioned above)
implement user management (auth & access control-related rules & templates)
make UIs for all the above
docs (always in-progress, but this would be a good point to catch up)
start using it – dogfood!
make it solid enough for production release – and release properly
add quick & dirty other stuff (my potential app scenario list is long, starting with making semwebby clones of things like delicious, twitter, workflowy etc. I also want a semwebby personal project management tool asap)
refactor to make mighty pluggable
invade Poland