Posts Tagged 'FOAF'

I like to FOAF you

No, it isn’t a proposition, so get your mind out of the gutter 🙂 FOAF stands for Friend-of-a-Friend and is a RDF taxonomy capable of describing a person and his/her friend(s) in far more glory details than XFN, in fact it is a competing standard. Reading your mind, you are probably going to ask me, what is RDF? RDF (first published specs in 1999) stands for Resource Description Framework which means absolutely nothing to most people however it is often touted as the foundation for the so-called semantic web. If you want a good introductory RDF post, check out What Is RDF. A synopsis of RDF extracted from this ReadWriteWeb post Semantic Web Patterns: A Guide to Semantic Technologies

RDF is a powerful, graph-based language for declaring things, and attributes and relationships between things. In a simplistic way, one can think of RDF as the language that allows expressing truths like: Alex IS human (type expression), Alex HAS a brain (attribute expression), and Alex IS the father of Alice, Lilly, and Sofia (relationship expression). RDF is powerful, but because it is highly recursive, precise, and mathematically sound, it is also complex.

On a high level, FOAF has the following categories

  • Person’s basic information such as name, nick, title, homepage, email, surname, first name, given name, email (expressed as mbox), etc.
  • Person’s extended information such as blog, interest, project, school home page, work home page, friend(s) he knows, etc.
  • Person’s online accounts (includes instant messaging)
  • Person’s projects and groups
  • Person’s documents and images

As you can see, it allows for extensive coverage of a person’s information. If you want the full details, check out FOAF Vocabulary Specification 0.91. Assuming you have a basic knowledge of XML, let’s take a simple example to illustrate how FOAF is actually written.


<foaf:name>John Doe</foaf:name>
<foaf:mbox rdf:resource="" />


The above XML snippet describes a person’s name and email, obviously John Doe is not a real name and is not a real email but you get the idea. Technically this describes a person, not the “me” identity as defined by XFN rel-me.

Let’s take a more slightly more complex example



<foaf:name>John Doe</foaf:name>
<foaf:mbox rdf:resource="" />
<foaf:mbox rdf:resource="" />
<foaf:name>Jane Smith</foaf:name>


Basically the above FOAF says there is a person John Doe, his email is, he “knows” Jane Smith, and her email is Note that “knows” does not necessarily equate to a friend, it simply means that you know someone, that person could be a friend, lover, co-worker, parent, sibling, or someone you met online but not in person, etc. For a more in-depth look at FOAF, check out XML Watch: Finding friends with XML and RDF.

Ok, now that you know how to create basic FOAF, what next. Unlike XFN / hCard / microformats, FOAF is delivered via a file separate from any HTML markup. Creating a FOAF file is not something that a Joe Blow user will ever do manually. However, if you are curious and want to play around with creating FOAF, you can use this handy tool FOAF-o-Matic. For most users, their service providers, the ones that support FOAF, will handle all the intricate details behind the scene. For example, if you have an account at MyBlogLog, you can check out their FOAF feature by appending “/foaf” to the end of your MyBlogLog member URL. If you aren’t a MyBlogLog member, here is Ken Brewster’s MyBlogLog FOAF file,, and check out his fun FOAF consuming app, picture below
Ken Brewster FOAF app

Since FOAF is a separate file, you have to link to it from a HTML page by adding the following HTML code within your <head> tag (using Kent Brewster’s FOAF URL)

<link rel="meta" type="application/rdf+xml" title="FOAF" href="; />

In MyBlogLog’s case, that HTML code is added automatically to a member’s profile page. I should note that in MyBlogLog’s case, the FOAF file is publicly available without any authentication allowing any search engine to crawl and index it, in fact, this information is available through Google Social Graph API but beware that there is a current limitation with Social Graph API in that Googlebot does not crawl a FOAF file linked from an HTML page, hence not making it available for the API to parse. In Brad Fitz own words,

I just verified that the problem is the crawl coverage. Historically Googlebot hasn’t cared about FOAF because it hasn’t used FOAF, so why hit your server fetching it just to throw it away? Now that the SGAPI is using it, though, I need to ask Googlebot to go get that FOAF that I know exists but is uncrawled.

A few parting thoughts…

  • Chris Messina thinks that FOAF baking in relationship information is a fundamental flaw, I have to respectfully disagree because I think it is a key missing feature from XFN/hCard, at least when it comes to my XFN consuming app. Upon further reflection, I think I understand Messina’s concern about FOAF being potentially convoluted. It is due to the powerful recursive nature of RDF that can lead to circular references and if a FOAF parser doesn’t account for this, it can lead to infinite loops.
  • Since FOAF only has a “knows” property, it is less descriptive, hence less useful, than XFN rel values (friend, acquaintance, co-worker, neighbor, sibling, parent, child, crush, date, etc)
  • Apparently FOAF does not have properties to specify an address, e.g.
    state/province, country, city, street address, quite odd indeed. However, it can be remedied by adding VCard namespace to RDF.

  • The general vibe in the web development community is that FOAF is more complicated than XFN so it is more likely to see XFN in the wild than FOAF
  • Firefox Operator plugin does not consume FOAF information
  • FOAF information is meant for app-to-app consumption unlike XFN / hCard which are embedded in HTML. Check out this post WordPress, FOAF, OpenID – updated for a WordPress plugin retrieving FOAF profiles when users authenticate a wordpress blog with OpenID.
  • There is a recent effort, hFOAF, to combine FOAF, hCard, and XFN

In the wild snapshot#1: Lessons from my XFN coding experiment

In an offline conversation with Chris Messina, we discussed the idea of creating blog-length interviews with various in the wild apps describing their processes and the technologies that they use with regards to data portability. The goal is to profile real use cases, solutions, and lessons learned when it comes to the current state of affairs for data portability technology. I am using the term “data portability technology” loosely here and is in no way affiliated with the ongoings of

So I am giving it a go and see what comes of it because we both think this kind of information can be useful to others looking to understand the lay of the data portability land. As such, I will title all such future posts starting with “In the wild snapshot…” as well as assign the category (WordPress terminology) of “in the wild snapshot”. If any of you are interested in doing such an interview, leave a comment on here and I will get in touch with you. Note that these posts are generally meant for web developers but everyone is welcomed to read it of course.

First up, I interviewed myself on my recent XFN coding experiment, neat how that works.

Application Overview
Given the abundance of XFN producers available, I wanted to create a XFN consuming application instead. If you need an introduction to rel-me and XFN, check out my earlier post here. The basic idea is to extract XFN information from a URL and present it in a human readable form, in my case, grouping rel-me entries into “My Online Identities” and rel-contact entries into “My contacts”, that’s it, pretty simple thing to do.

Technology considered: XFN, FOAF, Javascript, JSON, DOM, server side platform (like Ruby on Rails, etc), Google Social Graph API, Google Social Graph Test Parser, lab.backnetwork ufXtract microformats parser

Technology used: XFN, Javascript, JSON, DOM, CSS, lab.backnetwork ufXtract microformats parser

To begin with, I considered client side (Javascript, JSON, DOM, CSS) vs. server side (Ruby on Rails) platforms and went with client side technologies primarily because I had a good example client side app to start with, courtesy of Kevin Marks (OpenSocial advocate and microformats founder). You will notice the very similar layout and fonts, I like to reuse code.

The next question is selecting an appropriate XFN parser. I can either try to find some Javascript library or write my own or use a 3rd party service. To make things easier, I decided to go with a 3rd party service. I have 2 choices to pick from 3rd parties, lab.backnetwork microformats parser and Google Social Graph API. I decided to use lab.backnetwork parser primarily because it parse pages in real-time whereas Google Social Graph API only parse pages crawled by Googlebot which can result in data staleness. With lab.backnetwork parser, I used the JSON callback to process the JSON data structure passed back by the parser. Once I have the JSON data, I then sliced and diced it to dynamically generate additional HTML using Javascript, DOM, and CSS.

If you want more details on how to use Javascript to call the lab.backnetwork parser, check out this excellent post Javascript badges powered by JSONP and microformats. Extracted from the post, here’s the script tag code calling lab.backnetwork parser

var script = document.createElement('script');
script.type = "text/javascript";
Badge.obj = badge;
script.src = "" + escape(link.href) + "&format=xfn&output=json&";

Lessons learned
As a newcomer to XFN, this is a good way, at least for me, to learn about XFN. lab.backnetwork parser works pretty well for extracting XFN information especially since it provides real-time parsing. However, unlike Google Social Graph API, it doesn’t currently parse FOAF. FOAF is a competing standard to XFN but can be used in conjunction with XFN. Here’s a post about XFN and FOAF. From the few profile pages I have seen, it is possible for people to use both XFN and FOAF. For example, on such a profile page, XFN is used to markup the multiple rel-me identities and FOAF (in a separate file) is used to list all his friends. However in other profile pages, FOAF is skipped altogether. It doesn’t appear that there is a best practice published on how to mix and match the various technology.

Another issue I ran into is parsing and displaying human readable names for XFN URLs. As it stands, XFN allows one to define relationship between oneself and friends all centered around the URLs. However, URLs are not designed for optimal human readability, some URLs are long and unruly and others employ the use of proprietary internal naming scheme, e.g. (actual site names changed to protect the innocent),

The reason why I think it is important to couple human readable names with URLs is that a consuming app usually wants to do something meaningful with the XFN information and URLs alone does not provide complete information resulting in the end user having to do more work filling in the human readable information after the initial extraction.

In my discussion with Kevin Marks, he indicated that hCard can and should be used along with XFN to provide complete information. For example, it is possible to have the following XFN and hCard markup

<li class=”vcard”><a class=”fn url” href=”; rel=”met colleague friend” >Joe Blow</a></li>
<li class=”vcard”><a class=”fn url” href=”; rel=”met colleague friend”>Jane Doe</a></li>

I think this is a best practice that is not obvious. Developers are generally familiar with each type of microformats standard but I haven’t seen much documentation in way of how to mix and match the various standards for optimal use. Each standard tends to be describe in silo without consideration for other standards, so hopefully revelations like this can help developers better understand how to use the standards.

Even though the XFN/hCard combination is more complete than just XFN, I still see some issues with it. For example, a parser has to understand the implied relationship between the hCard information and the XFN information and returns that information as a related entity meaning that hCard provides the human readable names for the XFN URL, a relationship that is currently not part of the hCard or XFN spec, so it has to be inferred by the developer. Also, I would like this type of cross standards best practices to also extend to XFN/FOAF, etc. Note that at this time, Google Social Graph APIs do not parse hCard information so even if someone put that information on their profile page, it won’t be useful if the consuming app uses Google Social Graph API. Kevin indicates that he might rectify this in the future and extends the API to also parse hCard.

One last thought, even though I started my application using Javascript, if I want to do more useful stuff, I would switch over to server side code. In particular, if I need to store persistent user information, I need a database and that’s best facilitated by server side platform.

Feedback and suggestions are welcomed.

Chris pointed me to a blog post he did on XFN, Portable contact lists and the case against XFN, it’s worth a read IMO.

DaPo Acronym Soup

In my first post, I said that DaPo list of existing open source technology reads like an acronym soup, here’s why (below extracted from DaPo site).

Authentication Standards

  • User authentication – openID
  • API authentication – oAuth

Data Transfer, Interchange, and Exchange Standards

These standards enable data dumps via import and export across data spaces on the Web. They also aid publish and subscribe methods of data exchange. The list includes:

  • Messaging – XMPP
  • Syndication – Atom and RSS
  • Attention – APML
  • Services and Service Discovery – YADIS and XRDS
  • Subscriptions – OPML
  • Personal details – hCard
  • Relationships – XFN
  • Personal Profile Data & Social Networks – FOAF
  • Online Communities – SIOC (discussed at SIOC-DEV)
  • Publishing data – AtomPub

Linked Data or Data Referencing Standards

These standards enable access to data by reference via HTTP based data object identifiers called URIs. The list includes:

  • HTTP based URIs (for Location, Value, and Structure independent Object / Resource Identifiers)
  • Personal Profile Data & Social Networks – FOAF
  • Online Communities – SIOC (discussed at SIOC-DEV)
  • Other Schemas and Vocabularies in the Semantic Web realm

Other standards

Other standards groups and initiatives that may not yet have a place in the Blueprint, but still deserve help and support!

  • Content Identity Validation – MicroID
  • REST

Despite the acronym soup, I found it to be the most useful page on the site because it lists all the open source technology promoted by DaPo. Now I just need to research each acronym to understand the technology, I will write subsequent posts on each technology as I get to it.

Note that there are policies and legal aspects to DaPo also which I am ignoring, at least for now.