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

[Martyn Russell <martyn lanedo com>]

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.

--
Regards,
Martyn