[rdfweb-dev] FOAFnet and the future of FOAF in commercial systems

Leigh.Dodds at ingenta.com Leigh.Dodds at ingenta.com
Thu May 6 19:39:44 UTC 2004

> Leigh - you know I love yah - right?

What's not to love? :)
> So the simple minded child asks: "how's the performance?"
> What happens when 125,322 FOAFs get spidered every hour and.....
> [insert
> anything else here]?  What happens when I want to move my social net
> somewhere else?  How long does the import take?  

All good questions, but I don't see how they relate to API development?

Yes, spidering FOAF files is a hard problem. The web crawling community has much
we can learn from there.

Yes, I want to be able to move my social net around (although I actually see it
as staying put: it's on my server, anyone can come and get it).

Here's a question in return: if I don't publish my FOAF file according to a
specific syntactic profile does that mean I'm not allowed to play with your
toys? Why lock me out?

There are plenty of RDF parsers out there, and as we're talking about Java here
(I think!) Jena is pretty damn good, and not slow at all.
> Why won't the Drupal folks allow RAT into their code base?

Do you mean RAP? Haven't a clue.

I'm going to do try to dissuade anyone that there are new concepts and tools to
be learnt in the RDF space, but good RDF APIs make it a lot easier process.

More on this aspect here: http://www.ldodds.com/blog/archives/000142.html
That view as RDF as a universal data model is the crucial bit. Most of the
programming problems I've had to solve over the last few years have mainly
boiled down to system integration type issues: where's the data coming from,
where's it going to, how do I shuttle it through my application. An RDF model
makes most of those issues go away.

> Who's gonna wait for all these developers to grok such a complex
> system?

You don't, you build simple APIs on to the data, which is where this
conversation started. The point of departure is what we both see as the
fundamental layer. I'm arguing that using an RDF parser is the most flexible way

> But we also have to ship code - not bloated, theoretical parsers that
> can handle anything Ben Hammersely feels like throwing into his FOAF.
> Got it?
> We're just trying to ship something stable and usable NOW.

I'm totally sympathetic to that. I'm just finding that "theoretical parsers"
statement a bit hard to swallow seeing as I've got a concrete RDF parser sat on
my hard drive which I've been merrily using for some time.

If there's a single point I'd like to get across here, its that the subsetting
should be in an internal application layer, not in the syntax. There are plenty
of tools to give you an RDF graph, you just have to poke around to get what you
want. At that point you're free to use whatever model you want. Don't lock me
out because I choose to generate my FOAF differently.


More information about the foaf-dev mailing list