I’m very interested to see this discussion of Atom. I’m currently working on a new system for managing data and metadata for studies of malaria. It’s at an early stage (not much to show yet), but we’ve tentatively opted to use Atom as the common standard for web service APIs, and then to code the user interface in the browser (using gwt) making direct calls to the Atom API whenever possible.

FWIW we chose Atom and XML over anything based on RDF primarily because we needed a read-write API. SPARQL is great for querying data, but what we really need is to be able to CRUD arbitrary packages of data/metadata, and also define permissions over different collections of those packages … in addition to querying the data in various ways. While Atom doesn’t give you a query API, it is a good fit for the CRUD side of things.

(As an aside, we’re also using eXist as the Atom implementation, which works more-or-less out of the box, and has cut down the amount of work we’ve had to do on the server side.)

I did take a good look at Talis’ API, which has the necessary CRUD capabilities, and was very interested in it. I still think it’s a great offering (the support for change sets instead of just bulk updates is potentially very useful). However, we went for Atom + eXist for two main reasons .. (1) Atom is a standard, so we had a vague hope that if eXist didn’t work out we could swap to a different implementation, and (2) we’re doing a lot of coding for the client-side, and there’s better support for working with XML there (I just couldn’t bring myself to write an rdf api for gwt then implement a gwt client for Talis’ API which involves XML and RDF/XML and reification).

The main questions we’ve had to figure out with Atom are all to do with what best practice should be when extending Atom to convey a particular type of data entity. We use link elements to relate one entry to another, but what should we use for the rel attribute values to represent different types of relationship? Should we be using URIs? Where should we put the foreign markup that represents our data, directly in the atom:entry element, or inside an atom:content element with type application/xml? And what do you do when a client wants to pull down not just a single entry, but a graph of entries? Is it OK to include the related entries inline within the link elements?

The other challenge is how to implement query functionality over the data. I would love to use SPARQL, especially as the result set serialisation formats are very easy to work with in the browser. However, right now we’re getting more mileage from writing XQuery scripts that implement simple HTTP query APIs.

If someone designed a CRUD API for managing RDF graphs that was basically Atom, that was very convenient to use from browser code, and with an implementation that worked out of the box, things would get very interesting :)