Choosing a SWORD for publishing OER (a pen may be mightier but ...)

Choosing or developing a standard way to publish open educational resources (OER) to libraries (repositories) that encourage remixability (sharing and adapting) was one of my main goals for the first three months of my fellowship with the Shuttleworth Foundation. Fortuitously, the way forward seems clear and smooth by using an existing publishing standard called SWORD.

For non-techies and techies alike, I highly recommend watching the video below that Cottage Labs made for SWORD V2. It is very short, clear, and quite nicely done. If you are a Connexions person, think of the package as a module (the document/page/topic itself, plus all the goodies like images, movies, sound clips, and handouts that the document contains). The package could also be an entire collection. If you work with other educational materials in learning management systems, the package could contain anything from a single PDF or geo-tagged image, to a whole common cartridge course.

As the video shows, SWORD is a simple protocol for depositing content into repositories. It is a specialization of the Atom Publishing Protocol which is itself widely used for publishing web content like blogs. After attending Open Repositories 2011, meeting some of the SWORD technical team (Stuart Lewis and Richard Jones), and getting a few technical details ironed out, SWORD looks like a winner. In particular, the second version (V2) has everything that we need for publishing open education resources.

The reasons for choosing SWORD in a nutshell (well really in a blog).

1. SWORD is simple, but not too simple. SWORD V2 will handle all the basics: finding locations to publish to, creating items, updating them, and signaling that they are ready to publish. And that is about it. SWORD doesn't specify authentication and authorization, so you can use other standards for that. SWORD doesn't get into details of organization (like creating and managing folders and such) so much of the complexity of CMIS-like systems is avoided. SWORD V2 specifies one simple packaging format (an atom entry plus a zip) that must be supported, and then leaves all other packaging up to the repository to negotiate with the client. So creating a sword service is straight-forward and encourages lots of implementations. Clients toolkits can provide lots of useable code, but clients do have to know a bit about how the repositories they want to use expect content to be formatted. But that is true anyhow. You can't send a bunch of PDF's to Flickr, because it wants images, right? 
2. SWORD is flexible. SWORD provides specific returned URLs that can be used to give repository specific requirements like signing a license. Repository specific metadata can be added to the entry at will (with a nice namespace to keep them sorted). Repositories can choose to replace content or to create new versions.
3. SWORD is popular. SWORD is implemented in many existing repositories (DSpace, ePrints, Fedora, arXiv, Zentity, Invenio) the Open Journal System (OJS), and budding data repositories like Chem#. The US Government led Learning Registry is also including a SWORD service for depositing metadata and paradata about learning materials. The SWORD working team includes many different organizations including JISC, UKOLN, US Library of Congress, and the teams from all those implementors. Client toolkits are available in a variety of popular langagues including Java, Python, Ruby, and PHP.    
4. SWORD has a head start in Connexions. Since I want to show how clients and services can make publishing OER easier while keeping them in remixable formats, implementing SWORD in Connexions is crucial to the process. Connexions already has a partial implementation of the first version of SWORD that was built for a very specific work flow with OJS. So a full implementation of SWORD has a head start in Connexions.