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

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2009-10-27 at 14:53 +0200, Natan Yellin wrote:

> On Tue, Oct 27, 2009 at 2:54 AM, Martyn Russell <martyn lanedo com>
> wrote:

[ CUT ]

>         
>         Quite a few. For example, if a file is size 0 and it is an
>         image, height and width should probably be set in any case.
>         Right now, we don't set any data. Some applications will
>         EXPECT some ontology data to ALWAYS be present and this is the
>         problem.

> Right, I understand why it would make sense for tracker to return
> default ontology data. I just don't understand why that data should
> ever be written back to the original file. (The only use that I
> understand- and disagree with- is to fix up filenames using Video
> Title.) 

As said before, the entire Tracker team agrees (with you, too) that
default data must never be written to the files themselves.

What the write-back feature is about is writing back known meta-tags to
files which the user has set himself. In other words the meta-data
written to the SPARQL store of Tracker where the origin is the user.

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


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.

For that we could use SPARQL's native support for named graphs:

PREFIX tracker: <http://www.tracker-project.org/ontologies/tracker#>
INSERT INTO <tracker:user> { <file:///file.mp3> nie:title "My MP3 file" }


However, 

This entire last block of text is my personal conclusion and my personal
own point of view on part of the solution to the problem "write back".

This ain't a team conclusion nor decision. We're still debating and
discussing both such design and implementation details.

>         Really I think it would be nice if the ontology standards
>         could detail this.

So note for the readers, this ain't about the write-back feature
anymore. But about the default-values.

Although this might be useful my personal opinion on this is that the
SPARQL coalesce function is sufficient, and that for this reason we
don't need to entertain default values in either ontologies or at the
level of file formats (ie. what was being ~ done in Tracker 0.6).

My opinion is that this adds a level of complexity that is unexpected by
the app developers (in case they have coalesce), that might not yield
wanted results for all applications (it'll be a compromise in most
cases, not something that for every use-case will yield wanted results).

And I happen to lean towards "if a complex solution and a simple
solution both solve the problem, then it's most likely the case that the
simple solution is what you want". That simple solution is called the
coalesce support that we've put in SPARQL.

I don't know what the final team-conclusion on this will be, though.

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be