It's not what you know, it's who you know. Ever since the Web started, it's been as much about self-expression as anything else. Many people's initial forays into the Web consisted of building themselves a home page. Search engines meant you could find people with similar interests pretty quickly. The technology was interesting, yes, but people themselves always prove more interesting.
One of the latest episodes in the personal Web publishing trend is weblogs, a form of rapid fire publishing, which often has a very personal and informal tone. Webloggers are fond of citing each other, thereby creating dialogues that span multiple Web sites. One of the technologies that underpins this rapid form of publishing is Rich Site Summary, or RSS (see Resources), an XML document that contains metadata about content items on a site.
RSS creates a predictable way for scraps of content to be aggregated, sequenced, and searched. Sites like Syndic8 and Meerkat (see Resources) enable you to keep track of who's saying what about your topic -- or person -- of interest. RSS is also pretty simple, and you can often find it used in examples in XML tutorial material. Part of its appeal is the way you can connect your content to the larger Web, enabling others to find you more easily.
This article is not, however, about RSS -- that has been well documented in other places. I'm going to examine a new project, with certain similarities, called Friend-of-a-Friend (FOAF). This project takes the social networking aspect of the Web further.
Many communities have proliferated on the Internet, from companies through professional organizations to social groupings. The FOAF vocabulary, originated by Dan Brickley and Libby Miller, gives a basic expression for community membership: describing people and their basic properties such as name, e-mail address, and so on.
FOAF is simply an RDF vocabulary. Its typical use is akin to that of RSS: You create one or more FOAF files on your Web server and share the URLs so software can use the information inside the file. Like creating your own Web pages, the creation of your FOAF data is decentralized and within your control. An example application that uses these files might be a community directory where members maintain their own records. However, as with RSS, the really interesting parts of FOAF come into play when the data is aggregated and can then be explored and cross-linked.
FOAF has the potential to become an important tool in managing communities. In addition to providing simple directory services, you could use information from FOAF in many ways. For example:
- Augment e-mail filtering by prioritizing mails from trusted colleagues
- Provide assistance to new entrants in a community
- Locate people with interests similar to yours
The rest of this article describes FOAF's basic features and gives some pointers to current implementations and future considerations. Let's start with the core problem that FOAF addresses: how to identify people in order to describe them.
When you start entering data about real-world things, like people, into a computer system, you come up against the difficulty of creating a unique name for each thing. In the case of people, it's obvious that a person's name is not enough to uniquely identify that person to a computer. In most closed systems, people tend to be allotted identifiers specific to the application. You can see this on the Web: You probably have username/password pairs for a variety of different services such as mailing lists and Web sites. As long as you never want those separate, closed systems to interoperate you'll have no problem (aside, perhaps, from a surfeit of IDs to remember).
If you want to unify your identities over multiple services, the situation becomes trickier . Someone has to come up with a centralized scheme to control the allocation of identities. One such scheme that has seen growth recently is Microsoft's Passport. However, this centralization is risky for several reasons, not least of which is giving a third party total control over your access to services, and possibly your private data.
So, if you consider the FOAF system -- where anyone is
free to create and consume the data, yet where you want only one name per
person -- a decentralized naming strategy is needed. The Web has a pretty
well-established naming strategy like this: the URI. For the naming of
people, you might think
(e-mail address) would be a convenient URI scheme to use.
However, all is not as simple as it seems. A
naive approach might lead a developer to write down, for example:
mailto:email@example.com lives in the UK
A moment's consideration shows this is actually nonsense, as you could truthfully write:
mailto:firstname.lastname@example.org is an e-mail address
Clearly a person and that person's e-mail address are not the same thing, so you can't practically use a person's e-mail address as the global name. Furthermore, a person may have multiple e-mail addresses, each used for a different purpose.
Yet the principle of using an e-mail address to identify a person isn't flawed: In general, if you send an e-mail message to an address you expect it to reach a certain person. What the naive approach missed is that while you can never create a global name for a person, you could reasonably assume that all descriptions of a person that included "this person's e-mail address is email@example.com" might reasonably refer to the same person.
So, you might correctly write:
The person with e-mail address mailto:firstname.lastname@example.org lives in the UK.
This is the way that FOAF works. In order to combine information about particular individuals, the assumption is made that an e-mail address is an unambiguous property -- that is, only one person owns a particular mailbox.
Theorizing aside, let's take a look at what form FOAF information takes. Because code often speaks louder than words, Listing 1 shows a small FOAF description of myself.
Listing 1. A sample FOAF description of the author
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person> <foaf:name>Edd Dumbill</foaf:name> <foaf:mbox rdf:resource="mailto:email@example.com" /> </foaf:Person> </rdf:RDF>
Put simply, the description in Listing 1 says "there is a person whose name is Edd Dumbill and whose e-mail address is firstname.lastname@example.org."
FOAF uses RDF to encode its descriptions. Within this article, I'll stick
to a pretty basic usage of RDF that mimics object-oriented data structures
by listing typed objects (in the case of Listing 1, the type is
and their properties (in Listing 1,
For more information on RDF, see Resources.
Table 1 shows some more simple properties that allow me to express more about myself.
Table 1. Some more simple properties to characterize an individual
|nick||A string literal that gives a name used to identify a user on a chat or other computer system; for example an AIM screen name or UNIX login|
|homepage||The URL of the person's home page|
|workplacehomepage||The URL of the home page of the place the person works|
|depiction||The URL of an image in which the person is depicted|
|phone||A telephone number for the person|
In Listing 2, I augment the description of me with a few more of these properties. (I'm leaving out the outer RDF envelope to save space.)
Listing 2. An excerpt of the RDF that adds more properties from Table 1 to the description of the author
<foaf:Person> <foaf:name >Edd Dumbill</foaf:name> <foaf:mbox rdf:resource="mailto:email@example.com" /> <foaf:nick >edd</foaf:nick> <foaf:workplacehomepage rdf:resource="http://xml.com/" /> <foaf:depiction rdf:resource="http://heddley.com/edd/images/edd-shoulders.jpg" /> </foaf:Person>
So far, the example gives us a useful way of creating a computer-readable home page. If everyone in an online community were to submit a URL pointing at an FOAF file, you could then spider them into a reasonable community directory.
One property I have not yet examined is the
It can be used to link two people together, and it has the basic semantics
of some kind of personal acquaintance. When you use this property
you first encounter the need to identify other
people. As I concluded in Expressing identity, the way FOAF identifies other people is by stating their properties: From this, a processor can use an identifying property to compute which person is being referenced. Listing 3 shows how I express that I know Simon St.Laurent.
Listing 3. An example of the foaf:knows property, which establishes the acquaintance of two people
<foaf:Person> <foaf:name>Edd Dumbill</foaf:name> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org" /> ... <foaf:knows> <foaf:Person> <foaf:mbox rdf:resource="mailto:email@example.com" /> <foaf:name>Simon St.Laurent</foaf:name> </foaf:Person> </foaf:knows> </foaf:Person>
In the description of myself in Listing 3, I add "this person knows a person who has the mailbox firstname.lastname@example.org and the name Simon St.Laurent." I've highlighted the mailbox line in bold, because FOAF will use the mailboxes to actually make the link to Simon, rather than any other property.
As I'll show in the next section, if a program
reads my FOAF file and also reads Simon's, I might reasonably want to ask it to "show the names and home pages of the people I know." Even though I say
nothing about Simon's home page, if he provides this information, then a program can link the
facts together by virtue of the shared
The real power of using the FOAF vocabulary comes when FOAF files are merged together. Note that there's absolutely nothing about the vocabulary that restricts you to creating only descriptions of yourself. For instance, I could create an FOAF description for several other people. Let's try a small example. First, Listing 4 shows a file that I create.
Listing 4. A simple description of the author and two colleagues
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person> <foaf:name>Edd Dumbill</foaf:name> <foaf:mbox rdf:resource="mailto:email@example.com" /> </foaf:Person> <foaf:Person> <foaf:name>Simon St.Laurent</foaf:name> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org" /> </foaf:Person> <foaf:Person> <foaf:name>Eric van der Vlist</foaf:name> <foaf:mbox rdf:resource="mailto:email@example.com" /> </foaf:Person> </rdf:RDF>
Suppose that Eric has an online photo album. Using it, he might create an FOAF file shown in Listing 5.
Listing 5. A description indicating depictions of two people
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org" /> <foaf:depiction rdf:resource="http://example.org/photos/edd+simon.jpg" /> </foaf:Person> <foaf:Person> <foaf:mbox rdf:resource="mailto:email@example.com" /> <foaf:depiction rdf:resource="http://example.org/photos/edd+simon.jpg" /> </foaf:Person> </rdf:RDF>
To the human eye, it's pretty clear what the total import of these two files taken together is: In addition to the information I've already stated, Simon St. Laurent and Edd Dumbill were both depicted in a particular photograph once available at http://example.org/photos/edd+simon.jpg.
To get a computer to understand that, you must make it perform a merge
of these two data files -- that is, it must process the data in the files to enforce the rule "If Person A has the same
foaf:mbox property as Person B, then A and B are the same entity." After this processing has been done, what the system knows can be represented as in Listing 6.
Listing 6. The description obtained from merging those in Listings 4 and 5
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person> <foaf:name>Edd Dumbill</foaf:name> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org" /> <foaf:depiction rdf:resource="http://example.org/photos/edd+simon.jpg" /> </foaf:Person> <foaf:Person> <foaf:name>Simon St.Laurent</foaf:name> <foaf:mbox rdf:resource="mailto:email@example.com" /> <foaf:depiction rdf:resource="http://example.org/photos/edd+simon.jpg" /> </foaf:Person> <foaf:Person> <foaf:name>Eric van der Vlist</foaf:name> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org" /> </foaf:Person> </rdf:RDF>
By this point, I hope you can see the power that merging offers. By aggregating and merging the FOAF files, you can achieve the same effect as operating a centralized directory service, without any of the issues of single points of failure or control. This is a very attractive feature for many communities for which decentralized or devolved control is a requirement, either because of political structure or sheer size.
There is much more to the FOAF vocabulary than I have space to explain here. One way to explore this further is to have a look at some demonstrations.
- Co-depiction: In Listing 5, two people were described as being featured together in a photograph. You can obtain a useful and entertaining effect with this data. In the co-depiction demo (see Resources), you can map out a route of photos from one person to another through co-depiction in a six-degrees-of-separation style exercise.
- Online chat: As part of my investigations into FOAF, I created
a software agent (bot) that sits in a chat forum and, having spidered their FOAF files, provides information about the community members. The code
isn't released yet, but here's a sample session:
<edd> oracle, edd's name <oracle> edd's name is 'Edd Dumbill' <edd> oracle, Edd Dumbill's nick <oracle> Edd Dumbill's nick is 'edd-lap' <oracle> Edd Dumbill's nick is 'edd' <edd> oracle, picture of Dave Beckett and Uche Ogbuji <oracle> Picture at http://photos.example.com/pic_029.jpg <oracle> Caption: Greg Fitzpatrick, Dave Beckett, Libby Miller, Uche Ogbuji
Also, be sure to check out Resources for more documentation and demonstrations of FOAF.
The Friend-of-a-Friend system raises many issues, quite a few of them of a social or legal nature. There's not space to cover them in depth here, but you may like to ponder some of them.
- How can you control the data so it stays within a community of trust?
- How can you track and guarantee the provenance of facts in order to correct errors and provide accountability?
- How can you partition data so some information remains private (for instance, "Person X distrusts person Y"), while other information is published to the world?
- What legal obligations do aggregators of FOAF information have under the data-protection law in the jurisdiction under which they operate?
- How can you join FOAF to other established and emerging community tools such as mailing lists, IRC/chat, weblogs, RSS, and wikis?
These questions and others are under consideration among the FOAF developers. You can join in a discussion of FOAF by subscribing to the rdfweb-dev mailing list (see Resources).
Read fellow IBM developerWorks columnist Uche Ogbuji's other articles on RDF:
- Introduction to RDF (developerWorks, December 2000)
- Thinking XML: Basic XML and RDF techniques for knowledge management, Part 1: Generate RDF using XSLT (developerWorks, July 2001)
- Thinking XML: Basic XML and RDF techniques for knowledge management, Part 2: Combining files into an RDF model, and basic RDF querying (developerWorks, September 2001)
- Thinking XML: Basic XML and RDF techniques for knowledge management, Part 3: Knowledge from semantics (developerWorks, November 2001)
- Thinking XML: Basic XML and RDF techniques for knowledge management, Part 4: Issue tracker schema (developerWorks, February 2002)
- Thinking XML: Basic XML and RDF techniques for knowledge management, Part 5: Defining RDF and DAML+OIL schemata (developerWorks, March 2002)
Explore the RDFWeb
project, which offers links to FOAF and other semantic web vaporware initiatives.
Join the rdfweb-dev
mailing list to talk about FOAF with its developers.
Look at the FOAF
0.1 schema which describes currently documented FOAF properties. (View
its source and look for the embedded RDF schema).
Check out the Co-depiction
demo that shows community relationships through photos.
Investigate the Open Directory Project's page on RSS for many useful resources.
Try out two aggregation sites that compile information using RSS: Syndic8
- Find more XML resources on the developerWorks
XML technology zone.
- Get IBM Rational Application Developer for WebSphere Software, an easy-to-use, integrated development environment for building, testing, and deploying J2EE applications, including generating XML documents from DTDs and schemas.
- Find out how you can become an IBM Certified Developer in XML and related technologies.
Find other articles in Edd Dumbill's XML Watch column.
Edd Dumbill is managing editor of XML.com and the editor and publisher of the XML developer news site XMLhack. He is co-author of O'Reilly's Programming Web Services with XML-RPC, and co-founder and adviser to the Pharmalicensing life sciences intellectual property exchange. Edd is also program chair of the XML Europe conference. You can contact Edd at email@example.com.