I stayed in Trac B this morning because I wanted to catch Eric Jansson's talk. We've been transcribing a lot of work recently using TEI and one of the projects he managed from NITLE is Manu. I've never been able to get Fedora to work long enough to test Manu out, I think it has a lot of potential for displaying original manuscripts in TEI with large images (you can zoom in on particular parts of the image by clicking-and-dragging a box on the area you want to highlight).
The first talk was from Ron Jantz on digital preservation. I have to say this kind of made my head swim (either that or the cold I was developing was really starting to kick in). Ron heads the Digital Preservation Services Working Group for the Fedora project, and this was an overview of what they are exploring. I don't envy this group's charge as they are attempting to look into the future and figure out a way to trace "digital originals" of pretty much everything. At a very basic level this seems very reasonable, but when you remember how quickly computer technology changes, this becomes an almost overwhelming task to undertake. What the working group is proposing as their candidate capabilities are:
- Audit trails and datastream versioning for object
- Persistent identifiers for objects
- Checksum creation and validation for objects
- Object formation validation
- Content model validation
- Whole-object version
- Event management and event versioning
- Repository redundancy/mirroring service
- Format migration engine
It'll be interesting to see how and if these capabilities are integrated into Fedora, or in parallel with specific projects.
Now for Eric's talk…
Like I mentioned above, I've had some interaction with Eric in the past and was excited to hear him talk. He teamed up with Stacy Pennington to talk a little about how they've used Fedora at a small liberal-arts college (Rhodes College in Memphis, TN) to document the Civil Rights movement in the city. Eric started the talk with a scenerio that plays out in a lot of university libraries…a librarian (or someone in the library) hears about these digital libraries and institutional repositories and goes to talk with someone on their IT team who thinks its a great idea. They then turn it over to a programmer who then starts doing some research on the Internet and comes across Fedora and notices it's a very robust architecture for what they're wanting to do. However, the programmer starts looking at the documentation and starts having questions on how to implement the project. Since there's a significant learning curve, this takes quite a while. In the mean time, the librarian becomes unhappy with the lack of progress and talks to the IT folks, who also become unhappy with the lack of progress. In the end, an out-of-the-box solution like CONTENTdm is then used since you can have a collection quickly on the web without much of any programming.
Without getting into the details of why CONTENTdm isn't a long-term solution, Eric turned the talk over to Stacy from Rhodes College. Stacy's first comments were on the size of the IT staff for the entire college: 12 (exceptionally small considering some projects have more than 40 programmers on the repository project itself). He emphasized that because of their size, they are integraters rather than developers. So why would such a small staff choose a solution like Fedora? Because it provides an infrastructure to build on that doesn't shoehorn you into a single solution (or multiple solutions depending on the scope of the project).
Stacy also talked about the frustrations they had with implementing Fedora and thanked Thorny for their help in getting them up-and-running. Some of these frustrations were a lack of a clear way to utilize Fedora as an end-to-end solution; the technical assumptions for primary integration and support for IT staff are too high; a lack of community-shared content models; and end-user expectations for the term "digital archive." I have to admit that in my own investigations I have run up against these same frustrations (and the fact that I keep getting errors when I attempt to install Fedora or one of the side projects to view Fedora contents).
One of the themes that resounded at this conference is the fact that Fedora is not "a thing in a box" that one can just install and start running. It is an architecture that allows developers (and I emphasize developers on purpose) "a way through open standards to associate meaning though digital objects". At the end of the talk, Thorny admitted to the group that these issues aren't just being seen at small colleges. He remarked that the only people at UVa who could implement the software were the people developing Fedora.
To this end, NITLE is developing spiffy, a PHP framework for working with Fedora. While Eric and I both share a general dislike of PHP, it does make sense to use it as a language to get more people using the repository. PHP has a great user-community that he hopes will "create an ecosystem of innovation (building bazaars, not cathedrals)," empower technical staff and developers, and build user experiences on top of Fedora.
Eric also argued (and I have to admit it was one of the better ideas I heard at the conference) that 1/2 day training sessions to get people familiar with Fedora would be invaluable to growing the community. The Fedora project has been going on for almost six years, and the vast majority of projects out there are vaporware. The way to actually get to the next level is to grow the community through training, interaction, and simplification.