Jennifer Golbeck talks of XFN Delusions of Grandeur. My own initial reaction to XFN was also negative. This was due to the microformats folks reinventing FOAF, apparently not very well, and the fact that they didn't distinguish between a person and a Web page. It just seemed too dumb to be much use.
Ryan King
responds
to Jennifer's post with some good points and some not-so-good:
One, microformats are designed for
"humans first, machines second". I'll nitpick on this, it
is a little misleading. XFN markup isn't really any more
human-friendly than FOAF's RDF/XML, and what's more without a
machine to interpret the stuff there's not much for the human
either way.
Two,
"why canââ¬â¢t URLs
be used to identify people?" - the problem Jennifer refers to
is that there's no distinction made between the Web page URL and
the human's URL. What happens if someone made a statement about the
URL, say providing its
dc:creator?
The use of a URI is questionable for the purpose in any case,
see
Identifying
things in FOAF.
Three,
"…at the time XFN was created, there was no useful,
machine-parseable, web-friendly way to encode personally
identifiable information in webpages." - well yes there was,
FOAF (ok, it's normally via a
<link> - but what problem does embedding the
data solve?). But now XFN is here, this isn't worth arguing
about.
One thing Ryan does get right is that this isn't really comparing like with like. XFN does use a simplistic view of relations (akin to blogrolls), and unlike FOAF doesn't give you the general ability to say anything about anyone. Ok, so far this all sounds very negative about XFN.
Read on…
What XFN can provide is useful machine-readable data when FOAF might not be available. For example, it seems to have been possible to convince the developer of WordPress to include XFN in the template, but there's no built-in support for FOAF (though it is only a matter of installing a plugin). But every user of WordPress is publishing XFN data from day one. So back to Jennifer's main point, what of that data? For a start XFN includes the following:
<head profile="http://gmpg.org/xfn/1">
That URI unambiguously declares that a particular metadata profile is in use. Given that, it's possible to automatically process such pages and extract the data. This is a Good Thing.
Another point is that although XFN might munge person and page, there's no reason for agents that use this data to do the same. Here's a page containing XFN, here's grokXFN.xsl and here's an XSLT service. Result: perfectly reasonable FOAF.
Yep, there are circumstances where XFN might not be suitable, where there might not be a simple 1:1 correspondence between a page and a person. What's more all XFN does is make some data available, there's no real interoperable model to allow you to do stuff with the data once you've got it. Convert it to FOAF RDF/XML and you've got all the Semantic Web loveliness. But basically in cases like the WordPress scenario, XFN can provide FOAF where it wasn't previously available. This is another Good Thing.
Are people likely to not use FOAF RDF/XML because XFN is available? Maybe. But where something richer than XFN is needed, FOAF is still available. I bet overall there's a considerable net increase in the amount of good data available thanks to XFN. So there's little to be gained from framing this as XFN vs. FOAF.
~
Where there is something to be gained is for people that want good data available to encourage microformat developers/publishers to use the profile URI. With it, you can parse the data. Without, we're back at scraping.
There's one more small step that could potentially make a lot of
difference. The use of XSLT to extract RDF data from XHTML is
great, and can potentially be applied to
any XHTML that contains explicit material. But only if you
know in advance which stylesheet to apply.
GRDDL describes a
technique by which the microformat profile page (referred to by the
profile URI) can identify which XSLT works with the
profile. Check the source of
xfn-workalike.html,
in particular the
<head>. That's not a lot to ask, is it? Remember
this is only needed *once* in the profile document, no change is
needed to individual microformat docs, they just need the profile
URI.