I can’t help but like microformats, and part of that comes from the dogmatic principles that drive them. Among those is the notion that none of us should attempt to create a format out of whole cloth. Here’s how they explain it:

Under the title of “Propose a Microformat” they tell us: “Actually, DON’T!!!”

ask yourself: “are there any well established, interoperably implemented standards we can look at which address this problem?”

Why? The dogma here is to “pave the cowpaths:”

It’s quite possible [...] that you’ll find someone else who has dealt with the problem you’re addressing. Perhaps even solved it. Do your best to open a dialog with others who have encountered the same problem. We don’t want to build walls between competing communities — we want people to work together to develop a good solution which will cover the majority of cases.

Now think about this in the context of libraries. Think about it in terms of our acquisitions workflow, think about it in terms of our online catalogs. Break down the walls that divide libraries from the rest of the world, look for and embrace larger standards, and benefit from the community of work that already supports them.

microformat, dogma, lessons, software development, standards, interoperability

Oliver Brown introduced me to microformats a while ago, the Ryan Eby got excited about them, then COinS-PMH showed how useful they could be for libraries, but I still haven’t done anything with them myself (other than beg Peter Binkley to release his COinS-PMH WordPress Plugin).

What are microformats? Garrett Dimon explains the theory:

When writing markup against deadlines and priorities, it’s easy to forget that somebody else will eventually have to maintain it. Conveniently, some of the central ideas behind microformats revolve around the fact that they are designed for humans first and created with simplicity in mind. This means you’ll have markup that is easy to understand and maintain for everyone, including:

• The engineer integrating your code next week
• You updating your code next month
• The new guy taking over your job when you get promoted next year

Basically, microformats suggest the use of common class names for various XHTML elements. As it turns out, the hCard microformat is a convenient way of representing the data from vCards in XHTML. The convenience is by design, of course. Here’s an example:

<div class=“vcard”>
<a class=“url fn” href=“http://maisonbisson.com/”>Casey Bisson</a>
<div class=“org”>MaisonBisson</div>
</div>

By standardizing the class names for this content, it’s easier to share and maintain stylesheets, re-use content, and read the content programatically. Perhaps most importantly, it offers valuable tips to search engines crawling your site about what the data is, making it more findable.

The principles of microformats are such:

• solve a specific problem
• design for humans first, machines second
• reuse building blocks from widely adopted standards
• modularity / embeddability
• enable and encourage decentralized and distributed development, content, services

The potential here for libraries is huge, but we should take seriously the caution that microformats be easy to use and the design rule that it be simple.

microformat, networked information, semantic web, microformats, library, libraries, metadata, data standards