Warning: I am a paper conservator who knows her way around a computer, but that doesn’t mean I totally get all of this. We’re starting to consider doing work like this at my home institution, so I thought I’d better see what it was all about. Luckily, there are a lot of pictures of slides, and it was presented in such a way that I just saw it as another case of documentation of an artifact – it just happens to have many moving parts (literally). Oh. And I apologize in advance for the photobombing microphone stand in the slides.
The basic summary is that the Tate collaborated with Klaus Rechert from Freiburg University to develop a workflow, and created a report describing a framework for the use of emulation for preservation of artworks. This was made possible by PERICLES, a European funded project which focuses on evaluating and representing the risks for long-term digital conservation of digital resources. As part of that collaboration we then tested that approach in a workshop with the participation of Dragan Espenschied of Rhizome on works from the Tate’s collection. One of those artworks was “Subtitled Public” by Rafael Lozano-Hemmer (T12565).
The emulation challenge with “Subtitled Public” (2005) was that it involved electronic and live components in addition to the operation of cameras. Good news is this is one artwork that was deeply documented, so it was a good test case for developing a workflow. Below is the extent of the documentation (BTW the computers were Mac Minis):
Selecting Preservation Strategies: These are the Essential Steps, which are complimentary:
Note on artwork’s significant properties: one of the elements of the artwork is projecting words on people. The entire artwork would need to be reinstalled in order to compare completely and properly.
Note on resources, sustainability, and application: how many artworks can you support? You need to think about the collection as a whole; resources, sustainability, and application for the long term.
Defining boundaries will help you identify commonalities among artworks, which can help with prioritization and creating systems that will work for multiple artworks.
In the emulation environment, you have the artwork itself as a digital artifact. This does not change over time and can one of any huge number of different objects. The computer system are a rather small number of different hardware environments, but they require constant replacement.
In between is the most interesting work to approach the problem: keeping the operating system monitored and functional. If the OS is interfering with artwork directly, monitor and maintain technical interfaces (OS and CS – hardware environment).
So why do it this way? Scalability!
Making emulation approachable is the ultimate goal.
- Image disk and normalize it. Make it work in an emulator. Unify hardware configuration. Disk controller issues may appear if moved to different emulator.
- Generalize disk image otherwise you’ll get the blue screen of death. Goals: All images share the same technological risks.
- Yay! It works! Changed a layer on top to original image to get it to work, but the original image was untouched.
EaaS: automate image ingest of disk image. Select matching machine template. Automatic check of hardware configuration of operating system.
The proposed workflow is reversible and recyclable. One can try different ways and every revision can be forked.
The operating and computer systems are not specific to the work itself. Emulation can be considered since the digital artifacts and the hardware are not tied to the artwork itself.
Unfortunately, the entire installation couldn’t be completed, so further testing needed for this artwork. But now they understand the process, and disk images are captured and archived.
