Leo Sauermann wrote:
> So, I would be happy to seperate the sesame database from the XPI
> plugin, but how to do this with good performance?
Well, the only way to have good performance is to attach the rendering
system with the triple store, so that they can communicate in-process
instead of having to communicate thru a socket.
The problem with faceted browsing is that a single page requires
multiple queries to the triple store and not many of these can be
cached/pre-calculated.
So, today, Piggy Bank has two communications between the XPI part and
the java part: one is thru in-process communication and it's pretty
small, the other is thru http over a tcp/ip socket and that's where the
real browsing happens (in which we use ajax to perform a bidirectional
channel).
We have decided to go on and decouple the two parts completely, so that
communication happens only thru http *and* to allow the browser to fork
the java process into another process, hopefully a deamon.
This should completely isolate the two memory pools and make it easier
to debug and fix the memory leaking.
But understand that what we are isolating is the javascript part from
the java part, but the java part remains the same with the rendering
engine (longwell) and the triple store (sesame) sharing the same memory
space.
So, how about other triple stores?
Well, we already have the necessity of being able to communicate with
other triple stores, for example one or more semantic banks. This
communication would hopefully happen over a Sparql query over HTTP.
What I expect is some sort of RSS-like subscription service, where your
piggy bank can "subscribe" to a particular sparql query and the system
can understand, thru HTTP headers, if the content of the triple store
has changed since the last time that query was issued.
This is a very simple architecture and works very well for blogs.
Sure, there are denial-of-service security issues to consider everytime
you expose a query interface to the wild, but apart from that, I think
having a way to "deltify" the changes to a triple store would make it
finally feasible for local triple store to be efficient, distributed and
up-to-date with a minimal architectural effort.
What do you think?
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Fri Dec 16 2005 - 14:37:34 EST