Building on what MacKenzie has said, it's very likely that a repo that hosts "rich media" content will manifest the bitstream in several ways, based on the archival master --- for video, they could be Real (streamed), MPEG-4 (download/stream/torrent), Ogg, etc.
Such a range of manifestations doesn't (necessarily) mean there are multiple bitstreams being archived and managed and in particular doesn't mean the assets are outside the management realm of the archivist, merely that the repo implementation has multiple disseminators that can be associated with objects under management. MacKenzie wrote: > Hi Shane, > > I share your concern about preservation-ready repositories, but in this case > I think we can have our cake and eat it too... and I think this is just a > different way of saying what you said. > > There's no reason that the repository couldn't store an archival master copy > of the video that is restricted to, e.g., the repository administrator, and > also have a link in the metadata to a delivery copy, wherever it resides. It > would be nice if the delivery copy could be delivered right from DSpace, but > for special or odd formats that may never be practical (think of proprietary > formats like AutoCAD or ESRI). > > Lots of digital archives make the distinction between preservation and use > copies, and consider the use copies entirely disposable and reference them > for the users convenience. Does that make sense to do here? > > MacKenzie >> I've said this before, and I have to say it again due to my >> philosophical outlook on the issue: >> >> Using a repository record to link to an item stored elsewhere is a >> tactic that will continue to cause more difficulties in digital >> preservation. When the record and the item are stored separately, >> there is no actual structural bond keeping them permanently together >> whatsoever, and any number of things can cause the link to fail and >> the record to be useless. >> >> As a secondary resource, an item on a streaming server makes sense. It >> can be used to provide a fast-access copy to users for preview or >> viewing, and the primary bistream can still be the video file. There >> is really no reason to not include it, and simply use a link in >> another metadata field or description to provide a streaming version. >> >> Shane Beers >> Digital Repository Services Librarian >> George Mason University >> [EMAIL PROTECTED] >> http://mars.gmu.edu >> 703-993-3742 >> >> >> >> On Apr 2, 2008, at 9:59 AM, Scott Phillips wrote: >> >> >>> One strategy you may want to adopt, is to include a reference to a >>> steaming sever in your items metadata. Then have your theme display >>> that link as the file to download. This way you can separate all re >>> technology you need to run a proper streaming sever from your >>> repositry which doesnt have any support. >>> >>> Scott-- >>> >>> On Apr 2, 2008, at 14:30, "Mark H. Wood" <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Unless these videos are extremely short, that would involve adding a >>>> second content delivery model to DSpace. Users aren't going to be >>>> satisfied to sit and wait while their browsers download 5GB of video >>>> content before starting to play it. >>>> >>>> I've experimented with storing a simple SMIL document as the item's >>>> primary bitstream, and having that point to a streaming server which >>>> supplies the actual video. The problem I ran into is that SMIL >>>> support in popular browsers was poor to nonexistent at that time. I >>>> haven't retested for a while, so the situation may have improved. >>>> >>>> -- >>>> Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] >>>> Typically when a software vendor says that a product is "intuitive" >>>> he >>>> means the exact opposite. >>>> > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
