Permission to break feature freeze for Nepomuk and Soprano
richard_dale at tipitina.demon.co.uk
Mon Sep 3 16:53:27 BST 2007
On Monday 03 September 2007, Sebastian Trüg wrote:
> Hi guys,
> there has been a long silence around Nepomuk. Well, the main reason is that
> I was working heaviliy on Soprano2 . It comes with a bunch of new
> features, a much cleaner API, a server/client architecture (quite simple
> but waaaay faster than DBus), and I intend to replace the Nepomuk
> middleware with it. I already did it locally and a commit "should" not
> break anything once Soprano2 is copied to kdesupport.
> The main advantage of all this is: speed. No more DBus for requesting data.
> It is now done via tcp (and I would love some tips and help to add support
> for unix socket communication)
> If there are no objections until this evening I will proceed (I know it is
> short notice but I don't think it is such a big deal yet.)
>  branches/work/sorano2
I don't know about speed, but from what I've seen of the SPARQL query api it
only returns results as C++ over dbus (as a Nepomuk::RDF::QueryResultTable).
The query itself is a text string which is language independent and fine. So
the results are retrieved as xml text, marshalled to c++, then marshalled to
the dbus wire format. At the other end, the are put back into the original
c++ classes. In ruby there would be a further step where those c++ instances
would be wrapped with Ruby classes.
What I would prefer is that the query results are sent as a an xml
string 'application/sparql-results+xml' over dbus and then the client can
choose what it wants to do with it, depending on what language the client is
written in. For instance, a C++ client could convert the xml to
Nepomuk::RDF::QueryResultTable, or a ruby client could convert to the
ActiveRDF result format. Maybe there is a problem because Nepomuk needs to
return quads when named graphs are used, instead of just triples - I'm not
enough of an expert to know if using sparql/xml for the result sets would
cause problems with that.
I am keen to be able to use jabber XMPP as a transport for peer to peer SPARQL
queries between KDE users if they wanted to exchange their own meta-data in
their local triple stores, such as restaurant recommendations or whatever. So
I think Nepomuk should be as transport and language independent as possible,
and using xml as the result set format makes that easier.
More information about the kde-core-devel