[rdfweb-dev] NEEDED: SIMPLE FOAF->Javabeans conversion

Leigh Dodds ldodds at ingenta.com
Thu May 6 18:08:20 UTC 2004

> The statement was “isn’t there somebody out there who’s converted FOAF 
> into Javabeans?”

The approach that I've settled for my MusicBrainz API (docs at [1]) and 
the FOAF-a-Matic Mark 2 (beta-2 is at [2]) is basically the following:

1. Implement a series of bean objects that model the simple view of the 
RDF data that I care to expose to my application.

This gives me Album or Person with simple get/set properties.

The beans are not attached to the underlying graph so are simple 
straight-forward JavaBeans.

2. Implement a "Populator" which, provided with a graph, can generate 
beans for particular queries. E.g. "whose FOAF file is this", "give me 
the friends of this person".

The Populator is the glue between my subsetted view of FOAF and the dark 
  tangled world of FOAF on the web.

This is all you need if you're read only.

3. Implement a "TripleBuilder" which, provided with a Java Bean(s), can 
generate RDF triples.

This turns my simple world view back into RDF. The TripleBuilder uses an 
RDF API (Jena) to actually produce the data which might be added back to 
the original model or a new one depending on whether you're worried 
about round-tripping or not.

4. Have fun implementing applications.

The RDF knowledge required to achieve this is very straight-forward, but 
there's scope for doing more complex things (getting the RDF graph to do 
inferencing, using RDQL rather than just poking around in the graph, etc).

There was no need to expose or define a FOAF sub-set in the data, as 
it's my application that needs the simpler view, not the rest of the world.

I wouldn't say I'm 100% happy with how this works, but it does the job. 
At the moment I'm finding that adding support for more vocabularies 
means I'm continually revising the beans, adding new factory classes, etc.

I think once you get beyond a threshold of working with several 
different vocabularies (which is easy to do: MusicBrainz, FOAF, 
Playlists, Relationships) it becomes easier to do away with the Java 
Beans wherever possible and just extract the data directly from the 
graph. This does have implications for the rest of the system, e.g. if 
you're relying on JSP/JSTL to help build web pages [3] but those aren't 
insurmountable problems.

And by not pretending that the RDF graph isn't there I've not gone down 
any rat-holes of relying on custom parsers(*).

[1]. http://www.ldodds.com/projects/musicbrainz/api/index.html
[2]. http://www.ldodds.com/foaf/fm-mark2/beta-2/fm-mark2-beta-2-src.zip
[3]. http://www.ldodds.com/blog/archives/000131.html



(*) OK, actually I did to start with. I was generating RDF/XML by hand, 
then came to reading it, and realised I'd goofed up seriously by 
expecting that there was a simple normalized form for FOAF. I could have 
pushed on with a subset but that would exclude all sorts of data, but 
where's the fun with playing with only a fraction of the data?

More information about the foaf-dev mailing list