Exploration

In our post-game analysis, Tantek and I felt that the Developers Day track on microformats went incredibly well. Not only did we get a lot of good feedback, I think we turned a lot of heads. The ideas we presented stood up to initial scrutiny by a pretty tough crowd, and our demonstrations of the already-deployed uses of formats like XFN, like XHTMLfriends.net and an automated way to subscribe to hCalendars and hCards, drew favorable response.

Even better, our joint panel with the Semantic Web folks had a far greater tone of agreement than of acrimony, the latter of which I feared would dominate. I learned some things there, in fact. For example, the idea that the Semantic Web efforts are inherently top-down turns out to be false. It may be that many of the efforts have been top-down, but that doesn’t mean that they have to be. We also saw examples where Semantic Web technologies are far more appropriate than a microformat would be. The example Jim Hendler brought up was an oncology database that defines and uses some 600,000 terms. I would not want to try to capture that in a microformat—although it could be done, I suspect.

Here’s one thing I think is key about microformats: they cause the semantics people already use to be impressed onto the web. They capture, or at least make it very easy to capture, the current zeitgeist. This makes them almost automatically human-friendly, which is always a big plus in my book.

The other side of that key is this: it may be that by allowing authors to quickly annotate their information, microformats will be the gateway through which the masses’ data is brought to the more formal systems the Semantic Web allows. It very well may be that, in the future, we’ll look back and realize that microformats were the bootstrap needed to haul the web into semanticity.

Tantek and I have had some spirited debates around that last point, and are actually in the middle of one right now. After all, maybe things won’t go that way; maybe microformats will lead to something else, some other way of spreading machine-recognizable semantic information. It’s fun to debate where things might go, and why, but I think in the end we’re both willing to keep pushing the concept and use of microformats forward, and see how things turn out down the road.

What’s fascinating is how fired up people get about microformats. After SXSW05, there was an explosion of interest and experimentation. Several microformats got created or proposed, covering all kinds of topics—from folksonomy formalization to political categorization. A similar effect seemed to be occurring at WWW2005. One person who’s been around long enough to know said that the enthusiasm and excitement surrounding microformats reminded him of the early days of the web itself.

As someone who’s at the center of the work on microformats, it’s hard for me to judge that sort of thing. But I was there for some of the early WWW conferences, and I remember the energy there. As I rode home from WWW2 in Chicago, I was convinced that the world was in the process of changing, and I wanted more than anything to be a part of that change. To hear that there’s a similar energy swirling around something I’m helping to create and define is profoundly humbling.

That all sounds great, of course, but if it remains theoretical it’s not much good, right? Fortunately, it isn’t staying theoretical at all, and I’m not just talking about XFN. Want an example of how you could make use of microformatted information right now, as in today? That’s coming up in the next post, where I’ll show how to make use of a resource I mentioned earlier in this post.

Ok, I’m convinced microformats have the potential to add a lot more machine-readable data to the Web. But one thing I’m still not sure about is the claim that the docs are easier to create than plain XML or RDF/XML.

To author microformat docs you need to identify which data goes in which fields, whether that’s through using separate text areas or inline markup of some kind. The way that information is recorded in the microformats happens to be as CSS attributes. But couldn’t the same info be recorded as plain XML just as easily? Ok, most (X)HTML editors for static docs include CSS editing, but if you’re dropping to a heavyweight editor, wouldn’t you be better off using something more geared towards data than presentation?

I suppose the bit that gets me is around “adapt to current behaviors and usage patterns, e.g. (X)HTML, blogging” – but what proportion of blogging tools allow per-post CSS editing? The current behaviour in most tools I’ve seen is to partition up the data in a form or whatever before it goes in the DB, then the XHTML view is templated from that, as is a “pure data” version, the RSS. It would be no more difficult to template the output as a microformat doc as a custom XML or RDF/XML doc.

Please tell me if I’m missing something obvious, but I really can’t see any significant simplification at the producer side, certainly nothing that outweighs the added complication at the comsumer side, having to extract the data from XHTML.

But like I said at the start, microformats do offer an additional route to machine-readable data and that gets my support.

Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...