IMatch and Metadata

As I wrote the previous entry I started with a presentation of IMatch and then ventured into describing how its metadata management isn't quite with the times. The point of the article wasn't a critique of IMatch, so I'll just post all that stuff here.

IMatch[a] is a fantastic photo management tool. It is fast, easy to use, and best of all - it doesn't impose itself on you. When just about every other tool wants to control your whole workflow (and in some cases, the media storage as well), IMatch is content with doing what it does best, locking you in by making you want to stay with it instead of imposing penalties on leaving. You can keep your open-format images, with their open-format metadata.

To sum it up - IMatch is the Digital Asset Management tool I would have written, had I written Digital Asset Management tools.

Well, with one exception: IMatch makes you choose between extensible and interoperable metadata.

​1. A Brief History of Metadata

Previously, the metadata that could be stored about an image was restricted by the file format or some other published, industry-wide standard. Most image files had some kind of "description" field. EXIF, an early metadata standard, was used by digital cameras to store information about the camera settings used to capture the photo. IPTC, another standard, would be used to store image authorship and licensing information.

Any extension to these standards were an industry-wide issue: First, the relevant standards body (if one existed) would have to declare what the additions were. Then all software makers had to implement the new fields and ship new versions of their products.

This left people out of luck if they wanted to store some information about the photo that didn't fit in any of the fields defined by those standards. The result was often that the "description" field was used and abused to store the extra data.

XMP, the eXtensible Metadata Platform, was created so that metadata could be extensible: If you or your organization needed to store anything extra, you should be able to define your own standard - and all software tools should, even if they didn't understand the data, at least not accidentally corrupt it. If the data you wanted to store then became an element of a new standard, you could easily migrate to the new way of doing things. Standardized tools could be used to manipulate the data - even if they didn't "understand" what the data was, the rules for copying, changing, reading and writing would be the same. Just as a word processor doesn't understand the text in the document that is being edited, it knows how to load it, display it, let the user change it, and save it.

​2. IMatch's Two Types of Metadata

IMatch 3 - the previous version of IMatch - came into a world were XMP was on the rise but still dominated by older, non-extensible, standards. To get around this, it let you define custom properties for each image and optionally load metadata from the image into those properties. If you wanted a new property, you'd just define it and then start using it.

Those properties are still around in IMatch 5 - the latest version - now in the form of Attributes, but with an important distinction - you typically don't import any metadata into them. Instead, metadata is handled separately. This reflects the new environment with XMP being the winner and everything else becoming XMP-ified.

It is important to note here that while image metadata stays with the images themselves and are accessible for other tools and programs, the attributes are a completely IMatch-specific concept. They reside in your IMatch database file.

​3. The Dilemma

If we want extensible metadata interoperability - that is, the ability to define our own metadata that can be used by the ecosystem of metadata processing tools that exist - this arrangement leaves us with two choices, both bad:

• Metadata: No extensibility, since you are stuck with whatever metadata ExifTool supports out of the box - but you get interoperability.

• Attributes: No interoperability, since the attributes live inside IMatch only - but you get extensibility.

​4. The Solution

The possible solutions to this were either to try to work with IMatch attributes, or to extend ExifTool. Since I chose IMatch primarily for it not locking me in and letting me keep my metadata in open formats with the assets it manages, I'm loath to go the attribute route.

This leaves only one route - make IMatch do what I want done with metadata.

I predict that the next major version of IMatch will have gone where everyone else have gone - XMP metadata for everything. Attributes will be defined as XMP metadata under a user- or database-specific namespace.