On 11/16/2010 06:40 PM, Richard Dale wrote: > On Wed, Nov 10, 2010 at 7:11 AM, Sebastian Trüg <[email protected]> wrote: >> The solution is simply what I said: we support the tracker API and >> that's it. The other way around is not possible anyway. > OK, how would you like to support the tracker API? I'm still not clear > on what you are saying. > > One way would be to write a Tracker backend for Soprano 2.x which > would support a subset of the Virtuoso backend's functionality.
For me this is all way too low level. The API I am talking about is much higher in the stack. I do not want app developers to handle data on the triple/quadruple level. I rather want one API that provides nice methods for all our data needs. I do not know yet how this API will look like but it will neither be Soprano nor will it be QtSparql. Cheers, Sebastian > Another way would be to write a QSparql based backend for Soprano 2.x > which would interface with Tracker, and also support SPARQL endpoints > and Virtuoso as a side effect, although you would be perfectly welcome > not to use that extra functionality as the drivers are only plugins. I > happen to be an expert on the Tracker apis (both the DBus one and the > newer 'direct api'), and the Tracker team are cooperating to improve > their api WRT its use in QSparql. I am also an active KDE developer > who has developed language bindings for Soprano and Nepomuk, and I am > quite happy to work on KDE things in my spare time. So if anyone can > do this particular task I feel I should be about the person person to > try. > > I don't know what your plans for Soprano 3.x are as I haven't studied > the code yet. > > -- Richard > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
