Author: Nathan Willis
In media management applications, the importance of good metadata handling outweighs good data handling, because the metadata are how we locate and track the data files with which we work. The audio player marketplace learned that lesson years ago, which is why you would be hard-pressed to find an audio player today that doesn’t understand ID3 tags and let users interface with files through them. Users decide which track to listen to based on metadata: artist, song, album, genre, and so on. Imagine how painful it would be if the only way to browse through your music collection were by file name alone — or, worse yet, by listening to a five-second clip from every track, with no access to the meta-information directly. How easily could you find what you wanted?
Yet that is the situation most photo apps leave you in. You search through your images by thumbnail, or at best by date. Cameras don’t auto-generate useful filenames, and while it’s good that almost all photo apps can read the embedded EXIF data, that information isn’t really helpful for “human” searches. EXIF data is automatically generated by the camera — width, height, shutter speed, aperture. That’s roughly analogous to fixed characteristics like track length, bit rate, and sample rate — good to know, but not what you generally think about when searching for a tune.
Some photo management apps incorporate pseudo-metadata like “star ratings” or “tags.” The two look different in the user interface, but essentially star ratings are just a subset of tags (the “onestar” tag, the “twostar” tag, etc.).
Tags are a poor interface for desktop applications. For one thing, tags work only when they are used in bulk, and work best when they harness the collective intelligence of large groups, not individuals. Read Tim Spalding’s excellent essay at LibraryThing on why tagging works for LibraryThing but doesn’t work for Amazon.com. In order for tagging your photos to prove useful, you have to tag every single one of them, on every factor of interest.
Another problem: tags have no context. Does a photo tagged with “mom” and “birthday” mean a photo of your mom on her birthday, or the photo of your birthday that your mom emailed to you? Both meanings are semantically valid, as is every other variation. Without a real context, the meanings of tags flatten out to least-common-denominator of metadata: the amorphous “subject.”
What about geotagging, which involves specifying the location of a shot with both a latitude and longitude tag (Flickr usesgeo:lat=1.2345 and geo:lon=67.890)? With those tags you can pinpoint the location of a scene — isn’t that an example of tags that provide a context? Yes, it is, but only because it has moved beyond tagging and into structured key-value pairing. And that’s metadata.
Support your local library
The old standard for semantically meaningful photo metadata was the Information Interchange Model (IIM), a data model drawn up by the International Press Telecommunications Council (IPTC) for use in commercial media environments. It picked up steam when Adobe added an IIM metadata embedding system to Photoshop. Adobe being the graphics industry’s 800-pound gorilla, that effectively made IIM the standard. But open source software only supported it intermittently and inconsistently — in part because few if any home users shared the same needs as graphics production houses. That will have to change, though, as the pro feature of today is the consumer feature of tomorrow.
Luckily Adobe is not as protective and closed about standards as some software heavyweights, so when it drew up its own successor format, it chose to base it on XML and publish the specification. That spec is XMP: an XML for generic image metadata. Existing standards like EXIF and IIM are simply implemented as XML namespaces, and on top of all that, users can create their own custom namespaces on a whim.
Adobe has been shipping XMP-aware apps since 2001, but up until now we have not seen an open source application step up and tackle XMP head on, providing read/write support, the core namespaces, and creation of custom namespaces. In fact, the apps that did address XMP all stopped at reading the data, not even doing anything useful with it.
Now we have XMP Manager, a one-man project to build an XMP interface for Nautilus, the GNOME file manager. It’s a small effort, limited in scope, but while reading others’ assessments of it I came across Hubert Figuiere’s exempi project. Exempi is designed to be an XMP reading and writing system library, LGPL-licensed and reliant on libxml2. Figuiere describes the API as far from complete in the current release (0.5), but he plans to support the EXIF, IPTC, and Dublin Core XMP namespaces.
Creating a library instead of adding support to an existing photo manager is far and away the better solution; certainly libexif is responsible for the wide EXIF support of today’s apps. Figuiere wants exempi to make XMP “as painless as possible” for higher-level apps, and it comes at a time when mainstays like gThumb, Picasa, and DigiKam are looking at how best to adopt the newer format. If we waited for all of them to implement XMP individually, we would be in for a long wait followed by incompatibilities.
Adobe supplies an XMP software development kit (SDK), but it incorporates multiple clauses, making it incompatible with free software. Figuiere has not looked at it, but has made use of the official XMP spec, which despite being an official Adobe publication, is free of the restrictions that complicate the SDK. He describes the spec as clean and “quite exhaustive.” Along with Adobe’s sample XMP files, it makes a useful resource for open source developers.
It is natural for free software advocates to be wary of proprietary giants like Adobe, but XMP is an instance where the company is to be trusted. The XMP spec is open, and better still, extensible through XML namespaces. Those factors are far more important in the long run than the fact that the SDK is unusable to free software projects.
Thanks to its scope, XMP has uses that range beyond the relatively limited purpose of older formats like EXIF. XMP is just as useful for vector graphics as it is for photographs, and it is not even limited to still images — it may prove to be a useful spec for video files as well. Just as importantly, XMP is not limited to individuals tracking their own files; the machine- and human-readability of it could prove useful for large, user-generated content libraries. Take Creative Commons, for example, which has already embraced XMP, even providing custom XMP templates with which Photoshop users can add Creative Commons licensing information. The size of the collective CC-licensed works on the Internet far outscales any personal or corporate collection; who better to leverage that collection than the free software community?
