[uf-discuss] A (big) problem with XFN: identity of source and
target not findable
davidjanes at blogmatrix.com
Tue Mar 18 06:11:52 PST 2008
I've been working on a social network browser recently and I was
preparing to write a blog post called "XFriendN or FOAF (or API)" on
what I learned, so I have a few relevant comments. Don't expect I
narrative flow to this e-mail, it's a bit of a brain dump ;-)
On Tue, Mar 18, 2008 at 8:31 AM, Costello, Roger L. <costello at mitre.org> wrote:
> Hi Folks,
> Flickr uses XFN. Here is a sample Flickr page that uses XFN:
> At the browser menu select View >> Page Source. Then search for rel=
> Here's an example usage of XFN within that Flickr page:
> <a href="/photos/24172116 at N08/" rel="contact">
> 03935044#24172116 at N08"
> alt="Jolene_A" width="48" height="48" /><br />
> Notice the use of XFN: >>> rel="contact" <<<
Please see Chris Messina's post from last week . Interestingly, he
came to the same conclusion I had just the day before -- there's
basically only "me" and "contacts" and the reset is gravy. In my
browser application, I normal all the relationship into one of these
two types (I keep the original relationships, of course).
There's a deeper problem with the Flickr XFN results -- it's _paged_,
which is totally a nuisance. In this particular case it was easier for
me go to the Flickr API to get the contacts than use the XFN data. It
would be nice if they offered a pared down page with only XFN results.
As an aside, it occurs to me now that we can indicate paged results by
add rel="me next" and rel="me prev" to the page navigation links.
> Metafilter also uses XFN. Here is a sample page that uses XFN:
> Here's an example usage of XFN within that page:
> <a href="/user/10411" rel="colleague" target="_self">40 Watt</a>
> Notice the use of XFN: >>> rel="colleague" <<<
> Now, suppose that I wanted to create a spider application which crawls
> all social networks that use XFN. Most likely, I would want the spider
> to collect:
> 1. Who is the source? That is, who is the individual using XFN to
> state a relationship?
Trivially, the page "http://www.metafilter.com/usercontacts/292" is
"me". However, I realize how unsatisfactory an answer this is! Let me
make three comments here:
1. As a _recommendation_ -- and microformats really need to make a lot
more recommendations IMHO -- I would suggest that the page should
should have a link <a href="http://www.metafilter.com/user/292"
rel="me">...</a> at a minimum.
Note then that if you navigate then to that home page, there's a whole
bunch of natural candidates for rel="me" links: all the other links
2. Extending that thought, they really should have a full hcard
wrapped around the "me" link: this would be the profile of "jessamyn".
You've now got the profile and the contacts on the same page and are
in FOAF-functionality territory.
3. In practice, it's nice to know all sorts of me links even though
the user hasn't explicitly done this with "me" links. Google has
created a concept of "canonicalization"  that can convert a sorta
arbitrary URI into a standard representation -- and then convert that
back into home, profile, contacts, rss, atom links. Interestingly
enough, metafilter is not in their code, though Flickr is. Plugging
tantek's flickr page into my browser gives tons of results, but
Canonically we figure out that this is "me" for tantek on Flickr.
I've re-implemented this in Python, though probably not quite to the
standard of Google's JS code.
4. I hate the fact that we've never solved the canonical hCard problem
(search the archives). I can't afford to visit tens of links just in
case there's something interesting on the other side! I think that as
I produce XFN information in the future (e.g. ) I'm going to add
rel="me X" to links, where X is one of "profile", "atom", "rss",
"contacts" ... i.e. the terminology that Google uses for describing
important pages ... and see if this goes anywhere.
> 2. What is the relationship? This is, of course, obtained easily from
> the value of the rel attribute on the link.
> 3. Who is the target? That is, who is the other individual in the
See previous ;-)
> You might argue: "Well, the XFN *should* be embedded within an hCard,
> then you can discover who the source individual is. And the target
> page should contain an hCard, then you can discover who the target
> individual is." And I agree that is Best Practice. Unfortunately,
> this is not mandated and consequently many people don't do it. For
> example, Flickr and Metafilter don't do it. Nor do any of the other
> social networks do it.
On the same page here as you. However, these guys do use XFN + hCard.
Digg, weirdly enough, uses hCard but not XFN :-(
> Conversely, consider FOAF. Advogato is a social network that uses
> FOAF. Here an example FOAF on that network:
FOAF is, quite frankly, an ugly mess. This, based on my experience of
trying to code to extract useful information out of it rather than
just an opinion I pulled out of the air. I spent way to many hours
coding trying to pull info out of FOAF because, well, things seem to
be doable in lots of different ways.
People don't want a format does _anything_; people want a format that
FOAF needs recommendations more than XFN does. Here's the sample set
of FOAF files I worked with:
I've uploaded N3 serializations of two of these to here:
Note the different way things such as "weblog" are wrapped -- there's
some sort of intermediate node being placed on the Hi5 links. Why? I
dunno, but it doesn't make pulling out 'img', 'weblog' etc. links with
SPARQL particularly easy. Maybe there's some magic way to do this, but
there's only so much digging I'm willing to do.
And someone can ask the people at livejournal what 'foaf:image' is, or
everyone else what 'foaf:img' does.
> Hopefully, I am missing something. I really like the simplicity of XFN
> and its rich set of relationships.
I had a great time coding the XFN stuff -- I wrote one piece of code
that extracts all the A.rel links, another that pulls out all the
hCards, and another that matches them up and I was done.
Can probably show you guys a demo by the end of the week if you're
interested ;-) Here's  a screen shot.
More information about the microformats-discuss