OERPUB: A community to create a flexible architecture for publishing and remixing OER (Open Education Resources)

I realize that we all want yet another mailing list to be on, but hear me out. A group of folks that participate on the Connexions’ Technical Committee wanted a way to broaden that discussion to the wider OER and OER tools community, attract new partners and collaborators, and yet stay focused on the principles of remixability. Thus was born the new oerpub-dev mailing list.

Draft Mission:

The next paragraph is how the fledgling oerpub.org website describes the group:

“We are a community that discuss and develop open source technology focused on designing, and implementing “An architecture for remixable Open Educational Resources (OER)”. OERPUB is not a single project but a collective where open source projects with the same goals can discuss the tools and architectures that work best for authoring, adapting, remixing, and publishing open education resources and then delivering them to the web, mobile, tablet, and print. If you are interested in advancing the tools that education authors use to create, remix, typeset and publish semantically rich documents, please join the discussion.”

In some sense we are still figuring this new group out as we go along. The idea grew out of the Connexions Consortium Technical committee and my Shuttleworth Fellowship to create a technical “roadmap” for remixable OER. specifically, textbook-like OER.

Some brief history:

• Connexions Consortium Technical Committee formed 2.5 years ago and has always had non-consortium-member members and has welcomed anyone to participate. Right now it meets on a conference call every 6 weeks and in person once a year. When we last met, we decided to become part of a larger and broader group under this oerpub umbrella.
• Connexions’ current architecture is a single interacting piece of software that is a repository, an editing environment, a quality control system (lenses), a search and web display system, and an engine for building pdfs, epubs, offline html packages, etc. It is hard to grow an ecosystem around it because components are not separable and APIs for interacting with the system are sparse.
• I have been supporting components and API’s for remixability through my fellowship.The goal of the fellowship is to support a broad set of repositories and tools, while encouraging much more remixable OER content in general. I started out with a publishing API called OERPub based on SWORD which is based on AtomPub and now I am focusing on building converters and editors that help authors create semantically rich and remixable OER and then use the API to publish the content. SWORD is supported in a bunch of scholarly repositories so it creates opportunities for dual publishing and for sharing development of editors and composers.
• Connexions is planning to rearchitect and wants to build components that are separate and communicate through APIs. They are also rethinking the semantic format that documents are stored in with a strong leaning toward a subset of HTML5 with additional semantic markup to do cool education-y things. So this larger group has an opportunity to influence those choices in ways that support the broader community.

Remixability:

I have always thought that Connexions’ vision captured the essence of remixable OER in the following principles:

• Modularity -- Rather than publishing complete works (books, papers, conference proceedings, courses, etc), it pays to support topical chunks that can be strung together to make many different collected works. Each topical chunk is reusable, adaptable and mixable.
• Semantic document structure -- Having a semantic structure makes things much easier to remix, because you can put sections together and have them flow smoothly. You can also do fancy things like pull all the glossary terms or exercises together.
• Shareability -- Making reuse licensing super easy. CC-BY is a simple, elegant choice for promoting maximum reuse opportunities. It really should be possible to mix other licenses in also, however, but more repositories will need structure that supports remixing.
• Permanence -- To build interesting systems that remix, combine, adapt, rate content, and so on, you really need to know the content is secure and uniquely addressable. When it lives on someone’s website, it could move, disappear, etc. Permanence makes the investment in reuse secure.

Participants and recruits:

The vision for OERPUB is broader than Connexions, though.

• Siyavula, Flat World Knowledge, CK12, Saylor.org and others are all creating shareable content in semantic formats. They are interested in supporting remixability, but it is still a technical challenge.
• Siyavula, OpenStax College, and various university presses support sharing and remixing their content, but still want a sophisticated and branded publishing system. One size fits all won’t work, but they could certainly share and adapt tools for producing PDF, EPUB, MOBI, Web Etc.
• Wikiwijs and Vietnam Foundation (they use cnx software) have major OER initiatives and also would like to figure out ways to share technology and remix content. Projects like Booktype have infrastructure for supporting remixable content and creating multiple delivery formats from a single source.
• Tons of universities are creating content and storing it locally as Open Courseware in DSpace/Eprints/Fedora/educommons repositories. If remix were easier to support, many of them would be willing.

My personal goals for the oerpub-dev list is to create the place to discuss (and develop and experiment with) an architecture for remixable OER that maintains the principles above, but is technically flexible and inclusive of a larger development community.

Some of the relevant discussions include:

• How to use HTML5 as a semantic document format?
• How to make really, really usable structured documented editing work?
• When and how to build converters that help with remix -- DocBook/CNXML/DITA/LaTeX -- are all semantic formats that can translate fairly well one to the other.
• What sorts of API’s should repositories “speak” to facilitate reuse of the code AND reuse of the stuff in the repositories?

Interested? Join us at oerpub.org, and oerpub-dev.