Skip Navigation - Go to page content

Archival Note: This project is no longer current. Information and links contained in these pages may no longer be up-to-date.

Solutions- Encapsulation

This is a method largely developed by Cedars, but is based on the OAIS methodology. Cedars assume that the actual process of migrating files will certainly result in losses of the original properties of the digital object(1) . In their project recommendations, they state that it is safer to preserve the simple byte stream of the object separately from the medium it was created on. Thus if the software to run it becomes obsolete, newer software can be applied to the byte stream to make it readable.


This method is also known as 'Migration on Request'. When a user requests a digital object from the archive, a migration of the byte stream is carried out automatically. This, in effect, separates the content from its format. Thus the object is more authentic, as it is always stored in the byte stream in which it was created.


This is to some extent the process of combining an emulation approach with migration, as one has to preserve a tool with the digital object to migrate it to its original platform. The tool referenced in the metadata could either be a software specification or an emulator to mimic the hardware or software environment.
This goes against the notion that digital objects should be continually migrated to ensure accessibility; they can lie 'dormant', so to speak, as byte streams, until they are needed and then software can act on them.

Underlying abstract form
When converting a file to a byte stream, it is vital that when it is accessed, the file can be re-converted into a readable format, in other words, a reversal of the Ingest process. In order to do so, it has to be decided at the Ingest stage, what the 'significant properties' of the file are, so that when it is accessed, the original contents and the way the file was put together can be interpreted. This abstract representation, or underlying abstract form (UAF) is separate from the software that it was created on.
For a CD-ROM, the UAF would be its file tree. In a web page, the highest-level entry point should be noted, index.html for example. In more complex objects, it will however be harder to ascertain what the UAF is. Nonetheless, when the UAF for each file type has been decided upon, it can be re-used when archiving the same file type again.

READ MORE:


Paul Wheatley explains this in full at:

http://www.personal.leeds.ac.uk/~issprw/camileon/migration.htm

Rothenburg's article also touches on this in his paper, 'Avoiding Technological Quicksand: finding a viable technical foundation for digital preservation', Council on Library and Information Resources

http://www.clir.org/pubs/reports/rothenberg/research.html#summary

(1) Wheatley, P Migration - a Camileon discussion paper Available at: http://www.personal.leeds.ac.uk/~issprw/camileon/migration.htm

HOMEPAGE