Adapted from an email I just wrote, but I think there is some good resources here, so I thought I'd share more widely. I’ve toyed around with the BagIt standard, and have a demonstrator for a very homogenous use-case (using Ruby, Ruote, and ruby-bagit) but it doesn’t factor into our DAM -> Fedora workflow yet. From my limited implementation, it would certainly be nice to see DAMS beginning to adopt it , if a few issues can be addressed, either by the standard or by convention. The biggest issue with the BagIt standard at this point is that it is exclusively a framework for transferring a collection of files, but doesn’t yet provide a way to create complex/compound objects out of the contents. The Library of Congress has been using BagIt for their Chronicaling America newspaper project ( tech notes) , but the reconstruction of objects and relationships has been implicit (based on a file naming convention) or manually done. This probably works in the simplest cases, where each BagIt item can be mapped into a compound object with either limited or embedded metadata, but I’m not sure if this could be easily applied to the problem of creating and relating multiple (heterogeneous) complex objects. Ben O’Steen at Oxford has proposed an extension to add an RDF manifest to the BagIt package to provide this sort of relationships , but I haven’t pursued that further. There has also been some recent development around combining BagIt and OAI-ORE, which might be a better way of approaching the problem using existing standards. A further wrinkle, at our end, is that our Fedora repository is holding compressed access copies of the content, which cannot be stored in the DAM (because the DAM content model fails to account for proxy objects or similar). I imagine this is going to be a problem with almost all large datastreams, and something infrastructure will have to adapt to.