Wednesday before last, June 29th, the Cape Town Plone users’ group and several other developers met at the Open Innovation Studios to sprint on creating a SWORD service for Plone and a couple of SWORD clients to talk to the SWORD service. Siyavula co-hosted the event with me, Roché Compaan of Upfront Systems led the technical Plone development, and all the results are hosted on github and documented on the project wiki here and here.

The goal of the sprint was to learn about SWORD, start a generic implementation of a SWORD service for Plone, and get a couple of clients off the ground.  

We started with this list of tasks and we made progress on 4 of the 5 tasks. Not bad for a one day sprint. A lovely catered lunch, pizza dinner, beer, and red wine (sorry no pictures) were the rewards, in addition to good company and knowledge transfer.

One team began creating an AtomPub service with a SWORD profile for Plone.  Publishing modules and collections to Connexions, which is built on Plone, makes a lot of sense with SWORD. And building SWORD into Plone, rather than at the Connexions layer, gives the potential for using this code in other projects. Because SWORD is really all about depositing packages of content, however, we wrestled a bit with the exact use cases that would make sense for generic Plone. We settled on developing a service to deposit a folder of content into a Plone site. Perhaps that folder represents a single web page and all its associated resources. Or perhaps it represents some other composite type. Time will tell if others reuse the service in novel ways that we didn’t anticipate. You can read more about the results and code locations here.

The other tasks involved building clients. One was a simple command line client written in python to test the service. The client was based on the python client that the SWORD community produced for V2.  The second client was based on a more interesting idea. One of the easier ways to publish online lessons enriched with interactive media is through a personal blog. But reusing material from someone’s personal blog isn’t easy, especially if you want to adapt it in in some way: include it with another set of lessons, package it up for using offline or mobile, translating it, adapting the reading level, etc. So the second client is a webservice for packaging and republishing (or copublishing) your blog entries in a repository like Connexions. The sprint team started with the Pyramid Web Dev Framework and seemed quite pleased with how easy it was to get started. Find out more about both clients here.

My prior blog post discussed the benefits of choosing SWORD for depositing open education resources (OER) in repositories that make it easy to share and remix. It was very general, however, and here I will attempt to make a few more details concrete.

The key to SWORD’s appropriateness is that it is specifically geared toward exchanging packaged content along with some information (metadata) about that package, and SWORD includes metadata in a format common to OER (Dublin Core).

Packaging and the “atomic” nature of SWORD: The key to SWORD over AtomPub (which it is built on top of) is that it has a notion of a “package”. Connexions, for example, is a repository of modules and collections. These are educational packages and can properly be thought of as containers of stuff. A module contains document XML, resources (images, slides, attachments) etc, and some metadata (title, authors, subject etc). It is good to have an API that can deal with that whole thing at once as a logical unit. And SWORD also gives you a way to ask for the whole logical item back (perhaps transformed). For Connexions someone can then rightly ask for their module back as a zip of all its parts, as a web view, as an EPUB, etc.

SWORD would be too heavyweight to publish images to flickr or status updates to Facebook. SWORD also isn’t appropriate in an environment where you could deposit a bunch of things at once, but they really aren’t a logical unit. If you just wanted to upload 20 pictures in bulk to save time, SWORD wouldn’t be the right protocol, because it would require the repository to be able to give you back precisely those 20. But it is just the right size for publishing modules or collections to the Connexions repository. There is really no extra overhead that isn’t completely necessary to the process of submitting content to Connexions.

A protocol like WebDAV is much more complex, because its goal it to make collaborative, distributed authoring of web resources possible, or perhaps be a networked file system. It has all sorts of locking and detailed synchronization, along with ways to query individual properties on individual resources. This is just much more fine-grained than is needed for an educational repository like Connexions. Similarly for CMIS, which is a complete system for making general purpose content management systems interoperable, and like WebDAV it is oriented toward general purpose files and folders.

Commonly used metadata: One more factor makes SWORD appropriate for educational repositories with modular, remixable content. SWORD uses Dublin Core metadata and Dublin Core support has become standard in the world of scholarly and educational content.

Investigation:
To start, it was important to look for an existing API to adapt for publishing OER that can support a learning ecosystem around open education repositories (especially delicious remixable ones). Like Goldilocks, I found a cottage in the woods with several to try. WebDAV, CMIS, and gdata are all interesting and well-established protocols for publishing to the web, but they are much too hot, or in other words they are either too complex for the task at hand, or too specific to particular services. Next I tried Atom Publishing Protocol, but unfortunately too cool — it was too general to specify the work flow natural to publishing packages of learning content. I found two bowls of very, very similar and tasty looking publishing APIs, called Simple Publishing Interface and Simple Webservice Offering Repository Deposit. The bowl I found most satisfying will become evident as the story unravels.

Birth of an OER Roadmap wiki and reserved parking spot for code (March 14): After some investigation of different hosting sites, I chose Google Code, because it had a lot of functionality that was easily available, and a very small learning curve. Welcome to OER-Roadmap.

Hewlett OER Grantees Meeting and Wikimedia: (Mar 29 – Apr 1) I went to the Hewlett’s annual OER grantees meeting and spent time reconnecting with old friends and meeting new ones regarding the broad goals of this fellowship and the potential to help catalyze education content production and consumption. After the grantees meeting I met with Erik Möller of Wikimedia about potential wikipedia/wikieducator bridges to Connexions and potentials for implementing the API in wikimedia projects.

I attended the NITLE Summit (April 6,7) where liberal arts college leaders think about education in a digital age. John Seeley Brown’s keynote (my notes here) on educating for change provided a though-provoking challenge regarding the kind of education needed when content changes constantly. I participated in the OER workshop led by Hal Plotkin of the US Department of Education. 

Cataloging the current Connexions’ API: (April 14th on) : Because Connexions software provides a publishing platform that supports “frictionless remix”, its functionality is a good model for the actions that a publishing API for OER should support. With the help of Connexions’ Systems Engineer, we catalogued the data and metadata that is available, the current publishing implementation, and ideas for how to build licensing, versioning, derived copies, and authorship roles into an API. Those details are found on the Roadmap Wiki here.

Connexions’ Google Summer of Code projects were accepted and two students were chosen. : (April 25th on) : Both of Connexions Google Summer of Code projects have the potential to increase OER production in open repositories.  

1. Creating a Google Docs editor for Connexions would result in a simple pathway for authors to produce content, and the publishing API from this fellowship would allow docs authors to push their content in from wherever they create it. 
2. The second project, Enhanced Author Profiles and Kudos, is also relevant to API’s for OER, because it will make it much easier for authors to advertise their publication of open education materials from Connexions.

Sprinting at the Plone East Symposium (May 19-22): We sprinted (communal coding) to extend an existing partial publish implementation in Connexions. The extension allows creation of modules from deposited Word files or CNXML (Connexions semantic document format) files and improves the handling of metadata (title, language, etc). With the help of fellow fellow, Mark Horner, we found and invited Carl Scheffler, whose background is in machine learning, and whose interests include improving education, to participate in the sprint, along with Connexions own Phil Schatz and Ross Reedstrom, with Penn State’s team Mike Halm and Michael Mulich advising. The sprint planning is here and the full description of the day is here. 

IMS Learning Impact and an emphasis on phased implementation strategy: (May 16-18) The IMS Learning Impact conference was the perfect place to corner, I mean get advice from, those with experience creating API’s and making pathways between software and services. Many thanks to Chuck Severance, Jeff Kahn, Gerry Hanley, Brad Felix and several folks I met at the conference. These discussions led to a general approval for (minor spoiler alert) SWORD, and a planned phased approach to implementing it in Connexions (sooner is better than complete). A simple first cut at the API and an implementation in Connexions allows us to start building tools that use the API to generate interest and excitement and software that others can use, improve, and copy as well.

Open Repositories 2011: The SWORD Workshop: The Choice Revealed (June 7,8)
After meeting with the SWORD technical team, learning more about the second version of SWORD, and conferring with Connexions’ Systems Engineer, SWORD built on AtomPub became the clear winner among the API servings. (And now that Goldilocks metaphor officially ends.) SWORD is simple, flexible, popular, and has a head start in Connexions where we will test it first. The full reasoning is published in the blog entry before this one and a bit more detailed reasoning here.

Client investigations: Translation tools
So with the choice of SWORD, and V2 in particular, investigating potential clients is in full swing. Translating content allows multilingual domain experts to contribute to OER without creating something from scratch. Siyavula’s translation sprints for the Free High School Science textbooks demonstrate that people who know the subject and the language are willing to help out. Carl Scheffler is investigating a couple of different approaches to translation.  

• Using CodeMirror: For geeks unafraid to see XML, this demonstration protects tags so only text gets changed – demo here. 
• Using Google Translate Toolkit: Translate Toolkit is designed for all translators and the beginnings of the investigation are described here. Using Translate Toolkit would require a web service that manages various format transformations that are needed.

The Specification of the API and implementation are underway. The Specification of an OER Publishing API extension of SWORD V2 has begun. The SWORD protocol should work as is, so the extensions should not change the protocol, but rather make use of the natural SWORD flexibility to include extra metadata and return repository specific information. For Connexions, the first phase of implementation of a SWORD V2 service will support creating, updating, publishing, versioning, and deriving copies of modules through the existing editing spaces (to hold the modules as they are being constructed). The following pages show the progress and ongoing work. 

• The OER Roadmap wiki page for Phase 1 
• and a shared Google doc for the specification