Mediawiki

I just came across this tool for Mediawiki: http://www.mediawiki.org/wiki/Extension:Send2Wiki

This extends the possibilities for using mediawiki as a remixing engine for open content repositories that are otherwise closed. I particularly like the pdf to wiki functionality.

A tool like Send2wiki, combined with the WikiArticleFeeds Extension to generate RSS feeds for republishing/reorganizing in an open content repository would allow a great deal of flexibility for creating and remixing open content.

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?

David Wiley recently posted on what some folks are calling Open Educational Resources, or OER’s. This post extends my comment left on David’s original post.

In his post, David starts by examining the difference between producers and consumers of Open Educational Resources, with an emphasis that Good Things ™ start happening when the Consumers become the Producers through the magic of wiki-style group editing.

He suggests that one of the impediments to broader re-use of OER’s results from the original R living in a strict context -- ie, the R came into existence because of a specific educational need in a specific educational place, and reusing the R will be difficult in part because no two contexts are alike.

This leads to a comparison of OER development to Open Source development, particularly the notion that OER creators, like Open Source developers, are people who develop resources to “scratch” a personal “itch.”

It’s an interesting and thought provoking conversation, but one that breaks in a few places. Wiley is right on when he speaks of context being a limiting factor in reusing open content. However, he concludes:

Perhaps instead of sharing watered-down, decontextualized, 'professional' versions of our educational materials we should share context-rich, personality-laden ones.

This conclusion sidesteps the issue.

If content is going to be reused in a different context, then it actually needs to be reused in a different context. This context shift cannot occur when the resource remains locked in the originating site, firmly within its original context. A resource only becomes reusable when the next user can pick it up and take it with them (The analogy that comes to mind is taking a kid to a sports store and showing them a soccer ball on display in a window, and then telling them to have a great match, but that they need to play the match with the ball remaining off-limits behind the glass). Pointing to a resource on the web, and even editing a currently existing resource, only accomplishes part of the task. While it’s great that we have a growing body of freely accessible content, we’d be foolish to pretend that it couldn’t be better.

And this brings us to the Open Source comparison, and why Open Source development is thriving: with open source, you can take it with you. I can download Apache, MySQL, and PHP and install them on my computer. I can build a Mediawiki site, and install Drupal, and install Moodle. As I do this, the little mice in my brain start moving and spinning their wheels, and when I have questions, I can look into the code, or change the config settings, on my machine, in my own context. If I have an idea that makes sense, I can bring it back to the community. If it makes sense to enough people there, then the idea gets picked up. If it doesn’t, then so be it. But I can still use my resource, in my way, and connect back to the community as needed.

This portability is the missing piece in creating widely re-used Open Content. There are some initial forays into moving content between sites -- Mediawiki has an excellent xml import/export feature; Moodle has the ability to back up pieces of courses, and Drupal has an array of import/export options. RSS import also provides the means to move content between sites. However, all of these methods require a comfort level with technology that stretches many users. Personally, I haven’t met many people inside or outside education who are particularly comfortable cutting and pasting an xml file.

For Open Content to work, moving content needs to be simple. A user should be able to select anything from a page in a lesson to an entire chapter, and the selected contents should be exportable from one site and importable to another via a web UI.

It’s also worth noting that the obstacles here are not technical. As RSS demonstrates, a lightweight solution does a great job moving large amounts of content between sites. However, until someone proposes a general spec, nothing will move.

So, here goes:

1. Use the native solutions already under development or in use in Moodle, Drupal, and Mediawiki. For Moodle, this would be the backup/restore feature; in Drupal, the Import/Export API , and in Mediawiki, the XML import/export functionality. For what it’s worth, the Mediawiki import/export seems to work with the fewest hitches.
2. Code a central filter to convert content from one site into an appropriate format for the other. This process would likely need to include some choices about supported and unsupported markup. This filter would need to ship as an included library with the import/export block/module/extension for each application
3. For each application, build a form that managed the import into each application; ie, a web UI that exposed the import/export functionality. Our target for reuse is not the technically proficient user, but a more general audience. Exporting and importing content -- from a single page to an entire course -- needs to be as complex as downloading an attachment from email, and subsequently re-sending that attachment in another email. Think of all the forwarded jokes you have received in the last week. It needs to be that simple.

OpenID provides a method of Single Sign On (SSO) between multiple web sites. OpenID allows users to "claim" a specific url; this url identifies the user as they browse and join different web sites.

Other SSO options exist, including Shibboleth, SXIP, Pubcookie, and JA-SIG's Central Authentication Service. OpenID differs from other methods in a few ways, but the purpose of this post is not to compare or contrast the pros and cons of the different SSO options. This post is also intended as an overview to demonstrate some possibilities, not as the final word on what OpenID can or can't do.

Far too frequently, conversations that set out to compare and contrast different standards end up denigrating one standard in order to elevate another. This type of conversation seems counterproductive; as with any technological solution, the best solution will be dictated by the specific needs of the institution or organization. While OpenID will not be the perfect choice for every situation, it combines flexibility, security, simplicity, and scalability. These traits make OpenID an attractive choice in a wide range of scenarios.

Background:

Two things are required to use OpenID: an OpenID server, and an OpenID-enabled client site. The OpenID server is the site where users claim their unique url. An OpenID url looks exactly like a web address; for example, if an OpenID server is set up at elgg.net, a user's OpenID url would be http://elgg.net/username -- more to come on this later. Then, using their unique url, the user can log into any site that is set up to accept OpenIDs. Among open source projects, several applications are already OpenID enabled. There are also libraries available to simplify the process of OpenID-enabling other applications.

This page provides links to OpenID providers (to get your own OpenID) and downloadable OpenID servers (to set up your own server). Within an organization you can set up one OpenID server that serves as the central authority for managing SSO to selected resources. OpenID servers can also be incorporated into existing applications, so that any site member also receives an OpenID. For example, an OpenID server can be incorporated into Elgg, which creates some interesting possibilities -- more to come on this later.

It is also important to note that OpenID is both an open standard, and that many of the applications that use OpenID are released under open source licenses.

OpenID is also gaining traction among larger companies. Verisign recently rolled out an OpenID implementation with their Personal Identity Provider service.

OpenID Features:

Single Sign On (SSO): OpenID allows for SSO between sites that are OpenID enabled.

User management: an OpenID server can authenticate against a wide variety of data sources, from a .pwd file to user data in a legacy system via LDAP. So, an OpenID server does not require an institution to maintain and synchronize multiple sets of user data. OpenID servers have been set up to allow pluggable authentication against a broad range of data sources to allow for maximum flexibility.

Whitelist/Blacklist sites: OpenID client sites can be configured to whitelist and blacklist sites. To demonstrate how this works, consider the following scenario:

Johnny is a sixth grader at Neighborhood Middle School, where they have an OpenID server. Using his OpenID, Johnny logs into his class web site, the chess club web site, and his personal learning space. Because all these sites are OpenID enabled, he only logs in once to do work in these different areas. However, because these are all different sites, Johnny can be a student within the class site, and a content moderator in the chess club site.

Within this same school, all client sites have been configured to only accept logins from the school's OpenID users. So, any logins with an OpenID from outside the school community will be rejected. As with all other security systems, a user needs to have a valid username and password.

The whitelisting and blacklisting feature can also be used to support safe, secure online collaboration between different schools. If the Neighborhood Middle School developed a relationship with the Far Away Middle School, the two schools could set up a web site to allow logins only from each school's individual OpenID server. So, members of the two school communities could have access to the site, and the rest of the internet would have no access.

Elgg as an OpenID server: Using Elgg as the front end for the OpenID server creates additional benefits. Elgg's user profiles allow for flexible display of profile information, as the OpenID url points directly back to a user's profile. For example, my Elgg profile is visible at http://elgg.net/bfitzgerald. If elgg.net was enabled as an OpenID server, my OpenID url would be the same as my Elgg profile. The long term roadmap for Elgg will allow for searching across different Elgg sites. The combination of whitelisted logins between different OpenID servers, searching across Elgg sites, and OpenID urls that point directly to a user's profile will simplify collaboration between and across organizations.

Taking this a step further, OpenID could also simplify the process of allowing students from different schools to take the same class in a single Moodle install. If Moodle was OpenID enabled, it would be possible to whitelist OpenID servers from multiple schools. This has the potential to create a truly distributed learning environment: students from different institutions interacting in a more formal class structure (Moodle), and in an informal learning space (Elgg).

Where things stand now:

Kevin Jardine is actively working to OpenID enable Elgg as an OpenID server and client. Drupal 4.7 and 4.6 are OpenID enabled, and we are creating an admin screen to simplify whitelisting/blacklisting sites. A Mediawiki extension is under active development in the Mediawiki subversion repository. There is also some preliminary interest in OpenID enabling Moodle, with at least one developer expressing an interest in writing the code to make this happen.