Using and aggregating FOAF is basically a Google sized problem. Made worse because there's a lot of non-standard FOAF out there and a lot of FOAF that is basically meaningless. For the second consider all the FOAF from Livejournal that consists of "Here's my nick and my page. Here's a long list of nicknames and their pages". There's precious little actual data about any of them.

If you look at a single FOAF file about A you can answer "Who does A know" but you can't answer "Who says they know A" The only way to do that is to build a cached database of the FOAF universe. Now you're deep into scutter design, cacheing, expiring and syncing data, and SQL database design for RDF triples. If you just store triples, you'll have a *very large* number of them. Getting any real data out of this is going to involve some nasty, nasty SQL queries that will run slow. If you normalise the data to solve a particular problem, then you're giving up other access routes. Particularly access routes that you don't know about yet.

So all in all it's an interesting computer science problem but damn hard.

I got quite a ways down building a site loosely called "Is my FOAF Hot Or Not?" I stumbled and fell at the Scutter problem.

In the end I've decided that FOAF is most interesting as a data transfer format from one system to another. At which point, microformats like hCard are more interesting, although they don't have anything comparable to the "foaf:knows" format.