[rdfweb-dev] NEEDED: SIMPLE FOAF->Javabeans conversion
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 ) and
the FOAF-a-Matic Mark 2 (beta-2 is at ) 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
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  but those aren't
And by not pretending that the RDF graph isn't there I've not gone down
any rat-holes of relying on custom parsers(*).
(*) 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