[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
http://target.website/
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