Re: New module proposal: tracker

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2009-11-10 at 12:51 +0000, John Carr wrote:
> On Tue, Nov 10, 2009 at 10:28 AM, Rob Taylor <rob taylor codethink co uk> wrote:

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

TrackerSparqlBuilder only supports INSERT and DELETE queries*.

* http://jena.hpl.hp.com/~afs/SPARQL-Update.html

We could easily expose this as client API, but we'd love to first have
support for SELECT too. Otherwise it's a bit limited in usefulness for
application developers.

Maybe is sparql-glib providing this and could it extend TrackerSparql-
Builder? We wouldn't be against accepting patches, if they are sane, to
improve on tracker-sparql-builder.vala (even if we wouldn't use it yet
ourselves).

SPARQL should be generic for all kinds of RDF stores (virtuoso, tracker-
store, etc) so it makes sense to keep it separate. Both KDE's metadata
projects and tracker-store are indeed going for SPARQL and Nepomuk. It's
indeed awesome that the metadata-ppl are in a big agreement on this atm.

SPARQL for virtuoso and for tracker-store are of course mostly the same.

We just have a few functions that other SPARQL services might not have,
and vise-versa. For example fts:match, fts:offsets and fts:range.

Standardizing them is part of exploring of SPARQL-on-Desktop. We're of
course discussing this with other people in the desktop-metadata-world.

If somebody wants to work on this perhaps a GSparqlQueryBuilder and then
a TrackerSparqlQueryBuilder that extends, adds and overrides
GSparqlQueryBuilder's virtuals with things that are specific for our
store's specialized use-cases?

/j #tracker and come talk with us. But You are already talking (and
coding) with us, John ;), so this is for the other ppl.

This client stuff doesn't have to be part of Tracker. We can make it
part of Tracker. Let's architect & design! :)

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

Exactly, precisely.

> That said, theres no reason it couldnt support multiple endpoint types, as
> im sure the miners would love to query such repositories online.

Awesome that some people are getting it! Thanks John.

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

Let's architect & design!

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

Sure, let's architect & design! :)

Hehe

As long as people who'll actually code, not just talk, take part, we'll
most likely join their ideas and help with the coding. People like you,
John. So if you know where the others are hiding, go get them!

It's absolutely not that we don't want this client stuff to happen, it's
that we have quite a list of things to do in Tracker itself. A bit of
momentum and contributors will help the client's side a lot, I think.


And with that has this thread grown way too large. If all the energy
that went into this thread would have been put in coding stuff, we'd
have five client libraries by now.



-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be