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 _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
