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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
