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

Leigh Dodds ldodds at ingenta.com
Thu May 6 17:47:22 UTC 2004

> Do we keep to the incredible flexibility, robustness and rather weighty 
> overhead of full rdf parsers, able to leap tall buildings in a single 
> bound?  
> Or do we start to batton down the hatches, screw down the screws, 
> resolve the conflicts and obvious dilemmas, commit to a subset and start 
> to actually ship working code to humans?
> Guess which scenario I’m voting for?

I'm of the opposite opinion (well someone had to be didn't they?! :)

I see that as: do we use tools built specifically for handling this kind 
of data (rdf parsers) or do we try to force our current tools to do the job.

> Now this is not to say that the semantic web stops evolving or that new 
> vocab, ideas and extensions can’t get added to FOAF.

Well actually it does. Because that (possibly widely used) subset 
becomes the anchor that will slow down uptake of additional vocab, 
ideas, extensions, etc.

RDF's wild graphy nature is something to be embraced. It's not a bug to 
be worked around.

If you want to slice the graph up to create a hierarchy or object model 
that makes it easier to work with then do so. But confine the subset to 
the application layer above the graph, don't subset the syntax or model
and then exchange data in that format as that doesn't benefit anyone.

As DanBri pointed out I created a bean view for my MusicBrainz API which 
is just a thin layer over the RDF graph. The beans are nicely decoupled 
and are populated by factory/query methods that extract a simple view of 
the data.

This means I can process anything that MusicBrainz care to throw at me, 
I can produce a simple beany view if thats all I want (and in many cases 
that's enough, especially if you're generating simple web page views of 
the data), but still have the raw graph to dip into if I want to extract 
more data.

The benefit of layering this on top of a full RDF API, particularly one 
that supports RDF Schema is that you don't have to hardwire anything. 
Load in a new schema, and you're good to go: all those millions of 
relationship types can be mapped to good old foaf:knows if that's all 
you want in your bean view.

The benefits of using an RDF data store can't be understated either. 
Because then you can store all that wild RDF data and start to build 
applications on it without starting to reach into your custom parser, 
custom database and other hardwired bits and pieces to support it.

FOAF is a semantic web application. Why not embrace semantic web tools 
for working with it?



More information about the foaf-dev mailing list