“The Sakai Project is a community source software development effort to design, build and deploy a new Collaboration and Learning Environment (CLE) for higher education. … The Sakai Project’s primary goal is to deliver the Sakai application framework and associated CMS tools and components that are designed to work together. These components are for course management, and, as an augmentation of the original CMS model, they also support research collaboration. The software is being designed to be competitive with the best CMSs available.”1
Written in the Java language for a servlet container, it is an example of some of the best thinking and work in the creation of a course management system (CMS) or a learning management system (LMS) [that plus “CLE” — how many acronyms do we need?] in the open source arena. It is truly an example of how higher education can take command of its destiny.
“Fedora open source software gives organizations a flexible service-oriented architecture for managing and delivering their digital content. At its core is a powerful digital object model that supports multiple views of each digital object and the relationships among digital objects.”2
Also written in Java to run in a servlet container, it is the best of the basic research of the general characteristics of a digital object implemented in an easily approachable (and again — open source) application.
Mix Together with a Glob of Glue
Our latest thinking about Ohio’s general purpose digital object repository (based in Fedora) has a potentially interesting intersection point with Sakai. In looking at
the latest releases of the Sakai framework, it appears that the developers have consolidated all of the repository functions into one tidy unit they call “Entity“.
The methods for the Sakai Entity interface are:
- getId: Access the id of the entity.
- getProperties: Access the entity’s properties.
- getReference: Access the internal reference which can be used to access the entity from within the system.
- getReference: Access the alternate internal reference which can be used to access the entity from within the system.
- getUrl: Access the URL which can be used to access the entity.
- getUrl: Access the alternate URL which can be used to access the entity.
- toXml: Serialize the entity into XML, adding an element to the doc under the top of the stack element.
If this pans out, it should be relatively straight forward to swap out Sakai’s built-in repository infrastructure with that of Fedora. At the very least we’ll need some new content models and disseminators. So we’d have some more work to do on the Fedora end of the equation (and the Sakai end is a bit of an unknown to us at the moment), but on the surface it seems possible.