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.