An Exploration of Significance, Dependency, and Virtualization in the Conservation of Software-based Artworks

Patricia Falcao, Annet Dekker, and Pip Laurenson

ABSTRACT

Tate is actively involved in the conservation of software-based artworks in its collection. This paper builds on research carried out at Tate over the past twelve years, bringing together the investigation of significant properties with more recent work focused on understanding dependencies and developing strategies to mitigate the risks associated with technical obsolescence. The research described in this paper is based both on the day-to-day practice in Time-based Media Conservation and on results of Tate’s participation in the European research project PERICLES, which was a four-year European funded project focusing on evaluating and representing the risks for long-term preservation of digital resources.¹

We begin by proposing a function-based typology for software-based artworks to aid in describing the artworks, and will then proceed by introducing two case studies that illustrate our findings. In the following section, we describe the key concepts of significant property and dependency as a way of informing decisions about what is important to preserve. After a short technical explanation of disk imaging and virtualization, we proceed to contextualize it within our conservation practice, by explaining in more detail the dependencies specific to these artworks, and the strategies that we are developing related to virtualization to address these dependencies.

SOFTWARE-BASED ARTWORKS

When we use the term software-based artwork, we mean that software is its primary artistic medium. These works form complex systems of hardware, commercial and custom software, and various interfaces such as screens. These systems also exhibit a range of functions and behaviors, including response to activities or engagement of visitors. To distinguish between various types of software-based artworks, we defined the following typology:

Types of software-based artworks:

A. Contained: no external influence on the software
B. Networked: the functioning depends on external data
C. User-dependent: user may change or distribute (parts of) the code or the actions of the user may be a combination of both
D. Generative: the work constantly changes through software; it can be contained or dependent on external inputs (e.g. scrapers, bots etc.)

This typology builds on the thinking of the Variable Media Network (Depocas 2003) and Graham and Cook (2010), who both strategically describe media art—a larger umbrella of artworks including software-based art—as behavioral instead of using merely object dependent terminology, which would reveal little about the functioning of an artwork. Shifting the focus to a work’s behavior reveals more information about the presentation and perception of the work. Moreover, the typology defines software-based artworks not only in terms of behavior, but also in terms of dependency. It also gives us an opportunity to recognize similar challenges within different types. It is also important to note that whether a work is created in open source or proprietary software or a combination of these two is relevant for all the typologies mentioned above, and has deep implications for the conservation of software-based artworks. This has been explored in detail by Dekker (2016).

For the purpose of this article, we focus on two artworks from Tate’s collection that deal with increasing challenges of software obsolescence and represent two different types of software-based art. The first is Michael Craig-Martin’s (b. 1941) work Becoming which we classified as a type A, a contained software-based artwork (fig. 1).

In 2003, Tate acquired their first software-based artwork, Becoming (2003) by Michael Craig-Martin. As a conceptual artist and painter, Craig-Martin is best known for his drawings of ordinary, mass produced functional objects that he altered or assembled in specific ways to draw attention to relationships between form and purpose. Becoming follows Craig-Martin’s practice of exploring the notion of emergence to visibility and identification, and the concepts of representation and recognition.

The work is a computer-generated animation displayed on a wall-mounted, customized LCD screen. A series of Craig-Martin’s elementary line drawings, vividly colored, fade in and out of visibility against a fuchsia pink background. The eighteen objects (a chair, a pair of pliers, a tape cassette, a fan, a pitchfork, a sandal, a light bulb, a drawer, a metronome, a book, a bucket, a TV, a flashlight, a safety-pin, a knife, a pair of handcuffs, and a medicine jar spilling pills) overlap and appear and disappear at random. The result is a constantly changing composition.

Daniel Jackson, of AVCO, wrote the script to create the intervals and the varying degrees of transparency of the images in the programming language Lingo, using Macromedia Director. As part of an exhibition, Becoming is presented as a ‘painting’ that can be hung amidst other artworks. The work does not require interaction from visitors and is built with customized proprietary software and hardware. As such, it belongs to the first type of software-based artworks: contained, using proprietary software, but without any external influence on the software.

Despite being technically straightforward, Becoming is vulnerable to change. In previous maintenance to the work’s software, it became clear that an important aspect of the behavior of the work—in this case, the speed of the changing composition—can be severely affected by changes to elements of the work’s environment; this will be explained in detail below. In contrast, our second example—the work Brutalism (2007) by José Carlos Martinat (b. 1974)—is more complex (fig. 2).

Martinat modelled the installation Brutalism after the Peruvian military and secret service headquarters in Lima, where he was born and studied sound design and interactive software and art. Constructed in 1975, the building—better known as the Pentagonito, or little Pentagon, is a typical example of brutalist post-war architecture. In the 1990s, under the presidency of Alberto Fujimori, the army started to use the building as a base for the torture and interrogation of political prisoners. The work reflects various layers of social, architectural, and political events.

The installation runs on a computer with custom written software, programmed by Arturo Diaz, which queries the Google search engine to search for the words brutalismo, brutalism, and other related terms like violence, dictatorship, or architecture. Sentences extracted from the Google results, varying in theme between dictatorships and architecture, are then printed on one of three thermal printers. The small pieces of paper fall on the floor, thereby creating associations between different kinds of brutalism.

Unlike Becoming, the conservation of this work requires the maintenance of a relationship to the Web, and although the work is programmed in open-source software, it is dependent on the proprietary search engine Google. Because the functioning of the work depends on external data input, Brutalism belongs to our second typology of software-based art, networked.

In the following section, we will focus on the relations between significant properties and dependencies, but first we will briefly describe what we mean by significant properties and dependencies.

SIGNIFICANT PROPERTIES

Within the mainstream archiving community, significant properties are described as: “the characteristics of digital objects that must be preserved over time to ensure the continued accessibility, usability, and meaning of the objects, and their capacity to be accepted as evidence of what they purport to record” (Grace, Knight, and Montague 2009).² This speaks very much to the concerns of the archive and record keeping community regarding access, authenticity, and reliability. Within a fine art context, significant properties are more closely aligned to what has been described by the philosopher Stephen Davies (2001), as “work-determinative” or “work defining properties” as described by Prof. Pip Laurenson (2006).

Significant properties are those conditions that must be honored so that the work is faithfully displayed. These are primarily defined by the artist, through a process conducted in dialogue with the curator and conservator, and often also influenced by art criticism and history.

DEPENDENCIES

We use the word dependency to describe the context under which change in one or more entities has an impact on other entities of the ecosystem of a work. A dependency is a connection, or relation, between different elements in a system; if one of the elements is missing or fails, the system will function differently or stop functioning altogether. Within PERICLES, a dependency is defined in the following way: given resources A and B, A is dependent on B if changes to B have a significant impact on the state of A, or if changes to B can impact the ability to perform function X on A.

When applied specifically to software-based artworks, resources include data, software, and hardware, but also entities that perform activities on the system, both human and non-human. A dependency may also be qualified by one or more intentions (Vion-Dury et al. 2015).³ By attributing intentions to a dependency, we can link the concepts of dependency and significant properties. By doing this, our research extends the understanding of dependency to include aesthetic and conceptual considerations, in addition to functionality. This can be used to model the difference in value of entities connected by a dependency, the key difference being whether that dependency is relevant to materialize one or more of an artwork’s significant properties.

We propose that a significant property informs a judgement regarding the nature of dependency and change so that a dependee can change—without loss of significance—if and only if the significant properties can be maintained. In other words, if a property is not maintained by substitution, a dependee cannot be changed without loss. A resource of an artwork can be changed without loss if it does not have any significant properties associated with it.

An example that reflects the definitions above is the dependency of Brutalism on the use of small printers, the type usually installed in ATM machines (fig. 3).

The printers are visible and placed at the top of the sculptural element. The artwork has a functional dependency on printers, which are required to maintain the significant property of printing the paper slips with sentences. Because the printers are visible on top of the sculptural element, there is also an aesthetic dependency on that type of printer. The artist has stated that he is happy for different printers to be used, but that the new printers should look similar. If similar printers were no longer available, different printers would have to be used, so the functional dependency would be maintained. The aesthetic dependency would not be maintained, and loss would ensue.

To summarize, we wish to imbue our concept of dependency with expressions of value via the concept of significant properties.  Although there are a multitude of dependencies, for now we aim to look at the different types of dependencies of an artwork and to define their parameters.

ARTWORK LEVEL DEPENDENCIES

The different types of software-based art as described before, may exhibit some or all of the following dependencies. Currently we propose four types of dependencies, related to (1) knowledge and information, (2) data, (3) hardware, and (4) software.

These types of dependencies can be further broken down into ones that are more specific. While this may be an artificial divide, for now it helps to distinguish between dependencies and the significant properties attached to them.⁴

1. Knowledge Dependency
   A knowledge dependency implies the requirement of knowledge or information in order for an artwork to be displayed correctly, or to function properly. This knowledge may originate from artwork documentation or implicit knowledge of stakeholders. For example, the installation of the artwork is dependent on certain information or knowledge being available.
   Aesthetic and concept example: For Brutalism Martinat requires that all the cabling used be visible, and that it must look untidy in the room. The default in a gallery display is for cables to be kept hidden or discrete, so this information about the display is essential to maintain the right look of the piece.
2. Data dependency
   A data dependency implies the requirement of data for the realization of an artwork. This data may originate from human input, computer files (e.g. configuration files), a network connection, live video, etc. For example, the function of the artwork is dependent on specific data being available.
   Functional and conceptual example: Brutalism requires live data from Google. If this is not available, the significant property of liveness of search will be affected.
3. Hardware dependency
   A hardware dependency specifies hardware requirements for the software of the artwork or for other resource(s) to function properly. For example, the dependent item is made accessible or realized by the dependee. When the dependee is not available, the dependent item cannot be viewed or experienced as intended.
   Functional example: as mentioned above, Brutalism requires printers to produce paper slips with the sentences resulting of the Google search.
4. Software Dependency
   A software dependency indicates the dependency of a resource on a specific software (name, version, etc.).
   For example, the dependent item is processed by the dependee. When the dependee is not available, the dependent item cannot be processed.
   Functional example: a compatible Java virtual machine is needed to run the Java code used to access Google.

These dependencies will affect the ability for an artwork to be preserved. The ongoing research at Tate has been focused on the possibility of reducing software dependencies by preserving whole software environments, through the creation of disk images and the use of emulation and virtualization, which we now proceed to explain in more detail.

DISK IMAGING, EMULATION AND VIRTUALIZATION

The preservation of software-based artworks such as the ones in our case studies should usually start with the creation of disk images of all the computers’ hard-drives. A disk image is “a digital representation of what would traditionally have been the contents of a physical disk drive. The actual data content of a disk image is identical whether it is stored as a raw disk image file or on a physical drive” (Ensom 2018). Disk images can also be created with an emulation or virtualization platform, installing an operating system and then the artwork software and required libraries.

Disk images have many advantages for preservation, but it is particularly relevant that an exact copy can be created, as a digital file. This allows the content of a hard-drive to be accessed and analyzed without risk of hardware failure or making unwanted changes to the original system. The disk image can also be used to run the original software, in its original environment, in either emulators or virtualization platforms.

In our tests we created disk images using these 2 methods:

• Create a disk image of the original computer’s hard-drive; an exact copy of the system supplied is created, so even elements unknown to be present will be copied.
• Install the artwork’s software on a disk image with a new installation of the operating system required; in this process, missing libraries or driver dependencies will be flagged, but some systems will be very complex and re-installing them can become very time-consuming.

Here we will only discuss running disk images on virtualization software, such as VMWare (http://www.vmware.com/uk) or Virtual Box (https://www.virtualbox.org/).

It is important to understand that having a disk image does not mean that the artwork’s software will be correctly executed. This will depend on the features supported by the emulation/virtualization platforms, for instance, a disk image may contain software that uses the USB standard for communication. If the emulation/virtualization platform supports that, which currently most do, then that function in the artwork software can be maintained.   

Creating and running disk images on an emulation/virtualization platform are processes that can be seen both as a diagnostic tool and a preservation strategy. When used as a diagnostic tool, they help to identify and document technical dependencies, enabling us to learn more about a specific artwork and its technical make. Virtualization is one element in the conservator’s toolbox for software preservation for works produced within the x86 architecture, so roughly, most versions of Windows, Linux, and Mac OSX.

As we will show in the next section, if a disk image is created carefully and thoroughly checked, it can maintain significant properties and support some peripherals. Similar to other software, virtualization has limitations and it will itself eventually become obsolete. The continued ability to boot and run a disk image may require maintenance procedures, namely the need to copy and alter the copied disk image to make it compatible with new emulators or virtualization platforms.

These new platforms must also maintain the support for historical Operating Systems and peripherals may require further intervention.  As with many other areas of conservation, the mode of operating is one of ongoing maintenance rather than a single treatment. Hence, disk imaging can be seen as a stabilization process, while virtualization might be regarded as a playback process for a whole operating system.

When running a disk image on a virtualization platform, it is essential to compare the system supplied by the artist—or that it is confirmed to run to the artist’s specification—and its virtualized version. Virtualization may introduce significant change to an artwork, and currently the best way to verify this is by comparison of the behaviors of the software. Both virtualization and the comparison are only helpful within an existing workflow, which we will outline in more detail below.

VIRTUALIZING SIGNIFICANT PROPERTIES AND DEPENDENCIES IN SOFTWARE-BASED ARTWORKS, TWO EXAMPLES

Because each significant property may require multiple dependencies, for the purpose of this article, we have limited the number of dependency examples per significant property to a key dependency.

EXAMPLE 1: BECOMING, MICHAEL CRAIG-MARTIN

As mentioned, Michael Craig-Martin’s Becomingcan be classified as contained. It consists of an executable file running on Windows XP. The computer used to run the work is built-in at the back of the display screen and there are no other sources or inputs. Since 2003 the gallery has been engaged in an ongoing dialogue with the artist and the programmer to understand the work and its significant properties. This history includes three specifically intense points of engagement linked to the acquisition of the work, the development of conservation strategies, and the display of the work as part of the re-hang in Tate Britain in 2013/14. For this particular work, we distinguished the following dependencies and significant properties:

Significant Properties

Data related:

This work does not have Significant Properties specifically related to data.

Hardware related:

• The LCD monitor has a simple black frame, which has been professionally spray painted to render it anonymous in appearance.
• The aspect ratio of the screen is fixed within parameters (either 18 or 21 inch, 3:4 ratio).
• Computer is built inside the frame and is invisible from the outside.

Key dependency: A monitor must exist to display the images produced by the software.

Software related:

• The complete composition of the images was defined by the artist, and any changes would have to be approved by him.
• The variations in the different elements of the composition must be random, and the timing (rhythm and speed) between the changing images and the degrees of transparency (fadings) are also significant.
• The colors of the drawings and their quality need to remain the same.

Key dependency: All the significant properties above rely, among other elements, on the Becoming software running correctly.

Knowledge related:

• The display specifications of this work state that the presentation of the artwork should resemble the way in which paintings are exhibited in gallery spaces.

Key dependency: A display specification must be kept on record with this information.

In this example a range of significant properties that can be maintained by virtualization are identified. This is only ensured by comparison between the physical and virtual systems. Further to that, settings in the virtual machine—for instance the number of cores in a CPU—can be altered to test the software being run. We could test this for Becoming, in that we were aware of a dependency between processing speed and the speed at which the images would fade in and out, which we explain in more detail below. By changing the settings in the virtual machine, we were able to view this.

Clearly, virtualization does not maintain knowledge-dependent significant properties. Virtualization will also not help maintain significant properties related to the specific aesthetic qualities of the screen and the dependency between the screen and the computer. Nevertheless, it frees the work from the dependency on computer hardware, as, in this case, the specific nature of this hardware is not significant and the functions can be maintained via virtualization.

It needs to be noted that maintenance of the hardware dependencies does not always ensure that the significant properties related to behavior are preserved. For example, any behavior related to the processing speed would need to be monitored and possibly adjusted on the virtual machine. In a previous migration test of the work’s software, it became clear that the behavior of the work can be severely affected. As recounted by Laurenson in an experiment of re-coding the work carried out by Jackson, the way Lingo managed the sequence of steps over time was different from how it functioned in the new software ActionScript 3. As concluded by Laurenson, “the re-coding of the piece not as a recovery tool, but as a diagnostic tool was valuable in producing a better understanding of its vulnerabilities and dependencies over time” (2014, 81). Whereas the work is not necessarily dependent on the specific software, it needs to be well tested beforehand and compared to the original parameters before changes can be made. Defining how that comparison can be made in a meaningful way becomes an essential process, and in cases may require developing other tools to measure specific behaviors of a software.

EXAMPLE 2. BRUTALISM, JOSE CARLOS MARTINAT MENDOZA

Brutalism presents an interesting overlap between dependencies and significant properties. For Martinat, it is important that the work always has a live connection and is connected to a search engine. While he originally used the Google search engine, this entity may be replaced with another search engine in the future as long as it presents similar results. This is an example of a technical dependency that maintains a significant property, therefore having both a functional and a conceptual intention. Martinat explained in an interview with conservator Patricia Falcão in 2010 that he sees the liveness of the search not merely as a tool, but its changing results represent for him the possibility to create a research organism that searches and selects from a sea of information, which has increasingly become difficult to absorb. Similarly, whereas the work depends on the Java environment and programming, which essentially could easily be changed or adapted since this is an open source program, in the same interview Martinat said that through discussions with the programmer, the significance of the software surfaced. Although it could be made in a simpler way, they value the process of creating the software (the extent of changes was not further discussed). We selected the following dependencies and significant properties for Brutalism as examples:

Significant Properties

Data Related:

• The search terms used by the software are used to create a wider variety of search results.

Key dependency: the terms exist in a text document, from which they are randomly drawn by the software.

Hardware related:

• Thermal printers that are able to print small paper; these need to fit into the total design of the sculpture. Current printers sit on top of the model, but when the look of any new ones changes dramatically this may have to be revisited.

Key dependency: there is a hardware dependency in that printers are required to produce the prints.

Software related:

• Liveness of search is important
• The software is a custom written algorithm that searches for certain keywords on Google and prints the results.

Key dependency: connection to a live search engine.

Key dependency: software must run, and it requires an Ubuntu OS to do so, among many other dependencies.

Knowledge related:

• The work must not look “clean.” The cables are visible connecting the printers to the computer, the computer should be visible in the exhibition space and the sculpture surface is not finished in any way.

Key dependency: a display specification must be kept on record with this information.

As with Becoming, a range of technical dependencies that can be maintained by virtualization were identified. Similarly to Becoming, virtualization will not help to maintain the significant properties related to the specific aesthetic qualities of the printers. However, as for Becoming, it will free the work from the dependency on the computer hardware, as in this case the specific nature of this hardware is not significant.

Another challenge is the work’s dependency to Google and the significant property of the live search results (fig. 4). As mentioned, the liveness of the search is important, and Martinat preferred to have recent results. In addition, the majority of visitors must be able to read and understand the printed results.

As acknowledged by the artists, Google may not be used indefinitely, and in conversations, it was mentioned that the MySQL database, which documents all the results, may be used instead. This change would result in the loss of the significant property of liveness and therefore, in conservation terms, as a loss to the artwork. Whereas virtualization will not address the dependency on the Google API, it will maintain the possibility to retrieve earlier saved results from the database. Moreover, it allows the Java search software to be maintained, and its behavior can then be compared with a new version using a different search engine.

Despite the networked dependencies, virtualization is still a valuable tool for Brutalism. It encapsulates a copy of the complete system on the computer, which includes the artwork’s software, including the MySQL database where the search results are stored, and the programming tools used by the artist’s programmer.  This will allow the retrieval of past entries from the saved database, re-use or performance of past experiences, as well as the possibility of recreating the work in the future when necessary. Software can be copied and stored easily (and cheaply). Strategies that allow for the maintenance of the correct software environment are consequently being investigated in the context of the conservation workflow at Tate.

In 2019, as we review this paper for publication, disk imaging has been identified as the first step to preserve whole software systems, both the operating system and any other installed software, and allow their preservation as a file.

The key advantages can be summarized as:

• Creates an exact copy of the physical drive as a contained file.
• Mitigates the risks of a computer and hard-drive hardware failure.
• Can be copied itself to allow analysis and adaptation without risk to the hardware version or a Master version of the disk image, that can be kept as an unchanged drive.

With our first two case-studies, we found that virtualization of software-based artworks can have several advantages and limitations that we can summarize as follows:

Limitations:

• Virtualization tools are dependent on a specific architecture, currently x86, and will only support OSs that use the same architecture.
• A comparison between original and virtualized system is essential to ensure that significant properties are captured accurately.
• Virtualization platforms and formats will become obsolete.

Advantages:

• Can maintain significant properties and peripheral support.
• Can be used for testing dependencies on specific elements or characteristics, e.g. processing speed.
• Can be used for comparisons between versions.
• Virtualization is one tool that can be used within a conservation strategy and maintenance plan for works created within an x86 architecture.

In the next section we will describe how virtualization fits within and adds to a conservation workflow.

INTEGRATING DISK IMAGING AND VIRTUALIZATION INTO A CONSERVATION WORKFLOW

Over the past twelve years, Tate has developed a workflow for software-based artworks that includes the following:

• Working closely with the artist and the programmer to understand the significant properties of the work and documenting this.
• Creating the technical documentation of the systems.
• Creating a copy of the hardware/software system for exhibition.
• Creating a disk image of the original hard-drive.
• Storing the hardware in controlled conditions.
• Maintaining the hardware elements.

Tate’s workflow for the preservation of software-based artworks is based on and is similar to the one used for other time-based media artworks. These processes help to identify the significant properties and dependencies for each work. Disk Imaging is currently being added to this workflow to address the dependency of an artwork’s software on specific hardware and to enable the work to be portable and stored within our High Value Digital Asset repository. Having a virtual version that has been confirmed to run correctly on a well-described platform may also enable comparison between later versions, in the absence of the original, to check that significant properties are maintained even when change is required.

CONCLUSION

For the preservation of an artwork, we must learn about the artwork’s production and technology, define what is important to preserve, and ensure that the work can continue to be displayed in an acceptable form. We do this by working closely with the artist and programmer to understand the significant properties and dependencies of an artwork, creating a technical documentation of the systems, storing and maintaining the hardware elements, and creating a copy of the hardware/software system for exhibition. With disk imaging we address the dependency of an artwork’s software on specific hardware and enable the work to be contained within a file and therefore be portable.

In this paper, we have explored the relationship between dependencies and significant properties within the conservation of software-based art. Looking at dependencies through significant properties helped to decide where the risks are and what can be changed. Using disk imaging as a tool helped to mitigate some of these risks and virtualization, or possibly emulation, can be seen as a way to playback these images in new hardware systems.

ACKNOWLEDGMENTS

This paper is part of ongoing research in which strategies that allow for the maintenance of the correct software environment are consequently investigated in the context of the conservation workflow at Tate. We would very much like to acknowledge the contributions of Michael Craig-Martin, Daniel Jackson, Jose Carlos Martinat, and Arturo Diaz, who, over the years, were always happy to collaborate with us and were extremely generous with their time and knowledge. And finally, we want to recognize the contributions for this ongoing discussion from the teams in Time-based Media Conservation and IS Department at Tate and the PERICLES project partners, namely Efstratios Kontopoulos, Marina Riga, Panos Mitzias from CERTH and Jean-Yves Durion from Xerox. 

This paper was updated in 2019, ahead of its online publication.

ENDNOTES

1. Within PERICLES, we are working and exchanging information with system engineers, mathematicians, and information technologists. This multidisciplinary team provides many interesting discussions about vocabularies, semantics, and ontologies, some of which are reflected in this paper. The common ground is that we are all interested in modelling systems, and one of the aims of this project is to develop a framework that will predict the impact of change within a repository or other digital system. 

2. The work done around dependencies and intentions was in close collaboration with the team at CERTH. For details on the use of terms, please see Vion-Dury et al (2015).

3. This description is adapted from the definition by InSPECT (Investigating Significant Properties of Electronic Content). Started in 2007, the project focused on digital files in an archive context and was conducted by King’s College London and The National Archives. See http://www.significantproperties.org.uk/.

4. This differentiation is work in progress. The current specification is based on the feedback we received from colleagues at AIC 2015 and the work we are undertaking with our project partners in PERICLES, in particular the team at CERTH (Panagiotis Mitzias, Marina Riga, Stratos Kontopoulos).

REFERENCES

Davies, S. 2001. Musical Works and Performances: A Philosophical Exploration. Oxford: Clarendon Press.

Dekker, A. 2016. Tracing Authenticity in the Computational Age. In Authenticity in Transition, eds. E. Hermens and F. Robertson. London: Archetype Publications.

Depocas, A., J. Ippolito, and C. Jones, eds. 2003. Permanence Through Change: The Variable Media Approach. New York, NY: The Solomon R. Guggenheim Foundation and Montreal: Daniel Langlois Foundation for Art, Science, and Technology.

Ensom, T. 2018. Technical Narratives: Analysis, Description and Representation in the Conservation of Software-Based Art. PhD thesis, King’s College London.

Grace, S., G. Knight, and L. Montague. 2009. “InSPECT Final Report” Significant Properties. London: Kings College.

Graham, B. and S. Cook. 2010. Rethinking Curating. Art after New Media. Cambridge, MA: MIT Press.

Gruber, T. R. A Translation Approach to Portable Ontologies. Knowledge Acquisition. 5(2):199–220.

Laurenson, P. 2014. Old Media, New Media? Significant Difference and the Conservation of Software-Based Art. In New Collecting: Exhibiting and Audiences after New Media Art, ed. B. Graham. Surrey: Ashgate Publishing Ltd. 73-96.

Laurenson, P. 2006. Authenticity, change and loss in the conservation of time-based media installations. Tate Papers. Issue 6.

www.tate.org.uk/research/publications/tate-papers/no-6/authenticity-change-and-loss-conservation-of-time-based-media-installations (accessed 09/09/15).

Portnoy, M. 2012. Virtualization Essentials. Indianapolis: John Wiley and Sons, Inc.

Vion-Dury, J.Y., N. Lagos, E. Kontopoulos, M. Riga, P. Mitzias, G. Meditskos, S. Waddington, P. Laurenson, and Y. Kompatsiaris. 2015. Designing for Inconsistency – The Dependency-based PERICLES Approach. Paper presented at SW4CH, Poitiers, France.

Dr. Annet Dekker
Researcher Digital Preservation, Tate
London, United Kingdom
annet.dekker@tate.org.uk

Patricia Falcao
Time-based Media Conservator, Tate
London, United Kingdom
patricia.falcao@tate.org.uk

Dr. Pip Laurenson
Head of Collection Care Research, Tate
London, United Kingdom
pip.laurenson@tate.org.uk