[uf-discuss] XFN and hCards

David Osolkowski qidydl at gmail.com
Fri Dec 23 07:12:10 PST 2005

On 12/22/05, Ryan King <ryan at technorati.com> wrote:
> First of all, see the discussion here: http://www.microformats.org/
> blog/2005/11/02/xfn-grandeur/

Apologies, I hadn't seen that; it looks like I'm a little late on this
topic, so if I'm not contributing anything new feel free to shut me up.

> Identifying the target is a little more complicated.  Generally, we
> > should check the linked page for an <address> element, and assume
> > that linking to a page means relating to the author of that page.
> I'm not sure what you mean by the last part above.

Well, the microformats blog post talks about using URLs as a proxy for
people.  If a page at a URL includes an <address> element, it seems safe to
assume that the content of that <address> element would be a representation
of the person that the URL is a proxy for.

Suppose http://source.website/blogroll.html includes an XFN link to
http://target.website/.  If http://source.website/blogroll.html contains an
<address> element, the content of that element would be the obvious
representation of the person on the source side of the XFN relationship.  If
http://target.website/ contains an <address> element, the content of that
element would be the obvious representation of the person on the target side
of the XFN relationship.  But... (see below)

> If that assumption is incorrect, the source could link directly to
> > an hCard ( i.e. http://www.example.com/page.html#hCard).  This
> > requires the hCard to have an id, which makes things a bit
> > trickier; what should the source do if the hCard does not have an
> > id?  When publishing hCards, how do you know whether they'll need
> > ids?  Is this situation within the 80%?
> You can certainly use XFN links to link directly to people's hCards.

Well, the tricky situation I was trying to describe is, what if the target
is an hCard on a page not authored by the person in the hCard? Suppose
is authored by Joe Schmoe, but http://target.website/#wife is Jane Schmoe's
hCard.  If someone links to http://target.website/#wife with an XFN
relationship, the general case says it's a link to Joe, even though the
intention may be to link to Jane.  I don't know if this is a common
practice, or a theoretical edge case, or something that is currently rare
but could become common practice as hCard/XFN are more widely deployed (need
to find the cowpaths).  This may be more of an issue for tools than for
people authoring websites.  I don't consider myself experienced enough to
make these decisions.

But, honestly, I think the two concerns: 1) annotating social
> connections and 2) identifying people are separate concerns in terms
> of formats/technology.
> XFN and hCard do different things. Together they can be very useful,
> but "identifying authors of pages" is a concern that stands on its
> own, apart from XFN.

Indeed, that's why I intended to present this as "best practices when using
the formats," as opposed to "changes to the formats."  It's a combination of
XFN, hCard, and identifying the person that a URL represents.  XFN links the
URLs, hCards represent the people, I'm just trying to fill in the
(perceived?) gap between the URLs and the hCards.

I don't know if it needs to be explained on gmpg.org . Perhaps someone
> could start a wikipage to document these best practices?

Well, at the least gmpg.org should probably link to the wiki page.  "XFN
works best when used as explained on [this wiki page]."  How about the name
"social-networking-practices" for the wiki page?  I can try to draft
something up during the weekend.

Just remember that just because two technologies get lumped together
> in an application doesn't mean they should be conflated in their
> specifications.

Agreed.  I do not wish to change XFN or hCard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051223/48bfae28/attachment.htm

More information about the microformats-discuss mailing list