Permission to break feature freeze for Nepomuk and Soprano

[Richard Dale]

On Monday 03 September 2007, Sebastian Trüg wrote:
> 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 would have thought the speed over dbus would depend more on latency than the 
quantity of data you send, but I haven't done any measurements. Is the data 
shorter than xml text when marshalled to c++ classes, and then marshalled 
over dbus - it doesn't sound like a compression scheme to me?

> > 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?
Yes, that sounds fine. As long as there is a way of getting at the SPARQL xml 
result set at the client end, I don't mind if it isn't the mainstream way of 
communicating with the server.

-- Richard