[Wasabi] Kicking of the Metadata spec - brainstorm

[Jos van den Oever]

2007/2/20, Joe Shaw <joeshaw at novell.com>:
> Hi,
>
> On Tue, 2007-02-20 at 20:52 +0100, Jos van den Oever wrote:
> > 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.
>
> I agree.  But it is something that should be kept conceptually separate
> from desktop search.
>
> > Whereas we are talking about metadata that relates to files, they are
> > working on a wider definition.
>
> Do you mean files in their strictest sense, or also things like emails,
> addressbook contacts, etc?
Yes, those too. Mails are clear, addressbook contacts is a bit
slippery, but yes those too. So files and url-addressable parts of
files.

>
> > 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.
>
> Indeed, and we should also use the same storage for it whenever
> possible.  I envision a three-tiered system for actually setting
> metadata on files:
>
> 1. Store the metadata in the file itself whenever possible.  Things like
> id3 tags in MP3s or XMP metadata in jpegs.  This is ideal because it's
> in a standardized format that most tools can read, and the metadata
> follows the file around no matter where it's sent.
>
> 2. Store metadata in extended attributes on the file in the file system.
> This has the benefit in that the metadata follows the data around within
> a single system, and our desktop applications can be standardized around
> a schema for xattrs.  Obviously this won't work for non-file items or on
> file systems that don't support them.
>
> 3. Lastly, store metadata in some sort of centralized store, like a
> sqlite database.  Keeping metadata in sync with data is harder, but
> fortunately most of the data that would require this mechanism wouldn't
> have mostly unique URIs.  I'm sure Jamie will disagree with me on this,
> but I don't think this requires a constantly running daemon; a simply
> library interface would probably suffice.

Hehe, now _you_ are taking this spec further then intended. ;-)
I'll not get into this. On the KDE side this is something for
Sebastian Trueg (Nepomuk) to consider.

Cheers,
Jos