hCard Overflow: Could We Use rel-hcard?

I’ve been writing a lot about Microformats lately. The Microformats community is pushing hard for more and more developers to adopt Microformats in their semantic code. I’ve been wondering, though… are we “overmicroformatting”?For example, if you go to the Microformats search engine at Technorati and search for a very “connected” individual, you’re going to get inundated. Searching for me reveals a whopping total of one hCard. And that’s the hCard I’ve put on my About page. However, if you searched for Brian Oberkirch, you’d get 258 hCards. That’s a lot of hCards. In fact, I’m concerned that we may be over hCarding.

The first result of the 258 Oberkirchs is the Syndicate 2005 speaker list hCarded on Tantek’s site. This hit helps back up my two issues with overhCarding.

1. Incomplete Data

Brian, like all of us, has a lot of bits of contact information. Among them, he has a phone number. He has an email address. Heck, I’m sure he even has a mailing address. But none of them are included in the hCard on the Syndicate list. Should that data be included? Well, there’s really not much of a need for someone to care about the phone numbers and mailing addresses of every single speaker at a conference. But then, what’s the point of setting it in hCard if you aren’t collecting the person’s entire collection of contact information? There are likely some uses that I haven’t thought of, but the extraction example usually given for hCard is to convert to vCard and add the person to your address book. What good are vCards in your address book without proper contact information? But at the same time, what good is being inundated with contact information on a conference speakers list?

2. Data Evolves

The hCard downloaded from the Syndicate speaker list has Brian’s organization as “Weblogs Work” and his title as “host of the Slidell Hurricane Damage Blog and CEO”. Well, Brian is no longer with Weblogs Work. He’s gone solo. And while he was the host of the Slidell Hurricane Damage Blog, that is still hosted with Weblogs Work, with whom Brian is no longer associated. So, when someone changes jobs, email addresses, or phone numbers, all of this hCarded data on the web is then obsolete.

What to do?

A Solution?

I’m no Microformats expert, but I wanted to brainstorm a potential solution to go with this question I’m raising. The solution I came up with is:


Rel-hcard would be very similar to rel-tag, rel-nofollow, or rel-license in that it is simply an attribute of a URL. Rel-hcard would allow developers to link an appearance of a person’s name on a web page to his/her own personal hCard on his/her own site. This way, if the person’s contact information changes, the site always links to the most recent information. Also, you don’t have to provide information about that person that really isn’t needed on that page. You can simply list the name and a link to that person’s hCard.

On the Syndicate 2005 speaker page, each speaker is marked up as a row in a three column table. The first column contains the speaker’s name linked to the speaker’s bio on the Syndicate site. The second column contains the speaker’s title and the third contains the speaker’s organization. Like so:

<tr class="vcard"><td><a class="linkType fn url" xhref="http://www.syndicateconference.com/live/38/events/
38SFO05A/conference/bio//CMONYA00BEAU">Brian Oberkirch</a></td><td class="title">host of the Slidell Hurricane Damage Blog and CEO</td><td class="org">Weblogs Work</td></tr>

So, one flaw that I see with my approach is that it requires a separate link. So, since Brian’s name is already linked to his bio page on the Syndicate site, we can’t link to his hCard with his name. I can think of a couple of ways around this.

The first involves creating a second link that we then hide with CSS (using {display: none}). Like so:

<tr class="vcard"><td><a class="linkType fn url" xhref="http://www.syndicateconference.com/live/38/events/
38SFO05A/conference/bio//CMONYA00BEAU">Brian Oberkirch</a><a class="contactinfo" rel="hcard">(Contact Info)</a></td><td>host of the Slidell Hurricane Damage Blog and CEO</td><td>Weblogs Work</td></tr>

You’ll notice a couple of things. First, I stripped out the class names for the title and organization. That’s because if we’re using a rel-hcard, there would be no need to mark up this information. The HTML would basically be a timestamp of the person’s contact information at the time it was published. The current, up to date hCard would provide the most recent contact information in the correct hCard markup.

You will also notice the second link in the first column (Contact Info). It is given the class “contactinfo”. That class can then be styled to display as none. So, is it bad that it’s still in the markup but not displayed on the page? Personally, I don’t think so. Those viewing unstyled content are probably not going to have Microformat parsers available to them. This way they can see that there is a link to the person’s complete contact information.

Alternately, the speaker table could be modified so that the speaker’s name is linked to contact information (with rel=”hcard”) and another column is added with that speaker’s sessions (and links to them). The title and organization columns could stay, though I wouldn’t mark them with “title” and “org” Microformat classes. I’d leave that to the hCard we’re linking to.

Does this make sense? Has this already been brought up in the Microformats community? Is there already a solution? This is similar to rel=”url” except that this would specifically tell parsers that the link contains an hCard. Perhaps this is encroaching on some of the work underway with OpenID, but this solution is one using pure Microformats.

Update: Brian Oberkirch has dubbed this “The Darowski Problem”.


  1. On January 23rd, 2007 at 2:14 pm OpenID, Portable Social Networks and the Darowski Problem at Like It Matters said:

    [...] I can also use OpenID to overcome what I’ll call the Darowski problem, after Adam’s post on this. The problem is managing the proliferation of identity information. Adam gives the example of finding 258 hCard listings for me using Technorati’s microformats search engine. With OpenID, I could anchor an hCard on my site and tell search engines and other services that this is the ‘gold’ hCard I want used for my contact information. What I change here should be thought of as current, and I want all services to pull from that. [...]

  2. On January 25th, 2007 at 2:26 pm Nick Peters said:

    I agree 100% with you! I think that over-hcarding leaves for a lot of incomplete and inconsistent data. In order to solve this, a person’s information has to be consolidated to one source. I also had the idea of using a rel-hcard, but I feel that the use of OpenID is the way to go. I’m currently researching it, but I think you can store personal information about yourself on the OpenID server, retrieve that information and then turn that into an hCard.

  3. On January 25th, 2007 at 2:55 pm Adam Darowski said:

    Hey Nick, thanks for stopping by. Did you see Brian’s link at the end of my post? He not only presents a very elegant solution, but also has a series of links for more research.

  4. On January 27th, 2007 at 11:19 am Stephen Paul Weber said:

    Some services (such as Wikidentity) also intelligently determine if two hCards are the same person and combine them in the search results (ie, searching for people instead of single hCards)

  5. On January 27th, 2007 at 7:27 pm Adam Darowski said:

    Hey Stephen… I wasn’t familiar with Wikidentity… looks pretty cool. I guess as apps start being developed, they will become even smarter in terms of combining data. Perhaps checking timestamps to find the most recent data, etc.