[Dspace-general] [Dspace-tech] Week 4: Bitstream types

Dorothea Salo dsalo at library.wisc.edu
Mon Sep 8 12:24:31 EDT 2008


I have all the same A/V problems Mark Woods talked about. What makes
me unhappy about the SMIL/stream solution is that (if I understand
things correctly, which I may not) I don't actually have the video
file under DSpace's control for checksumming and so forth. There are
ways around this (the file can live in two places!), but they seem
cumbersome and they increase storage-space requirements heavily.

Multimedia is also a problem just as Mark said, but let me toss into
that mix compound objects like Flash learning objects. As I understand
the structure of those benighted things, they act a little bit like
HTML files, calling out to external resources like images and movies
and whatever. *Unlike* HTML files, they're troublesome to rewrite, so
to ingest them usably, we'd have to be *extra*-careful to maintain
their directory structures... and I don't even want to *think* about
ones that access resources by URL/URI, ugh.

Here's a question I've never had an authoritative answer to: Suppose I
put a mess of audio files in their own collection. Is the RSS feed
from that collection podcast-friendly? If it isn't, how much work
would it take (especially in XMLUI) to make it so?

Other problems I've run into, along with potential solutions:

- Individual page-scans. Not only do these look unconscionably messy
on a DSpace item page, DSpace has no innate sense of bitstream order,
which makes it *really* hard to tie in an outside page-turner app.
What I've historically done is squish the scans into a (somewhat
lower-quality) PDF via ImageMagick and ps2pdf, and throw that in along
with the scans. This is -- okay, it's a gross hack, but it does well
enough for the purpose, I guess. The display-messiness problem might
be solvable with a Manakin theme, but again, there aren't really any
hooks in DSpace to make this easy (though hm, *maybe* the "primary
bitstream" notion could be repurposed), meaning any "solution" is
going to be an ugly kludge.

- Image collections. DSpace's usual browses are pretty grotty UI for
this purpose. I'm looking at doing some kind of thumbnail browse in
Manakin; it shouldn't be *that* hard. (Famous last words.) We might
also want to look at what third-party whizbangs like PicLens/Cooliris
need to do their magic.

- We've run into problems in 1.4.x opening large PDFs in-browser. We
*think* this was partly because of our bitstream-handle hack, and we
also think the rewrite we did of that for 1.5 will solve the problem,
so stay tuned.

- Specialty metadata and persistent bitstream URLs for mashups. GIS
metadata is a pain-point here. My colleagues on the digital-library
side of the fence have done super-cool things with local collections
and Google Maps. I know Manakin makes some of this possible because
I've seen the demos, but I'm not smart enough to figure out how to
make it work on my own.

I think those are our big pain-points. I may think of more as the week goes on.

Dorothea

-- 
Dorothea Salo dsalo at library.wisc.edu
Digital Repository Librarian AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493



More information about the Dspace-general mailing list