Re: [Tracker] Mining GVfs metadata

[Tomas Bzatek <tbzatek redhat com>]

On Tue, 2010-11-23 at 17:09 +0100, Adrien Bustany wrote:
> nao:prefLabel does not apply to a file, but to a tag. You would have the
> file, of types both nie:InformationElement and nie:FileDataObject, and
> then a tag (type nao:Tag), and link those two using nao:hasTag. The tag
> itself has a label. So if you have 5 files with the tag "Holidays", you
> actually have on tag resource with label "Holiday", and 5 files linked
> to that resource (with nao:hasTag).
Right, found
http://live.gnome.org/Tracker/Documentation/Examples/SPARQL/Tagging
which is a good reference to me.


Okay, so I got the code working, decided to go with live updates for the
beginning, i.e. push changes to tracker as they come. It's better that
way since we can track changes more easily. Still a lot of things to
solve.

But I need more sparql help now. First thing I realized is that I can't
update existing data, have to first delete old ones and then insert new.
Is there a better way? TrackerSparqlBuilder seems to have support only
for insert, delete, select.

Similar situation when adding record for a file (miner-fs using a kind
of DataSource?). There's high risk that attributes wouldn't match:

(tracker-store:9701): Tracker-DEBUG: ---- [2] query: 'INSERT {
<file:///tmp/slim01.jpg> a nie:InformationElement , nfo:FileDataObject ;
         nie:isStoredAs <file:///tmp/slim01.jpg> ;
         nie:url <file:///tmp/slim01.jpg> .
}'
Tracker-Message: ---> [2] Failed, Unable to insert multiple values for
subject `file:///tmp/slim01.jpg' and single valued property
`nie:isStoredAs' (old_value: '102060', new value: '102057')

Also, for setting information attached to a file, a record must already
exist in the database (due to WHERE statement, I get always a success
for the operation but only affecting 0 rows).

So that means when I want to update tags of some file, I need to perform
the following steps:
 1. delete record for the file in the database (or at least some
attributes)
 2. add a record for the file
 3. delete all existing tags attached to a file (can't know what tags
have been set previously by us)
 4. create missing tags
 5. attach all tags we need

This sounds crazy to me...


Another thing has crossed my mind this morning - if tracker-miner-fs
indexes removable media, how does it cope with mountpoint changes? I
mean once the media is mounted as /media/disk1 and the other time
as /media/mydisk. AFAIK full URI (absolute path) is stored in tracker
database. In gvfs-metadata, we treat mounts separately, independently
from mountpoint paths, in separate databases. My code does a translation
from device UUID or label back to mountpath, in order to get absolute
path of the file. 

Also, should I use tracker_miner_fs_ functions instead passing plain URI
(file:///mnt/something/file), i.e. tracker_miner_fs_get_urn() ?
        
Thanks,
-- 
Tomas Bzatek <tbzatek redhat com>