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 [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 _______________________________________________ Dspace-general mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/dspace-general
