Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof <philip codeminded be>]

On Thu, 2013-04-11 at 14:29 +0200, Philip Van Hoof wrote:
> On Thu, 2013-04-11 at 15:53 +0530, Vishesh Handa wrote:

> > In the Nepomuk KDE world we generally use graphs to group triples
> > based on which application has stored the information. This is
> > especially useful in the case of indexing. When a file has been
> > modified and needs to be re-indexed, we need to throw away the
> > previous data and re-index it. The file could in this case have both
> > indexed and non-indexed data such as tags and ratings. So, we only
> > remove the statements that were added by the indexer and then reindex
> > the file.
>
> This isn't supported by Tracker.
>
> > This seems like a very common use case. I'm curious as to how tracker
> > solves this problem.
>
> It doesn't. Full graph support was not a design consideration, only
> limited support for it was.

Let me rephrase that: there is a solution for this in Tracker, but it's
somewhat specific to miner-fs.

The miner-fs file indexer will only overwrite triples that have as
origin the miner-fs's graph. When you write a triple you'll always
overwrite its graph value (it's recommended to always provide it and to
never use the one of miner0fs).

Tracker's graph support is like supporting a default graph value, but
only a default one (not more than one).

So basically, miner-fs indexes a file and stores its metadata in sparql
using its own graph.

Another app stores or updates new metadata and uses its own graph.

When miner-fs updates the metadata of the file, it will only overwrite
data in its own graph.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be