On Tue, Nov 10, 2009 at 10:28 AM, Rob Taylor <rob.tay...@codethink.co.uk> wrote: > Iain wrote: >> On Mon, Nov 9, 2009 at 12:01 AM, Philip Van Hoof <s...@pvanhoof.be> wrote: >> >>> Sorry but, with DBusGProxy you already have a GObject that you can >>> immediately connect a signal to and get informed when something gets >>> added, removed and changed. >>> >>> http://live.gnome.org/Tracker/Documentation/SignalsOnChanges >>> >>> With DBusGProxy you also already have a GObject to make a SPARQL query. >>> You just have one method called SparqlQuery that takes a string, and >>> that returns an array of an array of strings. >>> >>> It can't get much more simple than that. >>> >>> Except that with libtracker-client you don't even have to think DBus >>> anymore. >> >> I saw the DBus API, I just didn't seriously think you were proposing >> it as application facing API. >> Porting the QTtracker library (or writing a high-level GObject >> equivalent) should be a priority if >> you want to get Tracker accepted by GNOME. > > As John mentioned earlier, see: > > https://labs.codethink.co.uk/index.php/p/sparql-glib/ > > I'd be quite happy to propose this as a GNOME module. It probably needs > some cleaning and tidying but is completely usable at this point. > > Thanks, > Rob
One option is that some of this code could be merged into tracker itself, if it is deemed useful, along with exposing TrackerSparqlBuilder (which might be internal atm? can't remember). Just an option, but i'm not strictly in favor of that as i had hoped to see it able to access other SPARQL endpoints like dbpedia.org. That said, theres no reason it couldnt support multiple endpoint types, as im sure the miners would love to query such repositories online. The main problem with sparql-glib as it stands is that it stands is that its still quite low level. You are essentially building an AST by hand and then sparql-glib flattens that into sparql. For the common case we need to come up with something a little higher level i think. Like gobject property getters (pass in multiple properties to fetch, it builds and uses the AST to get sparql). However for complicated queries with lots of relations to other resources this approach won't be as useful, i think. I'd like to see jalchemy merged in to sparql-glib too, as that is really just a wrapper to make using sparql-glib less verbose from js land. John > >> iain >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > -- > Rob Taylor, Codethink Ltd. - http://codethink.co.uk > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list