[uf-discuss] A (big) problem with XFN: identity of source and target not findable

Costello, Roger L. costello at mitre.org
Tue Mar 18 04:31:10 PST 2008


Hi Folks,

Flickr uses XFN.  Here is a sample Flickr page that uses XFN:
http://www.flickr.com/people/tantek/

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">
    <img
src="http://farm3.static.flickr.com/2146/buddyicons/24172116@N08.jpg?12
03935044#24172116 at N08" 
         alt="Jolene_A" width="48" height="48" /><br />
    Jolene_A
</a>

Notice the use of XFN: >>> rel="contact" <<<

Metafilter also uses XFN.  Here is a sample page that uses XFN:
http://www.metafilter.com/usercontacts/292

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?

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
relationship?

Examine the above snippets of code.  Does 1. and 3. pop out at you?
That is, do you know who are the individuals that are the source and
target of the relationship?

That information "can" be found on the Flickr and Metafilter sites, but
each site does it *differently*.

So, the problem with XFN can be stated as this: While XFN does a great
job of providing a set of relationship values (friend, contact,
co-worker, etc), it provides no means for the automated discovery of
the individuals that are the source and target of the relationship.
Without information about the source and target individuals, the
relationship information is not very useful.

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.

Conversely, consider FOAF.  Advogato is a social network that uses
FOAF.  Here an example FOAF on that network:

http://www.advogato.org/person/connolly/foaf.rdf 

At the browser menu select View >> Page Source to see the actual FOAF
document.  Notice that the individual who is the source of the
relationship is clearly listed at the top of the document:

<foaf:name>Dan Connolly</foaf:name>

And the individual who is the target of the relationship is clearly
identified:

    <foaf:knows>
      <foaf:Person
rdf:about="http://www.advogato.org/person/jtauber/foaf.rdf#me">
        <foaf:nick>jtauber</foaf:nick>
        <rdfs:seeAlso
rdf:resource="http://www.advogato.org/person/jtauber/foaf.rdf"/>
      </foaf:Person>
    </foaf:knows>

The downside of FOAF is the only built-in relationship is "knows", e.g.
"Dan Connolly knows James Tauber." That is, FOAF doesn't possess the
richness of expression in terms of relationships. (I know, there are
extensions of FOAF to express more than "knows," but as far as I can
tell, no social network is using those extensions)

The upside of FOAF is that all three pieces of information are
available to a spider application:

1. The source individual (e.g. Dan Connolly)

2. The relationship ("knows")

3. The target individual (e.g. James Tauber)

I don't see any solution to the problem with XFN.  As far as I can see,
social networks using XFN cannot be processed by spiders.  Only social
networks that use FOAF can be processed by spiders.  Bummer. 

Hopefully, I am missing something.  I really like the simplicity of XFN
and its rich set of relationships.

/Roger

 



More information about the microformats-discuss mailing list