Fedora plus Sakai — not quite that easy

In previous post I described to how easy it would be for Fedora to be integrated into Sakai and offered as reference the Entity.java interface as evidence. Well, it isn’t quite that easy. Two big clues:

  1. It is in the “legacy” part of the source code tree; and
  2. The interface has only getters (no setters).

Pretty damning evidence.

I still haven’t figured it all out yet, but there is this commentary in a document from last month with the title “The Sakai Framework: Proposal for Reorganization“:

Entity Bus

Fedora plus Sakai — a marriage made in heaven?

Note — there was a follow-up to this post.

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

Why Fedora? Because You Don’t Need Fedora

I’m often asked “Why is OhioLINK using FEDORA?”  (Just to eliminate any confusion at the start, I’m referring to the FEDORA Digital Object Repository, a project of Cornell’s computer science department and the University of Virginia Libraries, and not the Linux operating system distribution by Redhat.)  There are many reasons, but I was reminded of one recently while reading through the migration documentation for the 2.1.1 release that came out today.

In case of corruption or failure of the repository, the Fedora Rebuild utility can completely rebuild the repository by crawling the digital object XML source files that are stored on disk.

Berkeley’s “bSpace Images” project

Word of this Fedora-based image collection tool comes from the Sakai Library & Repositiories discussion group [Sakai Collab account required].

Project Name & Description (Short)

bSpace Images Version 1.0
The initial version of bSpace Images will focus on personal collections and provide “baseline” functionality found in existing tools like Course Gallery, ARTstor, Luna Insight, Portfolio, and Spiro. Through a user centered design process, bSpace Images features will be driven by faculty observations and interviews. Unlike the other campus offerings, its interface design will be based on the faculty’s real needs.

To BPEL or not to BPEL, quite a good question

OhioLINK is actively looking at BPEL as an option for workflow orchestration for the DRC project. I was asked recently about that choice, especially in light of a preliminary report from another team looking to use Fedora in a manner similar to the DRC. The preliminary report has not been published (I’ll update this posting when it is), and the organization involved is intentionally not mentioned here. Their questions, though, do allow for an opportunity to explain some of my own thinking on the topic.

On the Need for a General Purpose Digital Object Repository

Digital objects — we’ve all got ‘em. Billions and billions of them. And we put them in individual content silos, stratified along such unhelpful lines as media type, owning entity, and other equally meaningless categories. At least meaningless to the end user. So, let’s ask ourselves: what is the job the user is trying to get done? And how can we structure our digital object repositories to help them out?

What is a Digital Object?

Repositories Visualized

On 12/14/05 10:26 AM, Richard Green wrote on the sakai-library mailing list:
The RepoMman projectat the University of Hull, UK, is looking into the area
of workflow as related to an institutional repository. Hull sees a digital
repository as being a tool for its users, assisting them to develop a ‘piece
of work’ (a generic term intended to cover almost anything) from inception
to final form – supporting such things as development, collaboration and
versioning along the way. In other words, we see a repository as much more
than a container only for ‘finished’ digital objects. We are playing with
the acronym ‘AMP’ (access, management, preservation) to describe some of the
related functionality.