Into the Woods

In the heat of putting together prototype demos with our interns to show to our supporting executives, we fell upon the need to access RDF named graphs in a REST-ful manner from AJAX; nothing terribly new here. Our basic solution was to use the Atom content payload to transport the RDF named graph, and then shred the RDF from the content into our RDF database, along with the Atom [OWL] triples. In the other direction, the AJAX apps would parse the RDF/XML from the Atom entry content, and render it somehow (Sparql, microtempates, etc…). This use of Atom was part of our original vision. A problem arrose because the RDF store needed to also be populated from a Java application. (Named graph updates from the Java application would then reflect in the AJAX web application). Our first approach on the Java side was going to be to have the interns add all the Atom OWL triples to their named graphs before committing them to the RDF database, and then the Atom Server (Queso) would recognize them as proper Atom entries in the database (a cool use of RDF duck-typing). Unfortunately, circumventing the Atom Server to add Atom entries to the store created problems with our caching and other optimizations on the Atom server. So, we decided that somehow, the Java clients must publish their named graphs through Atom Publishing Protocol to Queso as well. So, I began to think about what an API might look like for the Java client. I settled on (surprise surprise) an implementation of a Jena Model backed by the Atom Publishing Protocol (APP) and Abdera (the Atom Java API from Apache). So far, my implementation only works for committing new named graphs and updating existing named graphs. Here is some sample code:

                APPNamedGraphService app = new APPNamedGraphService();
		APPModel model = app.getNamedGraphModel();
		Resource res1 = model.createResource("http://example.org/res1");
		Resource res2 = model.createResource("http://example.org/res2");
		Property prop1 = model.createProperty("http://example.org/prop1");

		model.add(res1,prop1,res2);
		model.commit();

Under the covers, the APPModel keeps track of the current state of the Entry, in particular the current “iana:edit” link, so that updates use the link with the proper version to work with the Google API Optimistic Concurrency mechanism. When commit() is called, I invoke the Abdera API to post an update to the entry.

Once I have more of the design flushed out, I’ll post more sample code and a usable Model implementation that will work against http://abdera.watson.ibm.com. I hope to have such features as background replication, merging, and eventing.