Re: New module proposal: tracker

[John Carr <john carr unrouted co uk>]

On Tue, Nov 10, 2009 at 10:28 AM, Rob Taylor <rob taylor codethink co uk> wrote:
> Iain wrote:
>> On Mon, Nov 9, 2009 at 12:01 AM, Philip Van Hoof <spam 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
>