Digital archiving tools

On 3/11/11 5:45 PM, Rich Alderson wrote: Leaving the original container as-is, and having the metadata completely separate. This lets you to know that the container should never change so it can be written to a write-once medium, or copied, knowing that the data will never intentionally change. The data that describes the container, though, is known to change over time. Browsability or not.. A long-running argument at CHM for storing assets. Bitsavers, and my working internal archive, are arranged hierarchically. The big difference between the two is while bitsavers is almost exclusively by source or vendor, the internal one is really a collection of archives with differing structures depending on content. Metadata is minimal (as Richard has noted in bitsavers). The 'real' CHM archive started out as a hierarchy, but switched to directories named after the month when the asset was added, since it was becoming increasingly awkward and time consuming coming up with categories, and there was no way to automate the repository ingest process (we had hundreds of pictures taken of objects created while cataloging the collection with no manufacturer directories for them to go into for example). There was a decision that the collections database (Mimsy) was going to be the primary way to locate assets in the archive. This is the logical way to go. Hierarchical databases (which is really what you're creating with directory trees) are known to be less flexible than relational ones. The directory heirarchy is a stopgap to provide some structure for the containers until more detailed metadata can be created. If a catalog record is created at the time the container is added to the archive, and is a efficient way to browse in the database, structuring the containers hierarchically isn't necessary.