When I gave my somewhat pretentiously entitled talk at XTech—Microformats: The Nanotechnology of the Semantic Web—I stretched the whole nanotech metaphor to its limit. One of the things I talked about was grey goo. I was referring to the danger of there being a microformat for everything. As has been said many times, if in two or three years there are hundreds of microformats then we will have failed.
There’s a danger of grey goo from another quarter: the temptation to unnecessarily extend existing microformats. This is something that has come up a few times on the microformats-discuss list. I believe that this temptation can be battled using the same prophylactic that protects the web from an over-infestation of microformats… The Process (cue dramatic music).
The first question to answer is whether or not there is a real problem to be solved. Remember that microformats operate on the 80/20 principle so if I proposed extension doesn’t apply to around 80% of use cases and requires more than 20% extra effort, then the price is too high.
The next step in the process is to look at whether an existing format already solves the problem. In my experience, this is the point at which the call for potential extensions can be resolved by casting the microformat net a little wider.
Here’s a recent example that came up on the mailing list…
Why not extend hCard to add a “date of death” field?
Now, first of all, I don’t think that this is a common use case but let’s set that aside for the moment and concentrate on whether it makes sense to add a new field to the hCard spec.
hCard is a one-to-one mapping of vcard to HTML and vcard doesn’t have a “died” field. There is, however, a bday for date of birth. So it doesn’t seem unreasonable to ask for a corresponding field for date of death. Here, for example, is the hCard for an historical figure that encodes a birth date but there’s no way of encoding the date of death:
<p class="vcard">
<span class="fn">Robert Hooke</span>
was born on
<abbr title="1635-07-18" class="bday">
July 18, 1635
</abbr>
and died on
March 3, 1703.
</p>
As it turns out, this is unnecessary. There’s already a format for encoding start and end dates. That format is hCalendar. If you reconsider a person’s life as an event, then you can encode birth and death:
<p class="vevent">
<span class="summary">Robert Hooke</span>
was born on
<abbr title="1635-07-18" class="dtstart">
July 18, 1635
</abbr>
and died on
<abbr title="1703-03-03" class="dtend">
March 3, 1703
</abbr>.
</p>
Now you’ve successfully encoded the event data but you aren’t explicitly marking this up as being a person.
One of the design principles of microformats is that they can be embedded within one another. So there is no reason why you can’t combine a person with an event like this:
<p class="vcard vevent">
<span class="fn summary">Robert Hooke</span>
was born on
<abbr title="1635-07-18" class="dtstart bday">
July 18, 1635
</abbr>
and died on
<abbr title="1703-03-03" class="dtend">
March 3, 1703
</abbr>.
</p>
Et voila! Now you’ve encoded the date of the person’s death without unnecessarily extending hCard.
The trick is not to get too fixated on using a single format. Use the right tool for the job.
It’s kind of like the situation with front-end development. There are three separate technologies, each one with its own purpose:
- HTML for structure.
- CSS for presentation.
- DOM Scripting for behaviour.
Here too there’s a danger of trying to overextend a technology beyond its purpose. Hence the call for “CSS-only” fly-out menus and JavaScript that generates page content.
Thinking about it, the existence of a bday field in hCard is kind of like the :hover pseudo-class in CSS. Putting event data into a format for contact details is as slippery a slope as putting behavioural controls into presentation.
As soon as you stop fixating on trying to encode everything in one single format then a whole world of possibilities opens up with microformats simply by embedding them within one another. The proposed hResumé format is an amalgam of existing microformats: skills marked up with rel-tag, previous jobs marked up with hCalendar, and so on.
Likewise there’s been a call for a genealogy microformat. But I think that the information required for a family tree—at least for the 80/20 situation—can be handled with a combination of existing microformats:
- hCard for people,
- hCalendar for lifespans and
- XFN for relationships.
I really enjoy coming up with unexpected combinations of microformats. It’s as if the semantic information is increased exponentially.
Staying with the hCard/hCalendar example above, suppose I used Robert Hooke’s Wikipedia entry as the url field:
<p class="vcard vevent">
<a class="fn url summary"
href="http://en.wikipedia.org/wiki/Robert_Hooke">
Robert Hooke
</a>
was born on
<abbr title="1635-07-18" class="dtstart bday">
July 18, 1635
</abbr>
and died on
<abbr title="1703-03-03" class="dtend">
March 3, 1703
</abbr>.
</p>
Because of Wikipedia’s tag-space URLs, I could tag the current document with “Robert Hooke” by adding rel-tag:
<p class="vcard vevent">
<a class="fn url summary" rel="tag"
href="http://en.wikipedia.org/wiki/Robert_Hooke">
Robert Hooke
</a>
was born on
<abbr title="1635-07-18" class="dtstart bday">
July 18, 1635
</abbr>
and died on
<abbr title="1703-03-03" class="dtend">
March 3, 1703
</abbr>.
</p>
And seeing as I greatly admire Robert Hooke I can also encode his relationshipto me as “muse”:
<p class="vcard vevent">
<a class="fn url summary" rel="tag muse"
href="http://en.wikipedia.org/wiki/Robert_Hooke">
Robert Hooke
</a>
was born on
<abbr title="1635-07-18" class="dtstart bday">
July 18, 1635
</abbr>
and died on
<abbr title="1703-03-03" class="dtend">
March 3, 1703
</abbr>.
</p>
hCard, hCalendar, rel-tag and XFN all together in a single sentence. Microformats are interesting enough on their own but they get really powerful when you mash them up together.