Some interesting discussion has been triggered by Jon Udell’s comments on FOAF. I agree with Edd and Dan that FOAF is about more than social networking and have said as much here on several occasions. Personally I see two problems with FOAF neither of them big.
Firstly the name causes people to adopt certain expectations about it’s intended usage particularly with general surge of interest (fad?) in social software. I certainly wouldn’t advocate a name change but, as the exchange with Udell has demonstrated, we need to take care to present FOAF correctly.
The second problem is just about data. Because there is no central repository of FOAF data, it’s harder to create FOAF applications: you either need to run a scutter yourself to collect up what’s available, or generate FOAF out of the back-end of another site. Of course you can also hang out on #foaf and badger someone (e.g. Jim Ley or Matt Biddulph) to give you a data export; that’s what I did.
I firmly believe that playing with the FOAF data that’s out in the wild will generate the most interesting applications, and provide essential implementation feedback on the vocabulary itself.
So I’m going to try encouraging folk to regularly and visibly publish the results of their scutter runs. An “offical” data set hung of the FOAF homepage would also be useful. This should hopefully encourage the development of more FOAF applications.
Incidentally I mentally classify those applications as follows:
- FOAF-generating — e.g. FOAF-a-Matic, ecademy, TypePad, etc. Applications that generate FOAF but don’t typically process it to perform any useful function. These are an important step in producing a critical mass of data
- FOAF-gathering — e.g. a Scutter, FOAFbot, FOAFnaut. Applications that harvest the web of FOAF data to build a data repository. Functionality is then built around this repository
- FOAF-consuming — e.g. FOAF explorer/viewer, Dashboard, Planet RDF. Applications that read specific FOAF data, to fulfill some function. FOAF-gathering applications also typically consume data in this way — to manually refresh their repository — but I’m thinking of slightly different application scenarios, e.g. automating web site registration and preference maintenance, generating a project or community blog, etc.
For me this classification separates out some of the implementation issues: a FOAF-consuming application doesn’t typically have to worry about attribution, trust, etc. The data is coming from a limited number of sources. FOAF-gathering applications have to deal with a much more difficult set of problems.
Lost Boy 
I wouldn’t’ve said foafnaut was really an application that harrvest the web for data, I only built it because at the time Redland didn’t build under cygwin (it does now, and would’ve then if I’d been less impatient) and wasn’t a python fan, so pretty much needed my own scutter to get the data. I’d like foafnaut to be a consumer – it certainly has implementations now using other backends than my scutter. Libby has one, as does Carl Garland’s 23 pools. so FOAFnaut is hopefully a consumer. People are welcome to the dumps though!
FOAF has a much, much bigger problem imho, that is its lack of containment. Everything in FOAF is a simple assertion; there is no way to aggregate assertions either in time or by some kind of association.
For example, if I make the FOAF assertions:
David knows Jim
David knows Michelle
David knows Judy
I cannot make a container that talks about HOW I know them. For example:
Michelle may be my wife, but I know Jim and Judy from work. Well… except for the fact that I know Jim from “2 jobs ago” and Judy from a consulting gig this past summer. Oh, and Jim and Judy don’t know each other, but Michelle knows Judy because they went to college together.
FOAF does absolutely noting to deal with the real-world mapping of associations and how people map their friends and acquaintances (or jobs, or other cliques/clans/roles they may be a part of) into the different aspects (some use the terms “personae”) that exists in all of our lives.
I wrote about this in my blog http://zeitblog.zeitgeist.com/ (look for (Anti-)Social Software.
That’s not strictly true. While your correct that FOAF doesn’t attempt to do with “real-world mapping of associations” thats not a failing, it’s a deliberate design decision.
Because these relationships are so hard to codify, rather than attempt to define a single model and expect everyone to conform to it, FOAF instead lets other communities (e.g. a specific social network, clique, clan or business) define these relationships for themselves.
FOAF is an RDF vocabulary. This means it’s terms can be easily extended. For example the relationship schema allows description of familial relationships.
FOAF also has the potential to allow discovery of relationships such as “went to college together”, without having them explicitly defined, by making simple inferences on top of basic data such as “attended school”.
In your (Anti-)Social Software posting you state a desire to “completely re-orient and de-centralize the very concept of the social network”. The items on your list are the very things that FOAF is aimed at solving: decentralised and open data; ability to capture both explicit and implicit relationships; act as substrate for creation of people-centric applications.
I don’t think that these relationships are hard to codify at all… unless you are coming from an RDF centric design point of view.
If we pretend that RDF didn’t exist — in fact that no XML-like world exists at all — and you’re forced to work with objects: suddenly all the things that are hard to codify in RDF become very easy to create. The reason why RDF (and FOAF in particular) seems (to me anyway) to be so hard to work with is that it seems that all of its vocabulary/data types and relationships are built starting from the point of view of how they would be represented in a file rather than as living objects.
Another thing that I find absolutely baffling about the design of FOAF is the that decades of previous work seem to be purposefully ignored. For example, the overlap between vCards and FOAF is close to 100% yet there is no simple way to make FAOF work with the existing data that makes most people’s worlds go around — their address books.
As a demonstration technology FOAF is very clever, but as a potential real-world tool it is competing with much more robust and better established tools and data-sets. The lack of any meaningful interaction with the current tools that people use looks like a dead end…
http://www.zopto.com/ – Foaf authoring and browsing.
FOAF challenges
Leigh Dodds – oone of the leaders of the FOAF community – raps it out.
Edd Dumbill’s sigh
…For me at least FOAF’s point is as the personal homepage technology of the semantic web. Like we all made…
FOAF 的精神
Because these relationships are so hard to codify, rather than attempt to define a single model and expect everyone to…