[Wasabi] Kicking of the Metadata spec - brainstorm

[Sebastian Trüg]

On Tuesday 20 February 2007 23:25:54 Mikkel Kamstrup Erlandsen wrote:
> 2007/2/20, Jos van den Oever <jvdoever at gmail.com>:
> > 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.
>
> Is it just Sebastian? I'm generally not keen on one-man-speccing.

Time to get into this discussion. Sorry for the delay. No, it is not me at 
all. I am just the portal to the open-source world. The metadata ontologies 
(Nepomuk defines complete ontologies here, see my other email) are defined by 
a task force within the Nepomuk project. I actually only try to communicate 
this to the outside world (apparently I did not that good a job so far ;)

> I can't make up my mind. On one hand I think that the way metadata is
> stored is an implementation detail, on the other hand it might be good to
> standardize it. It could be a standard that is orthogonal to the other
> parts of the metadata specs though.
>
> Cheers,
> Mikkel