 |
 |
Instead of purchasing a discovery system, I recommend using blacklight<http://projectblacklight.org/> Ethan On Mon, Mar 29, 2010 at 2:49 PM, Adam Wead <[log in to unmask]> wrote: > Hello All, > > This is my first post to the list so I thought I'd share my current dilemma > and put it to you all to see what you might do if you were in my place. > I've really tried to keep this message as short as possible, but it's still > too long. I apologize in advance for that. I can fill in more detail as > the discussion progresses. > > I'm the new systems and digital collections librarian for the Rock and Roll > Hall of Fame Library and Archives. I've been in the job for about two > months now and have been gathering lots of information on requirements. The > Rockhall library will open to the public for the first time at the end of > this year and one of the things we're going to need is a digital asset > manger. I'll briefly give you a list of some of the requirements that we're > looking for, then a list of what possible solutions I've come up with, and > close with problems I currently face. > > -- DAM requirements -- > > Currently, we have no digital content, but will be building the > infrastructure and workflows necessary to deal with the following: > > Video: manage archival JPEG2000 and MPEG4 files created from a variety of > analog sources, stream derivatives, handle descriptive metadata as well as > text annotations and transcriptions of video segments, and manage new > archival and access video objects created from edits of MPEG4 sources. > > Audio: manage archival 24/96 broadcast wav files and stream mp3 or > equivalent derivatives, handle catalog metadata > > Images and Documents: same as audio, but with hi-res tiff images and > jpeg/pdf, or similar derivatives > > -- Possible solutions (and their drawbacks) -- > > DSpace: great for images and documents, not so good with video or audio? > Also, complexity of video datastreams suggests another solution... > > Fedora: flexible enough to handle both JPEG2000 and MPEG4 formats for a > single archival video, as well as the text objects and future creation of > edited videos from multiple archival sources, similar to WGBH's OpenVault. > Downside: Extremely complex and code-intensive to develop and manage. > > Proprietary options, ex. ContentDM, DigiTool, and others: I am unaware of > their video capabilities at the moment. Image and document data seems to > work best. Downside: will likely be cost-prohibitive. > > -- Problems -- > > I need to come up with a realistic goal. I'm a one-person show here... > While we probably won't be able to afford a nice vendor solution--assuming > one exists that fits all of our needs--it would be just as costly in terms > of time for me to learn, code and deploy a complete solution using the open > source alternatives I've listed above, and I know I've missed some. > > I have a lot of catching-up to do. I'm great with unix systems, databases, > PHP and Perl; Java and XSLT, not so much. I'm taking a look at Python and > Ruby because I can build and deploy things faster with them than PHP or > Perl, they already have some Fedora libraries for them, and they are easier > for me to wrap my head around than Java, but it will take a while to get > fluent in either of them. > > So, what would you do? > > The idea I have in mind at the moment goes something like this: > First, we're going to purchase a discovery system that will harvest records > from our soon-to-be-created MARC library catalog, and soon-to-be-populated > archival manager, Archon. Using that discovery service, we could harvest > from one or more DAMs such as DSpace for images and documents, and maybe > even audio; and Fedora or some such other system for video. Fedora would be > ideal for our video collection, and everything else for that matter, but > very, very time consuming to construct. Assuming I could build the back-end > of fedora enough to allow some rudimentary ingestion of objects, the > discovery interface could at least serve those objects out in some way by > letting users know that they exist. Actually streaming the video or audio > is another story... but, if the discovery layer is there, I could build a > nicer interface for deployment at a later date. > > Since we don't open for another 9 months, and have no data to manage yet, > that's time to start working on a Fedora backend, or research and create > another solution. I've looked at Fedora front-ends like Fez, Islandora, and > Active-fedora, but they are limited to which version of Fedora they can use, > and I can't get a feel yet for how they would deal with our requirements. > > If we can coast by on a discovery-only type solution, that could give me a > year (?) to build a nice interface or retool an existing one for our use. > So, 9 months for a repository, one year for a full interface. Given my > above limitations and desire not to work 80 hours a week, is something like > that feasible, slightly ludicrous or completely insane? > > If it's not really feasible, then I might be looking at a collaboration > with one or more of you fine people, or finding some money from my > organization or a grant to help pay one or more of you fine people for help. > > So, I close this already way too long email with a final: what would you > do? > > Many thanks, > > Adam Wead > > > Rock & Roll: (noun) African American slang dating back to the early 20th > Century. In the early 1950s, the term came to be used to describe a new form > of music, steeped in the blues, rhythm & blues, country and gospel. Today, > it refers to a wide variety of popular music -- frequently music with an > edge and attitude, music with a good beat and --- often --- loud guitars.© > 2005 Rock and Roll Hall of Fame and Museum. > > This communication is a confidential and proprietary business > communication. It is intended solely for the use of the designated > recipient(s). If this communication is received in error, please contact the > sender and delete this communication. >