Re: Jena - A Java API for RDF

Nice work Brian :-)

(Yet another bristol RDF implementation -- must be something in the
water!)

I like the way you've included examples to help illustrate the API
usability issues. RDF discussion all too easily drifts into the
abstract, so having concrete sample application code is useful
here. 

The 'node-centric' coding style facilitied by Jena is intriguing. I like
being able to write things like:

   person.getProperty(H.ratings)
              .getProperty(RDF.li(1))
              .getProperty(RDF.value).set(r+0.1);
or...

   Resource rating =
              model.createResource()
                   .addProperty(RDF.type, H.Rating)
                   .addProperty(RDF.value, 0.75)
                   .addProperty(H.about,
                                model.createResource("uri for album",
                                                       X.Work)); 


I've not rummaged enough in your API, but I'm curious as to how this
interacts with another nice property of RDF, ie. aggregation of multiple
RDF graphs/models. For eg., you might imagine a Java application that
had multiple graph/model objects; calling methods on a node that is
mentioned in several such data structures would presumably only interact
with data from the model that owned that node. I'm thinking out loud a
little but my first reaction is that it would be good to have both
options somehow, eg. to offer application authors some control over the
aggregate of RDF graphs that were currently 'in effect'. 

Backing up from the detail a bit, I'm pleased you've posted this as it's
very timely now Art is looking at a new W3C bundling of the SiRPAC code. 
Sergey's done some excellent work with SiRPAC bug fixes, the Stanford
API proposal, and all sorts of fun stuff (UML, alternate syntaxes etc). 
Meanwhile others have been busy with alternate ways of interfacing with
RDF (most recently Redland and Jend). It's not clear to me where this
leaves us with SiRPAC. What I'd like is for W3C to ship a stable
'application framework' style SiRPAC distribution based on Sergey's
stuff that allowed alternate parsers to be swapped in, and for a "good
enough to use" RDF API to be out there in the 'official' SiRPAC distribution.
 
This list is the best place for us all to decide where best to go with
SiRPAC. I'd like to hear Sergey's and other implementors' perspective on
the strengths/weaknesses of the SiRPAC/Stanford RDF API, and on
priorities for the W3C distribution of that code. Should we focus on
something that can 'let people get the job done' in their RDF apps, or
on improving the API with the goal of a SAX-like (?Java) developers
consensus. 

What I'd love to see (possible student project for those of you in CS
depts...?) is an RDF API Beauty Contest. There are enough
implementations and proposals floating around now for such a
thing. Rough idea being to gather some common usage scenarios (web
ratings, sitemaps, Dubline Core,  RSS channels) and see what application
code looks like from these different approaches.

Last thing to say on Brian's stuff before I have a _proper_ look is that
the built-in support for RDF container constructs is very welcome. Oh,
and that an SQL-backed version would be very welcome...

Dan

On Mon, 28 Aug 2000, McBride, Brian wrote:

> A few weeks ago I posted some suggestions for an improved java RDF API.
> I've placed an implementation of these ideas at
> http://www-uk.hpl.hp.com/people/bwm/rdf/jena/index.htm
> <http://www-uk.hpl.hp.com/people/bwm/rdf/jena/index.htm> .
>  
> The code supports in memory models.  David Megginson's RDFFilter is hooked
> in so it can parse RDF serializations.  I suggest you use the version of
> RDFFilter supplied in the distribution as it has some minor bug fixes.  Its
> alpha code - it gets through the regression tests and runs the samples but
> hasn't had much use other than that.  An SQL implementation may follow.
>  
> I think better tools will help encourage the adoption of RDF.  I'm looking
> on this as an experiment to see whether this API brings any benefits.  So
> I'd like some feedback.
>  
> Brian McBride
> HPLabs
>  
>

Received on Monday, 28 August 2000 12:09:23 UTC