2007/2/20, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2007/2/20, Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>>: > 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.</blockquote><div> Is it just Sebastian? I'm generally not keen on one-man-speccing. 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. </div> Cheers, Mikkel </div>