[Wasabi] Kicking of the Metadata spec - brainstorm

[Jos van den Oever]

2007/2/20, Joe Shaw <joeshaw at novell.com>:
> On Mon, 2007-02-19 at 23:35 +0100, Mikkel Kamstrup Erlandsen wrote:
> >  ** What we need:
> >
> >   Fields)  Metadata field names and descriptions for *desktop*
> > objects
> >
> >   Types) A type grouping of metadata fields to be used in user search
> > language. Example types could be "Email", "Image", "Audio", etc.
> >
> >   API) A dbus api to get/set metadata
> >
> >   ?Tag/Emblem) Tagging/Keywords/Emblems
>
> Taking a step back here.  What exactly are we looking to define?  Just a
> set of fields and types that end users can use to narrow down search?
> "Metadata" is such a huge space here that I think we need to know what
> we're supposed to be covering here.
>
> If we go down the "search-only" path, I don't think we should be
> defining APIs for getting and setting metadata.  While metadata and
> desktop search are related and complimentary, they're not the same thing
> and I don't think that a desktop search system necessarily should also
> be a metadata store.
>
> As for tags, I agree, there's nothing special about them.  They should
> just be a string array.

What was not specified so far is the names of the fields that can be
searched in and a common way of defining theses names. Defining these
fields happens to be the same way you would specify the fields that
are writeable too. Naming these fields is not the same as defining an
API on how to write them. I agree that pure searching and annotating
are different things. But reading, writing and searching metadata
fields is something that desktop applications will want to do more and
more. Since there is, to my knowledge, also no standard for reading
and writing metadata in fd.o, this is a good opportunity to come up
with it.

For pure desktop search, the relevant parts of this discussion are the
types, the names and the groups of the fields because the other wasabi
defs point forward to this.

In Strigi we really need something like this and in KDE as a whole
too. In KDE3 something like this is implicit, albeit less clear. I'm
currently working on redoing the metadata reading and writing and I'm
implementing at least the above simple scheme. The nepomuk guys tell
me that this should be compatible with their larger metadata ontology.
Whereas we are talking about metadata that relates to files, they are
working on a wider definition.

When you think of writing metadata, you can e.g. think of the
properties dialog in Konqueror where you can write title and artist
for mp3 files. For searching you want to name this field and for the
read/write api you want to name it too, so you might as well use the
same language for that.

Cheers,
Jos