Re: New module proposal: tracker

On Sun, 2009-11-08 at 20:43 +0000, Iain wrote:
> > Tracker 0.7 ships with a DBus API, Nepomuk as ontology, SPARQL as query
> > language, SPARQL UPDATE for inserting and updating data and finally
> > signals-per-classes as life search capability.
> >
> > The DBus APIs are simple but very powerful thanks to SPARQL.
> From looking at tracker again this weekend, and indeed it does work
> better than the last time I checked in June (modulo some apparent big
> bugs and some issues with the concept that I couldn't test due to the
> bugs) but from a application developer point of view, I'm still
> disappointed.
> Essentially, I feel the APIs are far too low level and the
> documentation is very very incomplete, which ended up leaving me
> wandering around in dark as to what I was meant to do. The Application
> Development Manual is useless (I know its not finished, but its no
> help at all). I know you guys love love love ontolgoies and SPARQL and
> predicates and all that, but honestly, as an application developer I
> couldn't care less.

This is not what we love, this is simply the vocabulary used in RDF.

I know a lot of people hate hate hate buzzwords and all that. But in the
end it is actually important to agree on a vocabulary. 

This is that vocabulary.

> All I want is to get at the data I want in the
> easiest possible way, and looking at tracker and discovering that I
> need to learn yet another language and a whole new load of boring
> concepts to do that is very offputting. SPARQL, tuples, ontologies
> should be internal details that you shouldn't need to know about.

You'll always have to learn how the things that you are working with
look, what relationships with other things can be made, etc. It's the
ontology that tells you this.

You'll have to understand how to query it, especially if you want to
formulate more complex questions about your data. That's SPARQL.

> Looking at tracker/src I see 7 things begining with libtracker- and
> none of them look overly helpful. The most useful looks like
> libtracker-client, but again its too low level.

libtracker-client is really only for C developers who want to get some
DBus infrastructure quickly at this moment.

The API is the DBus API. We haven't yet made any higher level APIs,
although we could probably do that.

I personally think that SPARQL is, once you get it, so straight forward
that any such high level API is simply not necessary. SPARQL is much
more simple than SQL. 

> What I would really
> like to see is some simpler high level calls that enable me to get all
> data of (for example) Music, allow me to specify what fields I want,
> and it should be a GObject that I can connect to signals on to find
> out when a result has been added/removed/changed.

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.

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

> We should be looking
> to make our APIs as simple and easy to use as possible to enable
> developers to make the applications without distracting them with
> irrelevant implementation details. If this already exists, I apologise
> and blame the lack of documentation.

The libqttracker library provides this for Qt. We haven't yet had the
time to make something as high-level for the GLib world.

Libqttracker is what is being used to build various applications for the
new Maemo platforms.

It generates high level classes like "MusicPiece" and allows you to get
a list of musicpieces, given a query. (Just an example).

Libqttracker uses the Nepomuk ontology to generate itself. So it exposes
quite an amount of types and classes, etc.

Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]