[Nepomuk] QtSparql vs Soprano/Nepomuk

[Sebastian Trüg]

Hello Richard, hello Nepomukians,

after meeting Richard in Finland and calming down a bit (sorry if my
first email was a bit harsh) I got to terms with the situation.

On 07/10/2010 07:01 PM, Richard Dale wrote:
> 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.

An async API is indeed a good idea. Of course I would have liked to have
this layer in Soprano, too. But I also understand Nokia's interest and
why they would like to have such a layer in Qt.

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

Calling it ResultRow IMHO is very SQL'ish. But in the end the names are
not that important.

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

don't worry about it. When writing the first email I was very frustrated
that Soprano would possibly die. :P
But now I accepted the fact that at some point we will have to move to
QtSparql and drop most of Soprano...

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

Personally I doubt that the situation will change in the near future but
I still have hopes. :)

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

After the nice talks we had at the Akademy all this is not that
important anymore. No need to apologize.

Cheers,
Sebastian