Re: Proposing Tracker for inclusion into GNOME 2.18

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ross Burton wrote:
> On Wed, 2006-10-25 at 23:10 +0100, Jamie McCracken wrote:
> > > The RDF way would be (triples):
> > >
> > >   hasPersonalEmail --- rdfs:subPropertyOf ---> hasEmail
> > >   hasWorkEmail     --- rdfs:subPropertyOf ---> hasEmail
> > >   RossBurton       --- hasWorkEmail       ---> ross openedhand com
> > >   RossBurton       --- hasPersonalEmail   ---> ross burtonini com
> > >   RossBurton       --- hasPersonalEmail   ---> ross burton gmail com
> > >
> > > You would then be able to query on "hasEmail" and get all three addresses.
> > okay that looks nice.
> >
> > I will add some kind of triple store (ie use three tables instead of the 
> > current two tracker uses for metadata).
> >
> > I dont have plans to turn tracker into a full semantic web thing but I 
> > do want to take advantage of this in the simplest way possible.
>
> There is very little difference between a database with three columns,
> and a true triplestore ("full semantic web thing") apart from the fact
> that the former has lots of RDF:s magic inherently available to it.
> Which, incidently, is already coded up in librdf.

yes I will borrow some code from it.

> As I said before, librdf contains database-backed triplestores, RDF
> query parses, and more.  All one needs to do is glue it together with an
> indexer.

thats problematic because we dont just use sqlite for metadata but lots 
of other performance critical stuff (namely storing results of live 
queries, merging results from rdf query with fulltext searches etc)

the librdf creates a standalone database so cant be properly integrated 
"as is" with out existing sqlite stuff (can modify librdf though to do so)

For the query stuff, I would need the generated sql to join against our 
full text index results and librdf does not provide for that. (it would 
be too slow and consume too much memory to merge two potentially big 
result sets entirely in memory). Full text results in tracker are 
currently stored in a temp table for joining against the rdf query's 
generated sql in a fast and efficient manner.

so to integrate I would need to either extract code from or modify librdf.

All I need (as we already have a functional and extensible rdf query 
support already in tracker which is optimised for rdbms use rather than 
hashtables as librdf is) is just the triple table structure and the 
rdfs:SubProperty stuff coded in librdf for the metadata relationships.

By not using librdf as is, we can better optimise stuff as JamesH 
suggested with a flattened table for metadata relationships as well as 
the fact we already use integer based joins on our tables as opposed to 
the slower string ones librdf appears to be using (librdf also mentions 
its not optimised for RDBMS use - http://librdf.org/docs/storage.html)

Let me know if you think I need any other stuff...


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/