B. Mann Consulting

In my continuing quest to understand and try to explain where microformats fit, I think I have three use cases of syndicating "beyond blogging" content. This means, content/data which has semantic information attached to it -- events, people, etc. etc. I'm probably using the phrase "semantic information" wrongly -- call it rich data or structured blogging, it's content that goes beyond base textual description and is "data" that has meaning.

For the most part, I'm only considering generated content. People that want to hand-code individual pages will fall into the first use case of embedded rich data.

This is a work in progress. I may make changes inline and/or integrate comments directly.

1. Text/HTML blobs with embedded rich data

   Considering as I am not a fan of RDF for no particular reason, this seems the best use case for microformats -- easily accomplished even by having little saved snippets in your composing tools.

2. First-class data model support (XML flavoured)

   This use case is where a platform/web app supports events or people natively, e.g. there are event and people data objects which you can create/display directly. The type of application which would have first-class support might be an online address book (example?) or calendaring program (e.g. WebCalendar).

   Tantek has had some feedback that it may be easier to, e.g., generate an hCalendar display and then use a proxy to transform this into (in this case) vCal. I know that in Drupal, and I would think in other well-designed applications, it's easier or as easy to just generate a vCal file directly. Remote proxies involve a point of failure, and local proxies mean another app/more code to deploy. Code libraries which parse microformats or vCal etc. should be equally available.

   Microformats are good at the display layer, for presenting a uniform target for theming thanks to common classes. Crawlers optimized for XHTML might have an easier time parsing this, although just as crawlers can do conversion of binary formats such as PDF or Word to HTML/text, I imagine the same could be done with vCard.

3. Established format support

   Typically, every system that has native support for data models will also provide direct support for any non-RSS established formats. Calendars supporting iCal/vCal and address books supporting vCard are two good examples. Outlines supporting OPML is another example, although neither outlines nor the OPML format itself are nearly as widespread -- something that is likely to change rapidly due to Dave Winer's work with the OPML editor.

   These established formats are probably few and far between -- offhand, only something like Google's KML comes to mind, which is nothing more than a de-facto standard for interfacing with the Google Earth application. These formats are of course not directly human consumable -- clicking on an iCal button representing a webcal feed and/or ics file depends on the operating system to pass this on to local applications that support them.

So, in two out of three use cases, there are very compelling reasons to make non-microformat information available as well. Of course, we're mainly talking about event and person data, for which long standing formats exist that are consumable today by lots of systems, including desktop applications. My next post will cover some areas that are sorely in need of microformats.