Tag Archives: api

Project plans for 2012

I am thrilled to report (a bit belatedly) that my fellowship with the Shuttleworth Foundation has been renewed for another year and I have big plans for the next year (along with the team of designers, developers, testers, open ed collaborators, and students working with me so far)!
Year 1 Review and Year 2 Plans

In Year 1 we:

In Year 2 we plan to:
  • Work with specific OER producers and help them publish their content efficiently while making it remixable using the OERPub tools.
  • Create an easy to use visual editor for the importer to create a full service “Massive Content Enabler”.
  • Expand OERPub to include common APIs to make open assessment banks interoperable.
I am always looking for more people to get involved so if some aspect resonates with you, please get in touch.

SWORD V2 Project Funds our Proposal!

A few weeks ago I wrote a proposal in response to a call for proposals from the JISC funded SWORD V2 project to help build SWORD clients. The proposal requested funds to accelerate development of software to help educators publish word processing to Connexions using the new OER publishing API that is based on SWORD V2.

The proposal is being funded! Thank you to JISC and the SWORD V2 project. Read their announcement about it here.

The basic idea is as follows:

  • Many teachers use Word or Open Office to create their lessons and educational material. And many are eager and willing to share.
  • Connexions is a great place to share educational materials because it is easy to reuse.
    • You can combine pieces to create whole textbooks and courses.
    • Connexions makes it available on the web, in print, for mobile phones, and for ebook readers.
    • If you change one bit, Connexions remakes the book, the ebook, the web view, etc.
    • If someone wants to adapt your content (change the examples, translate it), they can make a copy and publish their changes and you still get credit for inspiring the new adaptation.
  • But, the word processing documents have to be converted to Connexions format first. 

So this new tool will help authors convert their word processing documents, preview how they will look once they are in Connexions, and then use SWORD to publish them to Connexions.

And developers can help make better versions of this tool without knowing a whole lot about how Connexions software works. Just how SWORD (and the OERPub API variant) work.

    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.

    Publishing API and a new service could make translating Connexions modules easy

    p { margin-bottom: 0.08in; }a:link { }

    Specialized tools for translating and publishing OER is one of the possible uses of an API for publishing to open education repositories. Repositories may have general purpose editors for creating content, but they aren’t likely to have great facilities for translating content.
    Carl Scheffler and I spent some time in the Geneva airport investigating whether Google Translator Toolkit could be the translation editor of choice for Connexions modules. Translator Toolkit has to be convinced and helped along, however, because it was designed for HTML (web pages), rather than for the structured XML format of Connexions’ modules. It just might be possible, however, and advice and comments would be most welcome.
    The workflow would be just a bit more complicated than the normal route for translation and would look something like this:
    1. Find a module that you want to tranlsate on Connexions and record its ID. Lets say the module is Electric Circuits – Grade 10, http://cnx.org/content/m32830/latest/. Then the id is “m32830”.
    2. Open Google Translator Toolkit and select a URL something like this: http://www.coolhelperservice.org/cnxtranslate/m32830. This would fetch the module in a format that Google Translate can use well.
    3. Translate it using the Translator Toolkit.
    4. Save the file to your laptop.
    5. Go to something like http://www.coolhelperservice.org/cnxpublish and upload the saved file. Fill out a bit of information and then push a button to sign the license and publish it to Connexions.

    Although it would be more straightforward to enter a cnx.org web address into the Translator Toolkit and then publish straight from the toolkit, we don’t have the technical hooks into the Translator Toolkit to be able to do that. So instead, we would create this new “coolhelperservice” that would know how to format Connexions content for Translator Toolkit and how to take translations and reformat them and publish them to Connexions.

    Does that work flow seem reasonable? Is there a better work flow that you can think of and suggest?

    Some technical details for those that are interested. Those that aren’t can safely stop here and still be able to give feedback on the process from a translator’s perspective.

    Google Translator Toolkit doesn’t work with XML formats. But Connexions does produce an HTML format for modules that can be be converted back into Connexions XML without any loss. So the “coolhelperservice” needs to retrieve the module, format it in HTML for the translator toolkit, and then do the opposite transform (HTML → CNXML) on the way back into Connexions.

    To get the HTML for the body of a module from Connexions, you append “/body” to the module URL. And the module metadata (title and such) is available by appending /metadata to the module URL. So with the module ID, the “coolhelperservice” can put together a nice package of HTML for the translator to use, and still be able to reconstruct the XML to publish the translated version.

    One tricky bit is that Google Translator Toolkit makes a mess of the mathematics that comes in from Connexions, so the math has to be protected somehow. Carl and I experimented with a few ideas for how to do that, and toolkit didn’t cooperate with most of those, but Carl came up with the idea of putting all the math into an HTML id. Amazingly, that worked. It comes out all escaped, but that is good enough. (Toolkit won’t keep around a random attribute, so “id” was the way to go). Carl is pretty sure that there is a webservice that will take a snippet of mathml and give back an image. He is going to investigate that further. So in principle, you can stuff the math into an image ID (so it doesn’t get lost) and replace the math with a URL to this service that will render the math. The translator won’t be able to translate words that were inside the math, but Carl had previously looked around and that isn’t very common, so this might just be good enough.

    At the end, the “coolhelperservice” will use a publishing API (SWORD V2) to publish the translation back to Connexions. Implementing that API is part of my fellowship work so it is coming later this year. There will have to be a bit of license signing back at Connexions, but the “coolhelperservice” can make that smoother also.

    I think something like this could work. What do you think? And did we miss some clever idea or service that could be of help? Actually, I am sure we did since this was a 2 hour experiment. So send help, advice, etc. Carl will keep investigating, and maybe we will have some screenshots to clarify all this for a future post.

    Sprinting with Connexions

    First progress implementing a bit of a publishing API for OER, based on SWORD and AtomPub.

    Last week at the Plone East Symposium in State College PA, plone developers across the US gathered together to learn and share about using Plone in educational settings. At the end of the week, Friday and Saturday, about half the attendees stayed to “sprint” (original plan, full report).  At sprints, people develop working code together on various projects in order to share expertise, learn from each other, and expand networks of technical mentors. Knowing that Connexions already had a partial implementation of SWORD for creating modules from Word documents, and that SWORD is likely to be the backbone for the OER Publishing API (your comments, approval, concerns welcome), I brought a sprint topic to the symposium — “OER Publishing API: Extend Connexions SWORD implementation”. Connexions provided an expert, Phil Schatz, to lead the sprint and we created a milestone to track the work. Carl Scheffler joined Phil and me working on SWORD and we got advice and help from Michael Mulich (Penn State), Ross Reedstrom and Ed Woodward at Connexions.

    What the Connexions/Rhaptos SWORD service does now:

    The current Connexions SWORD service is tailored to a very specific client, the Open Journal System (OJS). It takes a zip of a Word file and a METS file with some metadata and a bibliographic entry that is used to insert a reference to the the original publication of the article in a journal. The service then creates a new, unpublished module with the content of the Word file, and puts it in a work area chosen by the client.

    What we got done at the sprint:

    1. Reorganized the existing SWORD code to make the coding cleaner.
    2. Extended the service so that it would take a Word file, or the Connexions native format.
    3. Changed the service to get the title and abstract from standard locations.
    4. Got the SWORD client toolkit, EasyDeposit, to work with the new code (and partially work with the existing code.)