Re: [Tracker] Write-back data & default/dummy data

On 27/10/09 14:10, Philip Van Hoof wrote:
An example:

The tracker-miner-fs sees an MP3 file that has no ID3 info for Title.

o. The current consensus is that nie:title will just not be available
    for the MP3's resource in SPARQL.

o. The current consensus is that you can get a "nice title" this way:

    SELECT COALESCE(nie:title(?n),nfo:fileName(?n),"unknown") ...

o. The write-back feature means that if the user does this:

    INSERT {<file:///file.mp3>  nie:title "My MP3 file" }

    - That we consider this a set by the user, with origin = user.

    - That we want to write "My MP3 file" as Title ID3 tag into /file.mp3
      in case we want the write-back feature

Thanks for the round up here Philip.

My personal conclusion:

As far as I'm aware there is right now no way to say with the store's
SPARQL UPDATE support what the origin of metadata is. Whether it comes
from tracker-miner-fs or from an external "user" application can't be
differentiated in tracker-store's current handling of SPARQL UPDATE.

In my understanding we need to know about the origin of the metadata in
order to know whether we either should, or shouldn't inform a component
that will do a write-back about the necessity of writing back.

That's not strictly true actually. It did occur to me that we know the dbus entity that sends us the messages and we should be able to identify tracker-miner-fs amongst those. This isn't full proof though, since the tracker-store would have to have a list of known miners to know what is user specific and just mined.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]