Raw

A bit of background for a question I've put to SemanticOverflow (soon to be moving to semanticweb.com) -

Has anyone got a triplestore to interop with node.js?

(It's evented I/O for V8 JavaScript, looks nifty kit for HTTP stuff).

Given that V8 runs native, I'm guessing it should be possible to hook into Redland somehow (but I wouldn't know where to start). Alternately, I suppose one of the Javascript RDF engines could work, but I'm out of touch with what's available.

SPARQL would be nice to have...

node.js floated into my consciousness again after seeing mention of @sh1mmer's new video on the subject. This time around I got around to installing it - it was pretty easy to get the example server script running (error first time, but rather than disabling SSL as suggested in the docs I just apt-get installed openssl-dev etc. and that did the trick).

On and off I've been playing with the idea of using an agent metaphor for (Semantic Web) services. I did a bunch of slides for the Scripting for the Semantic Web 2007 meetup, which I've just managed to dig out again: Two Webs!. Here's what a generalised agent looks like (slide 47):

Pretty much any semweb service can be viewed this way, and if you degenerate it a bit by dropping the RDF store and HTTP client it covers pretty much any Web app/service/site. Drop the RDF and server (and add a view) and you've got a browser. But I reckon the fun should start when you go in the other direction, starting with this as a general architecture for the app, plugging in whatever bit of functionality you like. I like the idea of such things being quite small, and to add to the agility, use a scripting language for the behaviour, so it looks something like this (slide 48):

The pseudocode here is for a simple doc server (e.g. if the query was done with SPARQL, format done with XSLT), but a key piece to note is the call to another datasource if the query can't be fulfilled locally. It occurred to me that if you had a little framework for agents like these, they could communicate with each other over HTTP (as they would in the wild) although if they knew they were in the same VM then more direct programmatic comms could take place. In between direct and HTTP calls other protocols could also be available, e.g. XMPP, with negotiation used to choose the most suitable wire. But I think it would be important to always (MUST) have HTTP support.(I've been playing with this stuff a bit using Scala Actors, no results to show yet).

So...given how nifty node.js is for doing the HTTP client/server bits, it would be nice to get the RDF bits in there too. Given that node.js/V8 runs natively, one option would be a native RDF store like Redland. I'm not sure, but I think you'd have to wrap the Redland functions up quite a bit in V8's C++ to make them accessible through Javascript in V8 (and I'm not volunteering - it's years since I did any C, and I never got the hang of C++).

If there was a decent Javascript RDF engine, that would also be a good alternative - V8 compiles Javascript, so the result should be pretty performant. (Hmm, whatever happened to the RDF store in Tabulator?).

In the first instance I'm thinking here of running such agents server-side (slide 30 is "Tyranny of the Browser" in Gothic Black Letter - we've got used to such a narrow view of what the Web can do), though as a browser can supply the VM for V8, similar stuff could run there too.

Anyhow, there are already a couple of interesting answers to my question, comments over there please, or alternatelyI installed phpBB the other day to use in the near future for some support stuff - feel free to use that for comments or whatever.