Before I can write up my proposal for transcending social networks, I need to clarify the originating and destination scopes of XFN links.
It’s currently understood that XFN links describe personal relationships between two URLs.
Typically the endpoints of XFN links are URL-centric personal blogs (i.e. horsepigcow.com or tantek.com), but not always. And because we can’t always assume that the outgoing linker speaks for the whole URL, or that the destination linkee is all inclusive, we need a set of standard criteria to help us determine the intended scope of the originating linker.
Put another way, how can we better deduce who is XFN-linking to whom?
Let’s take a concrete example.
The established XFN protocol states that when I XFN-link from my blog at factoryjoe.com to horsepigcow.com, that I’m describing the relationship between me and Tara Hunt, and our blogs act as our online proxies. Readers of our blogs already know to equate factoryjoe.com with Chris Messina and horsepigcow.com with Tara Hunt, but how can computers tell?
Well, if you check our source code, you’ll find an hcard that describes our contact information — marked up in such a way that a computer can understand, “hey, this data represents a person!”
If only things were so simple though.
If I linked to Tara and there were only one hcard on the page, you could probably assume that that single hcard contained authoritative contact details for her since knowing that Tara blogs at horsepigcow.com there’d be a good chance that she put it there. Sure enough, in her case, the hcard on horsepigcow.com does represent Tara.
Now, flip that around and let’s have Tara XFN-link back to my blog. This time instead of one hcard, she’ll most certainly find more than one hcard, and, most perplexing of all, most are not me, but rather people for whom I’ve marked up as hcards in my blog posts.
So, if you’re a computer trying to make sense of this information to determine who Tara’s trying to link to, what are you to think? Which relationship is she trying to describe with her link?
Well, as a stop-gap measure that I think could be easily and universally adapted to add definitiveness to any arbitrary hcard at the end of an XFN link, I propose using the <address> tag. Not only has this been proposed before and not been overruled, but it is actually semantically appropriate. Furthermore, there are already at least a few examples in the wild, notably on my blog, Tara’s blog, and most importantly, Tantek’s.
Therefore, to create a definitive an authoritative hcard on any page, simply follow this example markup (note the self-referencing use of rel-me for good measure):
.code { border: 1px solid #ccc; list-style-type: decimal-leading-zero; padding: 5px; margin: 0; }
.code code { display: block; padding: 3px; margin-bottom: 0; }
.code li { background: #ddd; border: 1px solid #ccc; margin: 0 0 2px 2.2em; }
<address class="vcard" id="hcard"><a href="https://factoryjoe.com/blog/contact/#hcard" rel="me" class="fn n">Chris Messina</a>.</address>
At the destination URL, include a fragment identifier (#hcard) for the hcard with the complete contact information and add rel-self in addition to rel-me (as per John Allsopp’s suggestion):
<address class="vcard" id="hcard"><a href="https://factoryjoe.com/" rel="me self" class="fn n">Chris Messina</a>.</address>
This practice will primarily help identify who XFN-linkers intend to link to when pointing to a blog or URL with multiple hcards. In the event that no definitive hcard is discovered, the relationship can be recorded until later when the observing agent can piece together who owns the URL by analyzing secondary clues (rel-me or other hcards that point to the URL and claim it).
Oh, and I should note that from the standpoint of multi-author blogs, we should be able to scope XFN links to the author of the entry — with hAtom entry-author making this infinitely easier.
Factory Joe 
ADDRESSis of course optimal, but the fact remains that it cannot contain block level elements without triggering quirks mode in browsers, so you couldn’t ever mandate it for all hCards.Good point. I wonder if simply wrapping the “FN URL” object (linked name) would be sufficient — since at least you’d have the person’s name and URL.
Well, in my hCard I have
ADDRESSelements with it — wrapped around each contact address (IM, email and so on). In my experience that’s the best that can be done. Whether that’s of any help to parsers I’m not sure. It’s not as easy to imply meaning about the parent from its children.What’s more,
rel=me>is relative to the page, so in terms of identifying the definitive hCard for theaddressable owner of the page,rel=meimplies the relevant part of the same semantic even withoutADDRESS.Chris,
I think self actually suffices for a definitive reference as per the Atom spec from which it is reused by hReview and hAtom.
See my recent post to uf-discuss for more detailed reasoning.
j