November 15th, 2008

amused, happy
  • mart

When hCard meets XFN

hCard is a microformat for encoding the contact information for a person, company, organisation or place. XFN is a microformat that uses URLs to represent people and links between those URLs to represent relationships.

If you've got a URL representing a person, how do publish the contact information for that person? An obvious answer is to include an hCard in the page returned at that URL. However, as far as I can tell there's no way presently to mark up the fact that a particular hCard on a page at a particular URL is the hCard of the person the URL represents, which I find to be an irritating disconnect.

Since I was unable to find any prior art for this, I'll make a straw-man proposal. On my main website I've had for some time my basic contact information marked up with hCard. To support discovery of my hCard, I added id="contactinfo" to the element that holds the vcard class and then added the following to <head>:

<link rel="me" href="#contactinfo">

My intent here is to say that the element with the id "contactinfo", which in this case is an hCard, represents the same person as the page as a whole. This technique could be used for any other person-related microformat too, such as perhaps an hAtom feed of a person's activity stream. (though rel="alternate" might make more sense in this case.)

This seems like a nice, straightforward way of filling this missing link. If there's an existing practice I missed then please let me know, or else I'd love to hear feedback on this approach.

amused, happy
  • mart

The representative hCard for a Page

In my previous entry I mentioned that I couldn't find a way to go from an XFN-discovered URL to an hCard describing the corresponding person. It turns out that David's response was correct: there is a way to do this already. The catch is that rather than linking from the page to the hCard, it instead links from the hCard to the page. The fact that I already had half a solution in my mind when I was searching for existing practice prevented me from finding this one. Mea Culpa, I guess.

This is, however, a good example of what I consider a failure in the design of some Microformats. For me, the big advantage of Microformats over other data publishing mechanisms is that I just need to add a few adornments to data I'm already publishing, so I can add Microformats support quickly with no visual or structural impact on my page. This approach for marking "representative hCards" fails to deliver on this promise: my page doesn't have a link to itself. Why would it? You're already there!

This does draw my attention to something I hadn't noticed before: the hCard on my site doesn't contain my URL, so if you export it using existing tools you won't get the URL field populated. I'm loathe to put a self-referential link on my page, since that'd be confusing. It feels like hCard parsers should be able to infer that my URL is the current page URL having determined that this is the representative hCard... but of course, as currently specified, it can't determine whether it's the representative hCard unless I publish that self-referential link.

I've posted the proposal from my previous entry on the Microformats mailing list to see what the Microformats community thinks of it. I think it complements nicely the approach they're already recommending, allowing some additional possibilities that it can't support alone. It also doesn't invent anything new: the link element and rel="me" are being used to mean what their respective specifications say they should mean, and the hCard documentation already says that if a fragment is present in the URL the parser must look only within the identified element.