[Nepomuk] QtSparql vs Soprano/Nepomuk

[Richard Dale]

Hi Sebastian

On Thu, Jul 1, 2010 at 9:22 AM, Sebastian Trüg <trueg at kde.org> wrote:
> Hi Richard,
>
> it seems you are working on QtSparql which I only found now by accident.
I'm sorry I didn't make an announcement on the kde-nepomuk mailing
list about the project and the Akademy BOF.

We did discuss the issues and QtSparql at the BOF and at other times
in Akademy. I'm afraid I've only just spotted your mail to me
personally. I think it would be a good idea to have a kde-nepomuk
thread here though for the benefit of people who weren't at Akademy. I
hope you don't mind me making the discussion public.

> I have to say that I am not happy about that at all. First of all many
> parts of the lib are obviously taken from Soprano and Nepomuk - even
> many names can be traced back easily to my code.
Yes, I did make sure to look at the Soprano/Nepomuk code when
implementing QtSparql because as a free software developer I don't
believe in re-inventing the wheel. I am a fan of the Soprano/Nepomuk
code and enjoy reading it.

The chief reason for QtSparql over Soprano as a Semantic Web
foundation layer is that QtSparql is intended to be asynchronous and
very simple. Soprano is based on synchronous iterators and wouldn't be
easy to adapt to make it work in the style of QNetworkAccessManager
with slot based callbacks. Soprano has features like a DBus api that
we (the QtSparql designers), along with classes for RDF nodes and
statements, which we felt didn't belong in a foundation layer.

Where the names used in Soprano make sense, I think it makes sense to
use the same names in QtSparql. One example might be a class called
'BindingSet'. In Soprano that corresponds to all the solutions of a
query, whereas in QtSparql it was to correspond to a particular
solution in what the SPARQL spec calls a 'solution sequence'. So we
had QSparqlResult (corresponding to Soprano::BindingSet), and
QSparqlBindingSet, along with QSparqlBinding for an individual
variable value. That being said, my preference was overruled and we
now have a class called QSparqlResultRow. Maybe Soprano::BindingSet
would have been better named as Soprano::ResultSet or
Soprano::SolutionSequence, and maybe I was wrong to use 'BindingSet'
at all - I don't know. I'm sure the more public discussion we can have
the better though.

I added a proposal for a cut down version of the Nepomuk::Resource
class as a QtSparql api called 'QSparqlResource' which we decided not
to use in the end, as it was too high level and out of scope. That was
directly based on your code.

The only other things I can think of that were directly based on your
code were some of the conversions from strings to QUrls, and names of
things in general. The code for the Virtuoso ODBC driver was derived
from the Virtuoso documentation code, which you say was derived from
the Soprano code. I didn't know about that until you told me - I
looked at both the virtuoso docs and soprano implementation, along
with the QSql ODBC driver code, and tried to take the best bits of
each.

> Still no mention of
> that is anywhere in the code. But that is not the part I am unhappy
> about really.
We should make sure that you are given credit for any of your
ideas/code in the QtSparql code. I would be happy to contribute back
any improvements I might have to the Soprano code too.

> Why create a whole new system instead of trying to make
> Soprano fit your needs? Why do we need two sparql implementations?
> I would really like to get some perspective on this one.
I hope the discussions we had at Akademy went some way to achieve
that. I really think we do need to improve collaboration between the
MeeGo/Maemo and the KDE semantic desktop projects. One example is
keeping the ontologies in step - maybe if the Maemo guys don't think
that change requests take too long to get accepted, they could put
them into some kind of experimental branch in the ontology repo,
rather than putting them only in the Maemo code repository.

My apologies once again for not giving you advance warning about
QtSparql, and not giving you proper credit.

regards
-- Richard Dale