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.
>