Permission to break feature freeze for Nepomuk and Soprano

[Richard Dale]

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 [1]. 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.)
>
> Cheers,
> Sebastian
>
> [1] 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.

-- Richard