Open Content

Put a Little Science in Your Life

From an Op-Ed in the June 1 online edition of the NY Times by Brian Greene: Put a Little Science in Your Life

The entire piece is worth the read. If you are pressed for time and need to choose between reading this blog post and the article, choose the article.

Some excerpts that struck me as particularly relevant:

in teaching our students, we continually fail to activate rich opportunities for revealing the breathtaking vistas opened up by science, and instead focus on the need to gain competency with science’s underlying technical details.

In fact, many students I’ve spoken to have little sense of the big questions those technical details collectively try to answer: Where did the universe come from? How did life originate? How does the brain give rise to consciousness? Like a music curriculum that requires its students to practice scales while rarely if ever inspiring them by playing the great masterpieces, this way of teaching science squanders the chance to make students sit up in their chairs and say, “Wow, that’s science?”

and

At the root of this pedagogical approach is a firm belief in the vertical nature of science: you must master A before moving on to B.

In reading this, I was struck how applicable this is to most disciplines, and how the requirements of a system that uses high-stakes testing as a primary means for assessing mastery (and as the basis for funding/management decisions) squeezes out the time required for engaging students around a big-picture vision of a subject -- and how that subject really cannot be contained within curricular lines. While most subjects have a set of core competencies that allow for a greater exploration of the subject, the core competencies cannot be confused with the end goal.

Among the many benefits of open content, this feels like one of the most compelling: content that can be freely edited and redistributed allows a teacher to balance the core competencies against the big-picture understanding. If this learning is supported within a learning environment that supports student-directed inquiry, the information contained within an open curriculum could provide a supporting framework for student work. This type of blended learning environment (part online, part face to face; part teacher directed, part student directed) would allow shared focus on core competencies and larger questions.

Another Tool For Open Content

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.

Incremental Changes

From my comment on Gardner Campbell's blog:

Hello, Gardner,

As a few people have already pointed out, these are incremental moves -- Open Content has been around for a while, as have blog-based classes. I think most of us are in agreement that, in general terms, these are Good Things, and that these shifts are improvements over expensive textbooks and cumbersome, expensive, proprietary LMS's.

The incremental shifts, however, become more meaningful when considered together.

Pulling content from a closed repository isn't all that big a deal -- we've had rss for a while. But, putting high quality content into a container where it can be readily remixed and reused is an incremental step in the right direction.

Using this newly liberated content as the basis for constructing a course isn't that big a deal either. You can use a blog as the skeleton for a traditional course, or you can use the blog as a tool for fostering discussion within a network of learners. And in this case, the second approach is what generates the excitement.

If you port open content into a blog-based class where students can participate using the tools of their choosing, you are allowing students to participate in a way that doesn't shut them off from their own intellectual work. This is an enormous shift from the traditional LMS.

So, when you combine these pieces together, you get:

  1. Open Content in a highly portable, reusable format. This open content, unlike most open content currently out there, is easy to reuse.
  2. If you collect your newly created curriculum into a planning repository, you then begin to create a new body of Open Content, thus increasing the amount of good quality open content.
  3. When you import your curriculum into a social learning space (I agree w/Chris -- the term "blog" gets confusing), you create class record of student interaction around open content.
  4. Students interact in the learning space by using their chosen tools; they always have control over their work. Subsequently, they can make that into a PLE/portfolio if they want to, completely outside of the course context.
  5. All of this has been accomplished using tools that are easy to set up, inexpensive to use, and easy to administer.

All of these are incremental changes. However, when you put these changes together, they allow for a degree of flexibility and control not present in most systems. As to whether it's evolutionary or revolutionary, I don't know, nor do I really care. It's an improvement that has the potential to get high quality content to a broader range of people at a lower cost.

Open Content -- Musings

I've been thinking about Open Content recently for a few reasons -- As he does with many things, Jim Groom had a great post over on his blog about his experiences at Open Ed 2007.

Here is a lightly edited version of my comment on his post:

On days when I'm feeling cynical, I can't get around the sensation that some of the motivation driving the discussion on "issues of scalability, sustainability, localization, and other infra-structural issues" has less to do with scalability, sustainability, and culturally competent/translated content than it has to do with controlling the flow of content, or slowing the process while businesses figure out how to make money off of licensing.

Because: we have rss and atom, json, soap and rest calls, and xml-rpc, to name a few -- all lightweight methods of moving information from point A to point B. When content is transported (not referenced, but actually copied) from one place to another, it can then be recontextualized, remixed, reused -- all the things that most folks within the open content arena agree need to be happening.

One of the things that is amazing to see about what Jim and Company have done at UMW is that they have proceeded to build out a lightweight infrastructure that works. People can criticize it as unscalable, etc, but when the dust settles you have the same basic response as defenders of Wikipedia: it only works in practice.

The same is true of using existing tools to make truly open content possible -- it only works in practice. We need make broader use of the existing tools, but they need to be improved and made more friendly in order to allow the everyday user (a teacher, a student, someone working on their own without the resources of a university behind them) to access, import, and recontextualize content. These tools need to run on FOSS platforms to guarantee free availability and access.

Look At The Doggy In The Window

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.
Syndicate content