OER's: Publishing is the Easy Part; Now, Let's Make Them More Usable

Introductory Notes

These are some thoughts in progress -- I've been thinking these things through for probably the last few years, but things have been getting more interesting of late.

Some of the blog posts that have helped shape my thinking here include:
http://bavatuesdays.com/proud-spammer-of-open-university-courses/
http://weblogs.elearning.ubc.ca/brian/archives/044998.php
http://opencontent.org/blog/archives/464
http://www.chrislott.org/2008/02/17/confused-about-the-blog-uproar/
http://weblogs.elearning.ubc.ca/brian/archives/044813.php
http://www.funnymonkey.com/mini-edu-rss
http://www.darcynorman.net/2008/02/16/on-eduglu-part-1-background/
http://blogs.open.ac.uk/Maths/ajh59/010236.html -- this is from Tony Hirst, who has an almost overwhelming amount of great information regarding remixing content on his blog.
I've also been thinking about the work Scott Wilson has been doing with FeedForward.

Toward the end of this post, I fall short of the needed conversation when I talk about the Course and Learner sections. There's more to be said here -- a lot more -- but the poor souls who actually persevere to that point in the post will probably agree that I've said enough by then already.

An Open Content and Open Learning environment



External Repository -- in this context, an external repository is a place where content is stored. In many ways, the external repository is an artificial construct that doesn't need to exist. The single most important argument in favor of the external repository is that the external repo can provide a level of credibility that less "official" sources of information lack. For example, a piece of information coming from the MIT's OpenCourseware will have more credibility than a YouTube video.

These external repositories, however, need to expose their content via rss/atom, or web services, something that many of them do not do. With that said, it would also be nice to see the major OCW repositories use less pdf's to allow for easier modification.

On a technical note, Tony Hirst pointed to a Mediawiki plugin that exposes full Mediawiki articles as rss feeds. This extends Mediawiki's flexibility by allowing Mediawiki content to be imported via rss feeds.

Planning Repository -- the planning repos are the staging grounds of course preparation. Planning repositories will import selected courses from a variety of external repositories. While a limited number of people might have access to an external repository, more people can have access to a planning repository. Within the planning repository, users can edit existing courses, add links, text, images, etc. Then, users can select individual pieces of different courses, and re-organize them into a new course. By definition, planning repositories should be messy. They are workspaces, and should be viewed as a place where people go from draft versions to more polished versions of course materials.

For example: a history department creates an departmental planning repository. Initially, they import a variety of courses from different external repositories. Then, instructors add content as needed. Once they have finished adding content, they select the lessons/material they want for their course. So, an instructor teaching a course on the Rise of Modernism could incorporate material from a course on WWI. Once the instructors have selected and organized their lessons, they export them into their courses.

On the technical side, the planning repository could be a Drupal site built using the FeedAPI. I described how to do this here, and revisited the idea here. Alan Levine (in the comments here) and Jared Stein and Patrick Gosetti-Murrayjohn (in the comments here ) ask about how to select individual pieces of content for inclusion in a course. Once you have imported content into a Drupal site, you can use Views Bookmarks, Nodequeue, or node references (part of CCK) for doing exactly that.

Once the individual lessons have been selected and organized into a course, they can be exposed via an rss feed.

Mediawiki would also make an excellent planning repository by using XFeed to aggregate external content and the WikiArticle Feeds Extension (linked to above) to generate rss feeds for curriculum.

However, here is another wrinkle: every school is already producing curriculum. Teachers generate curriculum for all of their classes. If a school used a planning repository to coordinate curriculum planning, they could export the polished curriculum to a web site that could become an external repository. In this way, schools generate their curriculum maps and provide open content as part of their ongoing course planning and development process.These planning repositories becoming external repositories would have one enormous advantage over existing content repositories: they would be fully open, with all content within them accessible via rss feeds. For all schools currently undergoing accreditation reviews, how much time are you spending collecting up curricular materials? If you build your curriculum as described in this post, you have all your curriculum ready to hand, and categorized via tags.

It's worth noting that the technology to do this exists now, and can be built entirely using open source tools.

It's also worth noting that, using Drupal, you can clone an entire site -- configuration, content, and even user accounts -- and move that site with minimal effort. It's what we've been doing with DrupalEd for nearly a year, and with less sophisticated class sites since September of 2005.

Courses -- In this context, courses are blog based tools, and could be delivered via a tool like Wordpressor Drupal. Curricular material could be imported; Jim has shown how to do this, D'Arcy has shown how to do this , and the aggregation examples I linked to earlier show how to do this.

The feeds of learners taking the course could be added to a blogroll, or, in the case of Drupal, could be imported directly into the site. With OpenID becoming more prevalent, students could either be site members, or be granted access via their OpenID. This flexibility would allow learners to interact with the course using their preferred tools, and, if they wanted, using their pre-established online identity.

Learners -- In this context, learners are just about anyone. You don't need to be a student to be a learner, although, for obvious reasons, most schools probably wouldn't allow open enrollment in their courses.

For me, the interesting piece of this has to with the potential for a true PLE. While I'm not particularly enamored of the whole notion of the PLE (I see it as more of a construct than a piece of technology, and something that is better achieved via innate curiosity than lines of code, but that's another conversation), this system of open learning solves one of the main problems inherent in most PLE implementations: how to get course content out of the course and into the PLE. In this situation, that's not an issue, as learners use their chosen tools to contribute in their courses. As they are doing the work from their platform, they retain control of their work in a way that just isn't possible using proprietary LMS's, or even open source LMS's like Moodle.

Next Steps

The next steps could include any/all of the following:

  • A school, or a group of teachers, banding together to create course materials in a planning repository. Dan Meyer has called for something along these lines a while back.
  • More teachers using a blog-based approach to delivering content. The WPMU work that Jim helped spearhead shows one way of doing this; and the folks at BYU have illustrated another way of doing this.
  • Existing Open Content repositories could actually expose their content via rss feeds. If this happened, one of the enornous barriers to actually using the open content that has been published to date would be removed.

These thoughts are incomplete -- what's missing? What needs closer examination? What else needs to be considered here?

Comments

Cool post.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
To prevent automated spam submissions leave this field empty.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.