Sakai 3: The Benefits of 'Everything is Content'

One of the more radical departures that Sakai 3 makes from traditional LMS design is that everything in the system is treated as content. A traditional LMS is an aggregation of tools—discussion boards, grade books, test engines, wikis, assignment drop boxes, etc.—each of which has its own data model in a relational database. It’s really a hodgepodge of separately designed tools that are knitted together through a user interface layer and a few common services. In contrast, Sakai 3 is being built on top of the Apache Jackrabbit reference implementation of the Java Content Repository (JCR) standard. Everything is treated as content, including grades, test questions and answers, discussion threads, syllabi, personal profiles, chat messages, and so on.

This approach has some benefits in terms of shoring up common weaknesses in LMS designs. But, more profoundly, it also leads to some pretty fundamental changes in the way that learning environments can work, thanks in large part to the strong and growing adoption and maturation of useful content integration standards.

Let’s start with the more mundane improvements. There are several areas where, because of their design heritage, LMSs tend to be weak and Sakai 3 can be better:

• Search: Developers for traditional LMSs have a very hard job when it comes to designing effective search. They have to figure out how to index the data from all the different tools. They have to figure out how to scope the search to the appropriate context, e.g., am I searching just this discussion board, just this course, or everything in the LMS? They have to figure out who has permission to see what. It’s messy. As a result, most LMSs don’t do search particularly well. In contrast, Sakai 3 is being built from the ground up on top of a content repository, which was designed precisely to handle search use cases. Theoretically, search in Sakai 3 should be best-in-class.
• Tagging: In some ways, this is just an extension of the search problem. Developers in a traditional LMS architecture have a real challenge wiring tagging uniformly into a very non-uniform system. As a consequence, there are lots of places in a traditional LMS where tagging could be useful but doesn’t exist. Once again, with everything stored in a content repository, adding universal (and useful and consistent) tagging should be much easier in Sakai 3.
• Archiving: A third area where LMSs typically struggle is in mass course archiving, and once again for the same reason. It’s hard to figure out ways to archive “courses” efficiently when they consist of a bunch of loosely connected tools with a hodgepodge of data models. As a result, most LMS archiving tools are cludgy (and Sakai 2.x may actually be worst-in-class in this particular area). It’s hard to capture everything in the courses, and even when you do, the process usually isn’t very performant. A faculty member archiving a single course may be OK, but doing an entire semester’s worth of courses can be ugly. On the other hand, if everything in your LMS is stored in a content repository, then you can treat everything like…well…content. Archiving should be much easier, much more performant, and much more uniform.

Those are some of the useful but boring benefits that come from the “everything is content” architectural approach. But Sakai 3 isn’t just being built around the general idea of “everything is content.” It is specifically being built on Jackrabbit, the Apache project that is the reference implementation for the JCR standard. There are benefits here for both Sakai-internal design and integration with external systems. Regarding the Sakai-internal design, Sakai 3 is being built not only on Jackrabbit but also on Apache Sling, which sits on top of Jackrabbit and provides RESTful APIs for almost the entire JCR standard. This gives Sakai developers a very broad and deep toolset for doing HTML/Web 2-style development without requiring a lot of Java heavy lifting.

Jackrabbit also provides some interoperability benefits. Now, JCR itself has achieved some adoption success, but not at the level that one might have hoped. Most enterprise content management systems support only a subset of the spec, often read-only. Jackrabbit is the only implementation I know of that covers almost all of the JCR specifications. In the higher education world, Sakai 2.x, Moodle, and Xythos all support some subset of JCR. So there is some value here. But the greater value by far is that Jackrabbit, being an Apache project and the reference implementation for JCR, integrates with other projects that support more interesting content integration possibilities.

Basic Syndication and Publishing: Atom and Atom Publishing Protocol (APP)

Atom and APP are the foundation for almost everything that follows in the rest of this post. They are the fundamental building blocks, with the other standards being mostly just Atom and APP with some extensions added. Jackrabbit has been integrated with Apache Abdera, a set of tools for producing and consuming both Atom and APP. (More on this integration in a bit.) Let’s look at these in turn.

The idea of producing or consuming an Atom feed should be pretty familiar to most folks by now. The utility of being able to add a syndication feed to, say, a discussion board, an announcements tool, or even a gradebook, is fairly straightforward. As with the benefits I described above, Sakai 3 will benefit here from storing everything in a content repository, as well as from the fact that Atom integration would happen at a repository level. It should be relatively easy to add syndication feeds uniformly and universally to the LMS. Likewise, it should be straightforward to pull syndication feeds (say, from self-hosted student or faculty blogs) into the course environment. This is all very useful, but at this point in the adoption curve of syndication, it’s starting to feel a bit like the benefits I listed above, i.e., like it corrects a somewhat embarrassing design flaw rather than adding something new and exciting. One bit I would add that is often overlooked as a difference between Atom and RSS is that Atom can represent threading, so it’s possible to syndicate discussions in a more sophisticated way. This could have some implications for PLEs. (More on this in a bit as well.)

Atom Publishing is a bit more interesting. To start with, it’s one of the protocols that desktop (and now mobile) blogging clients use to publish content to a remote blog. Support of both consumption and production of APP could be beneficial in an LMS. On the consumption side, it certainly could be useful for tools similar to blogging clients to be available for offline authoring. We in the developed nations, with our near-ubiquitous connections, tend to forget that there are literally billions of people who need an education and whose online access is limited. APP isn’t the only way to support offline work, but it adds another arrow to the quiver. But the production side is even more interesting, in my opinion. Getting content into an LMS isn’t as hard these days as getting content out of it. I can imagine building an APP authoring interface into Sakai 3 that would enable students to publish any content item they have authored in the LMS context out to their own personal blogs, tagging and commenting on them in the process.

I’m not the only one who finds APP to be intriguing. A number of folks have been working on adding extensions to it (the Atom and APP standards specifically support extensions) to support a variety of publishing use cases.

GData

Some of those folks work at Google. Google’s extensions to APP are called GData, and quite a few of Google’s APIs are based on it. Apache Abdera supports GData, which means that Sakai 3 developers would have a leg up on programmatically integrating with Google’s tools. There are many interesting possibilities, many of which are already being cobbled into current-generation LMSs one at a time. Here are a few:

• Enable students to go out and comment on web pages using Google Sidewiki and aggregate those comments for further discussion within the course environment.
• Enable students across course sections to share book reviews using Google Book Search.
• Give users the ability to make Picasa their default storage location for images rather than the local LMS.
• Build data visualization applications that have Sakai-native and specialized user interfaces but use Google Spreadsheets on the back end.

LEAP2A

LEAP2A is an extension of APP out of JISC/CETIS for simple ePortfolio data exchange. For a long time, ePortfolio interoperability standards have suffered the same issues that content management standards hit, i.e., they were so ambitious in trying to cover all the use cases that they became very difficult to implement. (Hello, JCR.) LEAP2A scales back to the most common set of scenarios. So far, it has limited adoption, but the fact that Moodle and Mahara (Moodle’s sister ePortfolio project) are using it as their interchange format is very promising. With Sakai 3’s architecture, adding pervasive LEAP2A support should be significantly less difficult than it would be on current-generation architectures.

SWORD

SWORD is another JISC-funded extension of APP for academic purposes—this time for depositing content into curated archives. (Those Brits sure do love their APP.) If you’re using an LMS space to collaborate on a thesis or a journal article or a work of digital art or a scientific data set and intend to submit it to an official repository of some type, SWORD is the way to go. Fedora, DSpace, and EPrints all support taking SWORD deposits. As far as I know, Moodle is the only LMS to have a SWORD integration so far although, surprisingly enough, there is a SWORD Facebook app. The blog post at the end of that link lays out some ideas for what the author calls a “social deposit”, which provide some food for thought in the Sakai 3 context. If Sakai becomes the hub of one’s academic (network another theme of Sakai 3), then academic submissions are indeed activities that you would want to have associated with your profile. Once again, Sakai 3 developers will have a leg up in terms of adding pervasive SWORD support because of the architecture.

CMIS

In some ways, this could have the highest impact of the lot. CMIS is an emerging OASIS standard that has just caught fire. It is a programming language-neutral content interoperability standard. More lightweight than JCR, CMIS already has implementations on a wide range of platforms, including Drupal, Joomla!, Alfresco, eXo, Liferay, Sharepoint, and Filenet, with other big content management vendors (e.g., Oracle and EMC) participating in the working group as well. There are also desktop and mobile CMIS browser clients. This is an enormous amount of activity for such a young standard.

One of the more high-profile open source CMIS implementations is Apache Chemistry which (you guessed it) integrates with Apache Jackrabbit. CMIS has both APP-based and SOAP-based APIs. Chemistry supports both, and uses Apache Abdera for their APP-based integration. (Hence, the Abdera/Jackrabbit integration.) With CMIS support, Sakai 3 could easily allow users to publish content into it from various content repositories (or their desktops or their phones) and, equally importantly, publish content out of it to a variety of systems, including lightweight open source systems that they could run themselves.

The Implications

I don’t want to pretend that all of these benefits will just automagically appear in Sakai 3. There will be work involved. It’s just that the amount of work involved is small enough to make it practically possible, thanks to the design choices in the Sakai 3 architecture. Assuming that the work does get done, there’s something here to please edupunks and university CIOs alike. On the edupunk side, the LMS suddenly becomes highly permeable. I have never believed that RSS is sufficiently rich to support widely adoptable and broadly useful PLEs. But I certainly believe that this range of APP-based protocols is rich enough while still remaining lightweight enough that individual innovators can play. And if you start with an LMS architecture in which everything in the system is content, you’re much less likely to end up with corners of your garden that are still walled off, not so much by choices as by default, since getting at the data is too hard. The LMS becomes just one place among many for educational content to be created, organized, and shared. It coexists peacefully.

CIOs are also likely to find a lot to please them too. Right now, colleges are awash in content management point solutions. If you think about LMSs, ePortfolios, digital archives, learning object repositories, collaboration software (e.g., Drupal and WordPressMU) and so on, there is just a ton of content that’s in these little siloes that is hard to manage, back up, archive, and generally support. But if most of these applications begin to support content integration standards, it becomes possible to have a sane university-wide system for handling all this data and reduce the load that it puts on many, many different systems. In some cases, you can centralize, storing canonical copies in an enterprise content repository and letting other systems access it transparently. In other cases, you can simply move the content around when that’s useful through syndication and archiving. The point solutions don’t go away, but the infrastructure for supporting them becomes more unified and therefore more manageable and cost-effective.

Bowling scores will go way up; miniature golf scores will go way down.