XMP and microformats revisited

Yesterday I exercised poetic license when I suggested that Adobe’s Extensible metadata platform (XMP) was not only the spiritual cousin of microformats like hCalendar but also, perhaps, more likely to see widespread use in the near term. My poetic license was revoked, though, in a couple of comments:

Mike Linksvayer: How someone as massively clued-in as Jon Udell could be so misled as to describe XMP as a microformat is beyond me.

Danny Ayers: Like Mike I don’t really understand Jon’s references to microformats – I first assumed he meant XMP could be replaced with a uF.

Actually, I’m serious about this. If I step back and ask myself what are the essential qualities of a microformat, it’s a short list:

  1. A small chunk of machine-readable metadata,
  2. embedded in a document.

Mike notes:

XMP is embedded in a binary file, completely opaque to nearly all users; microformats put a premium on (practically require) colocation of metadata with human-visible HTML.

Yes, I understand. And as someone who is composing this blog entry as XHTML, in emacs, using a semantic CSS tag that will enable me to search for quotes by Mike Linksvayer and find the above fragment, I’m obviously all about metadata coexisting with human-readable HTML. And I’ve been applying this technique since long before I ever heard the term microformats — my own term was originally microcontent.

But some things that have mattered to me in my ivory tower, like “colocation of metadata with human-visible HTML,” matter to almost nobody else. In the real world, people have been waiting — still are waiting — for widespread deployment of the tools that will enable them to embed chunks of metadata in documents, work with that metadata in-place, and exchange it.

We’ll get there, I hope and pray. But when we finally do, how different are these two scenarios, really?

  1. I use an interactive editor to create the chunk of metadata I embed in a blog posting.
  2. I use an interactive editor to create the chunk of metadata I embed in a photo.

Now there is, as Mike points out, a big philosophical difference between XMP, which aims for arbitrary extensibility, and fixed-function microformats that target specific things like calendar events. But in practice, from the programmer’s perspective, here’s what I observe.

Hand me an HTML document containing a microformat instance and I will cast about in search of tools to parse it, find a variety of ones that sort of work, and then wrestle with the details.

Hand me an image file containing an XMP fragment and, lo and behold, it’s the same story!

In both of these cases, there either will or won’t be enough use of these formats to kickstart the kind of virtuous cycle where production of the formats gets reasonably well normalized. In the ivory tower we pretend that the formats matter above all, and we argue endlessly about them. Personally I’d rather see what I’d consider to be a simpler and cleaner XMP. Others will doubtless argue that XMP doesn’t go far enough in its embrace of semantic web standards. But when we have that argument we are missing the point. What matters is use. This method of embedding metadata in photos is going to be used a whole lot, and in ways that are very like how I’ve been imagining microformats would be used.

PS: As per for this comment, Scott Dart informs me that PNG (and to a lesser extent GIF) can embed arbitrary metadata, but that support for those embeddings regrettably didn’t make the cut in .NET Framework 3.0.

Posted in .

18 thoughts on “XMP and microformats revisited

  1. “Or did Scott Dart comment privately on Steven’s comment?”

    Yes. I’d like to interview Scott, and/or folks on that team, for an upcoming episode of my new MS Conversations podcast series.

  2. “In the real world, people have been waiting — still are waiting — for widespread deployment of the tools that will enable them to embed chunks of metadata in documents, work with that metadata in-place, and exchange it.”

    For embedding & working with it in-place, I believe there are already XMP toolkits for most programming languages, and end-user tools like Adobe’s and (as you point out) Vista Photo gallery offer support. For exchanging it – well, an RDF dialect makes sense there because of the virtually arbitrary information a metadata packet can contain. A cleaner and simpler XMP might be desirable, but if XMP’s already fairly widely deployed as-is, wouldn’t it be easier to improve the tools? Improve mapping to e.g. microformats? (I honestly don’t know, but getting companies like MS & Adobe to change on aesthetic grounds is likely to be an uphill struggle…).

  3. From a brief perusal of the XMP Specification, it looks like the structure might also easily be serializable as JSON: simple types, structures, arrays.

  4. I too was confused about your use of the term “microformats.” That said, now that you’ve clarified, I’d like to point out that the microformat community has taken ownership of the name and intends for the name “microformats” to only be used for semantic markup in html that makes it’s way through the “microformat community process.” See [1] for reference.

    [1] http://microformats.org/discuss/mail/microformats-discuss/2006-December/007646.html

  5. Camera manufacturers have figured out a common standard for embedding information in photographs — not limited to gif and png — that can be accessed by many of the photo editors on the market. The photo editing programs can now adjust the color, etc. of a photo based on what is known about the characteristics of cameras.

    So, it is possible. And it is practical if you can get agreement on a standard, which is probably very difficult.

  6. “the microformat community … intends for the name “microformats” to only be used for semantic markup in html”

    OK. Then how shall we broadly refer to embedded chunks of metadata? Because that class of things has important properties that transcend the differences between microformats and “just semantic XHML” and EXIF and XMP and ID3 tags and Word metadata and….

  7. Ok Jon, there may be a way you can shift into Web 3.0 overdrive here, and get what you’re after. Now I don’t know about all the specific details, but I doubt it’s far off. First use Ivan Herman’s Python XMP code (in your IronPython environment) to get the RDF out of the JPG. Load the result into an RDF model in RDFLib. A simple SPARQL query against that (maybe just SELECT ?s ?p ?o WHERE {?s ?p ?o}) could produce SPARQL/JSON results, which you could use directly (following Patrick’s suggestion), or build a DOM including RDFa (along the lines Elias suggested), or, when one becomes available, as a true microformat (in the sense Mike mentions). For round-tripping, right now you might have to go a slightly different route, using XSLT (along the lines of this GRDDL use case) to yield XMP/RDF, which you could then re-insert into the JPG. Convoluted, sure, but versatile through being loosely-coupled and (assuming all the libs work), very programmer-friendly.

  8. PS. “how shall we broadly refer to embedded chunks of metadata?” – metadata embedded in a document is still just data. So I suggest the word “data” ;-)

  9. Jon —

    The emphasis in Mike Schinkel’s comment above was on ‘that makes it’s way through the “microformat community process.”’, rather than on ‘semantic markup in html’. That’s a crucial emphasis, because it’s about the singular community centered around microformats.org. They would call data using semantic markup in HTML just “semantic markup.”

    The thing you’re thinking of, XMP within HTML, is more in line with the now defunct (as far as I know) Structured Blogging initiative.

  10. Audience Seventeen models, a kind f)?This article Several, not in such.Ask me At, revenue only if.Web Directory right colocation, give latest technology we develop power.Playing World of, a sound business.,

Leave a Reply