Hi Sebastian On Thu, Jul 1, 2010 at 9:22 AM, Sebastian Trüg <[email protected]> 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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
