Re: Proposing Tracker for inclusion into GNOME 2.18

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ross Burton wrote:
> On Thu, 2006-10-19 at 10:12 +0100, Jamie McCracken wrote:
> > It also has fully extensible metadata and a desktop wide tag/keyword 
> > database so apps can use it to store all their metadata about any first 
> > class object (also kind of nice for integrating with the new G-VFS 
> > metadata handling)
>
> But the "extensible metadata" isn't really extendable is it.  If I add a
> new type Foo.Title, and then ask the tracker to search for a string in
> titles, Foo.Title won't be searched.  I have to wait for the Foo.Title
> tag to be incorporated into the specification and the UI tools updated,
> which makes it useless for indexing custom metadata.

not true. The spec is a guide only so for example ryhthmbox could know 
in advance what metadata types should be there. There could be others of 
course and it can be introspected but a spec is needed to define default 
types only.

All metadata types in tracker are treated equally so they can all be 
used in searching (if defined as indexable) and rdf query.

In the UI, we will add support for  metadata searching including custom 
types in the next version.

> Also, if I search for "created by ross" how does the system need to know
> that it should search File.Publisher, Audio.Artist, Audio.Performer,
> Doc.Author and Image.Creator?  The naming scheme here is inconsistant
> and redundant.

If we were a dedicated search tool then yes but we are a metadata DB as 
well so we need specific metadata names as Audio.Artist and 
Aduio.Performer can contain different values and we might want to only 
search one of those fields.

The searching of specific metadata in tracker is fine grained (and thats 
an advantage in my book) but we can do more coarse ones by combining the 
fine grained ones.

Because with RDF query we can create more coarse searches, its easy for 
a UI to do a "search by created" by OR'ing toegther the fine grained 
ones. In fact we will have to do this in the next version of our GUI as 
we can only  expose perhaps 12 common types and maybe have an "other..." 
one that opens a popup for less common and custom ones.

We need to keep the gui simple yet powerful enough for more advanced 
users like yourself so please let me know of any suggestions you have 
for amalgamating these types of searches -they are easy to implement.

> Also, you appear to be subsetting and generalising existing ontologies.
> Your Image.* types somewhat map to a subset of EXIF but how did you
> decide what EXIF tags should be included?    Why didn't you include
> exposure compensation?  Why only Image.Date when EXIF defines three
> different Date fields (taken, digitized, edited IIRC)?  Also note that
> EXIF dates are in local time so don't have any timezone information, so
> they won't fit into a datetime type.

We can quibble about an odd metadata field not being present ad 
infinitum and its unlikely we will have all possible values by default 
in the spec but it does not matter as such because tracker is extensible 
so theres no limit in adding extra items in future.

You are also welcome to patch our exif extractor with other fields you 
think are really needed.

Also note that other specs like OS/X spotlight only include a subset see 
http://developer.apple.com/documentation/Carbon/Reference/MetadataAttributesRef/Reference/CommonAttrs.html


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/