Fedora a Better Repository Alternative?

A Vision for FEDORA’s Future

The Fedora Project recently released version 2.2 of their Fedora repository system and Peter Murray provides a nice summary based on a presentation by Sandy Payette, Fedora co-director. I have been thinking about this stuff a lot of late as we start to craft a digital library infrastructure here at UPEI. I have also been talking with some bight people like Mark Jordan, Dave Cormier and Grant Johnson (UPEI) to help me understand all this. Fedora provides a much more flexible Web 2.0-ish architecture than the more commonly used DSpace, but it also requires a little more work to get things up and running. The advantage to this is that you are not hampered by the application skin/model as per the out-of-the-box interface, which is the one problem I have with DSpace. The disadvantage is that you either have to hamper yourself by using a Fedora interface layer, such as ELATED, or you need to write your own. The write-your-own approach seems to me the best one to take if you have wide-ranging repository needs and can muster the resources. For example, at UPEI we would like to be able to integrate the repository into our eJournal and document efforts, institutional repository, archives and records system, digital archive collections, learning object repository, the kitchen sink database, etc. Rather than kludge something like DSpace to fit all of these, you could use Fedora in a generalized way and then build/borrow/bastardize (the 3 B's of open source development) the appropriate tool or interface depending on the task at hand. For example, we would build a widget to integrate the Fedora repository into Moodle as a back-end LOR, allowing use of the same object in the learning environment and elsewhere.

In another example we are migrating the Library and campus websites to Drupal over the coming months. Drupal has very nice groups functionality, allowing fine control over what is presented to the user and when. This could form the basis of a highly functional and tightly integrated alternative to the DSpace Communities model directly in the website. The following scenario illustrates what I call common data destiny: there is not really that much data out there, but rather a small core of information that we all re-craft in some way; if we can find a way to tap that core more efficiently, life will be good. Scenario:

• I Chair a Committee which has just finished a long-awaited report;
• I log in to the campus website and click on the link for the Committee;
• the interface presents a list of items specific to me as a Committee member, including a submit-to-repository" widget on the side;
• I click the button and upload my report, including a couple of fields of information (title, date);
• the system deposits my report in Fedora adding a ream of additional metadata it gleans from my Drupal/LDAP profile and the document itself;
• my Committee page automatically changes to reflect the new item;
• the News page in the campus website updates it's aggregate RSS feed from the repository;
• Drupal sends out e-mail notices to all Committee and community members based on the deposit of a new item;
• a posting is automatically made in the appropriate University Discussion Forum, providing a seed for further discussion;
• the toilet flushes in the 4th floor washroom to signal the job is complete, life is good and the universe unfolds as it should :-)

Now, with the exception of the last one, this is all possible with a little creative programming and a desire to be more efficient. [And I'm sure we could solve the last one at the Access Hackfest.] I can imagine doing this with a Fedora back-end or a native file system data store, but I have a hard time imagining this with DSpace or any other system at that level.

The one thing that worries me is that you are still ultimately confined by the application, in this case Fedora. I like the idea of having an even more granular system (what I call "Outer Space") that need only rely on a file system where XML metadata and digital objects are stored. You then build or install the appropriate application as needed. This was part of the philosophy behind the Martini project. The obvious problem with this is that you will need to build a lot, or at least install applications that provide the appropriate functionality, to use your data store. The proliferation of systems and tools could quickly overwhelm any organization and for a smaller institution like UPEI I'm not sure that is a sustainable direction. Fedora or Outer Space...Decisions, decisions...

Scraped from Disruptive Library Technology Jester

Comments

[Bill Fitzgerald]

Hello, Mark,

Great post -- it highlights some of the potential tensions between the front end UI and the backend file handling/scalability issues --

Your sample scenario could be managed nicely in Drupal -- the Actions and Workflow module could handle the emailing (and possibly even the forum posting) on creation of a new doc -- the rss update would work out of the box.

And we're currently working up some code to pull the handle in the fourth floor washroom :)

Cheers,

Bill

[mleggott]

Hi Bill - thanks. I will be looking for that handle puller in the 2nd quarter :-)