Sousa Motivation

Way back at the dawn of the Sakai project, a group of people connected with the Sakai Educational Partnership Program (SEPP) formed a discussion group on the topic of content management and authoring. Two missing elements in Sakai were noted by this group: good content management and support for authoring content.

Since that time, substantial work has been done on the Resources tool and Content Hosting Service, largely thanks to Jim Eng and (more recently) Ian Boston, nor can we overlook Glenn Golden's early work. Some of this work has addressed missing requirements identified by the content group: bulk upload, support for ZIP, content handlers, etc. JCR will eventually address additional concerns, like version control.

Melete also came along after that time and filled another gap to create module-oriented, self paced learning content designed to work well in blended learning situations. Besides being the cornerstone of ETUDES, Melete has been adopted by several universities and is in good use.

In spite of all this good work, I believe that Sakai is not where it should be with respect to content. Even a casual look at Moodle will show just how rich that environment is with respect to teaching and learning. It is partially for this reason (and others) that I started work on (what is now called) Sousa. I think one of the strengths of Moodle is that it has support for several different approaches to content creation and it's pretty easy to add new approaches and tools. Granted, PHP substantially lowers the barrier to creating new content editors, but this can be addressed, even in Java.

Sousa is not ready for general use in Sakai. However, it is reaching the point where interesting experiments with content authoring and delivery can be conducted in Sakai. I have created a modular, plug-in architecture to support new media types in Sousa that make it VERY easy to add new ones. For example, I added support for VRML in about 45 minutes. That (early) work didn't include support for editing (which is being added right now), but even at a few hours, that's a powerful statement about it's flexibility.

From an organizational viewpoint, content breaks down into atomic elements that I variously call content items or media and ways to organize them. These include things like text (including marked up), images, video, audio, and all sorts of other things. Organization is chunked at various levels: there is some kind of page view, a sequence of pages (or items), collected sequences (modules), and packages. Personally, I don't think there is any one RIGHT way to do any of these things. It's so dependent on teaching and learning styles that I am VERY hesitant to impose any kind of restrictions. As such, I foresee several kinds of page types for Sousa (it currently supports two - grid layout and raw content items). I also see different kinds of sequencing (linear, branching, remedial, etc.). Modules can and should be organized in different ways to support higher level learning structures. Packages, however, are deliberately designed to support interchange standards such as IMS-CP, IMS-CC, OCW, etc.

The other thing I've done with Sousa that should be considered by this group is to layer and leverage existing Sakai capabilities. Currently, Sousa is solely based on the Content Hosting Service for storage. Sousa doesn't even have it's own database (thought that could change). Among other things, this allows an author to use different tools to work with the same data: upload and organizing files using the Resources tool, then sequence using Sousa, and delivery via Assignments (TBD) and a Sousa player. Melete is moving in this directly as well, I believe.

I offer these comments not so much as saying that I have the right answer, but rather to bring up some ideas I've considered that may have bearing on the problems this group is starting to consider. This particular set of problems is FAR bigger than any one person (or even group) can fully define, much less address.