A discussion of the design and implementation of an RDF API.
These are slowly in the process of getting written up. This page basically outlines what I think, the reasons behind the decisions I made for my RDF API (which I think are pretty sound). I'll include pointers to the source code and documentation as I go.
Thanks to Dan Brickley, Libby Miller, Dave Beckett (and others at the ILRT and beyond - Brian McBride in particular; his opinions tend to be pretty sound) whose discussions have helped these ideas to gel.
I'm aware there still isn't enough of a distinction drawn here between "what's desirable for an RDF API" and "here's how I did it in Java". I'm looking to fix this but my general enthusiasm for things like the anonymous resource hack meant that I've bundled behaviour and implementation considerations together. This is partly because they are very closely linked. I'll fix this soon.
Section 1: What follows is to do with the basic API, viewed only as an interface
Although the discussion in this section occasionally descends into Java, I've tried to limit the Java-centricity merely to illustrative examples. Throughout the document I'll try to indicate clearly (where it's not obvious from context) where the discussion is about abstract APIs, generic implementation decisions or explicit Java trade-offs or implementation techniques and examples.
Section 2: Moving on to implementation considerations and more detail about API issues
There are some questions that every implementation must consider and provide answers to, even if those answers are "that combination of operations is undefined". Such questions - and my answers - are presented here.
Section 3: The biggest problem to solve..?
Anonymous resources are very important - we can't always decide what name to give something, but we may be able to identify it instead by the relationships it stands in with respect to other resources. It turns out that supporting this notion has ramifications all the way through an RDF implementation. The solution adopted (Model-specific identities) is presented in some detail here.
Section 4: In-depth implementation issues.
There's more to an RDF implementation than the storage of raw nodes and arcs. We wish to add value, intelligence, and logical capabilities. The implementation techniques for (some) of this - in particular, for supporting value-adding layers, are presented.
Section 5: Advanced issues.
RDF isn't hard, but debates keep on ranging about the uniqueness of statements, what an RDF query language should look like, etc. This section looks at what goes on top of an RDF database, what sort of applications might be possible, and how one might actually get information in and out of such an application.