What happens when you mix two Mellon-funded projects? Perhaps a nice bit of what they call synergy. The thinking goes something like this…
Sakai
“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
“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.
4 Comments
At MIT we’re doing a little mixing of Sakai and Fedora (plus sprinkle of O.K.I. a lot of our own stuff) in Stellar images, a project that revolves around gathering images from repositories, mixing them with your own and building slide lectures. Some info here: https://confab.mit.edu/confluence/display/STLR/Images
Thanks, Ben. I’m not all that familiar with OKI (except to know that I should get more familiar with it) — could it be a good glue between a resource consumer like Sakai and a resource provider like Fedora?
In the near future, for the bSpace Images, we will explore authorization/authentication issues/approaches between bSpace and Fedora. Essentially Fedora will be our “image repository” within Sakai. Our level of integration with Sakai’s default Resource Tool may be limited to a means for users to add content from the Resources tool to their image personal collections.
Hello Ben, would you be able to share more details on Sakai integration with Fedora?
1 Trackback
Post a Comment