Permission to break feature freeze for Nepomuk and Soprano

[Sebastian Trüg]

On Monday 03 September 2007 17:53:27 Richard Dale wrote:
> 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.

Well, that is history as I deprecated DBus now with SopranoServer.

> 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.

It is way too slow to use XML as default. We can add that as an optional 
feature but for everyday KDE app data shuffling we need a fast solution.

> 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.

Again this can only be an additional translation layer which is based on the 
new implementation. That should be fairly easy as Soprano has a serializer 
API. So all you need to do is:

QTextStream s;
serializer->serialize( s, model->listStatements(), 
Soprano::SERIALIZATION_XML_RDF );

or something like that. And then provide an API for that. Does that sound like 
a solution you could live with?

Cheers,
Sebastian