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.<\/p>\n\n\n\n
SOFTWARE-BASED ARTWORKS<\/h2>\n\n\n\n
When we use the term software-based artwork, we mean that\nsoftware is its primary artistic medium. These works form complex systems of\nhardware, commercial and custom software, and various interfaces such as screens.\nThese systems also exhibit a range of functions and behaviors, including\nresponse to activities or engagement of visitors. To distinguish between\nvarious types of software-based artworks, we defined the following typology:<\/p>\n\n\n\n
Types of software-based artworks:<\/p>\n\n\n\n
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.) <\/p>\n\n\n\n
This typology builds on the thinking of the Variable Media Network (Depocas 2003) and Graham and Cook (2010), who both strategically describe media art\u2014a larger umbrella of artworks including software-based art\u2014as behavioral instead of using merely object dependent terminology, which would reveal little about the functioning of an artwork. Shifting the focus to a work\u2019s 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).<\/p>\n\n\n\n
For the purpose of this article, we focus on two artworks from Tate\u2019s collection that deal with increasing challenges of software obsolescence and represent two different types of software-based art. The first is Michael Craig-Martin\u2019s (b. 1941) work Becoming<\/em> which we classified as a type A, a contained<\/em> software-based artwork (fig. 1).<\/p>\n\n\n\n In 2003, Tate acquired their first software-based artwork, Becoming<\/em>\n(2003) by Michael Craig-Martin. As a conceptual artist and painter,\nCraig-Martin is best known for his drawings of ordinary, mass produced\nfunctional objects that he altered or assembled in specific ways to draw\nattention to relationships between form and purpose. Becoming<\/em> follows\nCraig-Martin\u2019s practice of exploring the notion of emergence to visibility and\nidentification, and the concepts of representation and recognition.<\/p>\n\n\n\n The work is a computer-generated animation displayed on a\nwall-mounted, customized LCD screen. A series of Craig-Martin\u2019s elementary line\ndrawings, vividly colored, fade in and out of visibility against a fuchsia pink\nbackground. The eighteen objects (a chair, a pair of pliers, a tape cassette, a\nfan, a pitchfork, a sandal, a light bulb, a drawer, a metronome, a book, a\nbucket, a TV, a flashlight, a safety-pin, a knife, a pair of handcuffs, and a\nmedicine jar spilling pills) overlap and appear and disappear at random. The\nresult is a constantly changing composition.<\/p>\n\n\n\n Daniel Jackson, of AVCO, wrote the script to create the\nintervals and the varying degrees of transparency of the images in the\nprogramming language Lingo, using Macromedia Director. <\/em>As part of an\nexhibition, Becoming<\/em> is presented as a \u2018painting\u2019 that can be hung\namidst other artworks. The work does not require interaction from visitors and\nis built with customized proprietary software and hardware. As such, it belongs\nto the first type of software-based artworks: contained<\/em>, using\nproprietary software, but without any external influence on the software.<\/p>\n\n\n\n Despite being technically straightforward, Becoming<\/em> is vulnerable to change. In previous maintenance to the work\u2019s software, it became clear that an important aspect of the behavior of the work\u2014in this case, the speed of the changing composition\u2014can be severely affected by changes to elements of the work\u2019s environment; this will be explained in detail below. In contrast, our second example\u2014the work Brutalism<\/em> (2007) by Jos\u00e9 Carlos Martinat (b. 1974)\u2014is more complex (fig. 2).<\/p>\n\n\n\n Martinat modelled the installation Brutalism<\/em> after the\nPeruvian military and secret service headquarters in Lima, where he was born\nand studied sound design and interactive software and art. Constructed in 1975,\nthe building\u2014better known as the Pentagonito, or little Pentagon, is a typical\nexample of brutalist post-war architecture. In the 1990s, under the presidency\nof Alberto Fujimori, the army started to use the building as a base for the\ntorture and interrogation of political prisoners. The work reflects various layers\nof social, architectural, and political events.<\/p>\n\n\n\n The installation runs on a computer with custom written\nsoftware, programmed by Arturo Diaz, which queries the Google search engine to\nsearch for the words brutalismo<\/em>, brutalism<\/em>, and other related terms\nlike violence<\/em>, dictatorship<\/em>, or architecture<\/em>. Sentences\nextracted from the Google results, varying in theme between dictatorships and\narchitecture, are then printed on one of three thermal printers. The small\npieces of paper fall on the floor, thereby creating associations between\ndifferent kinds of brutalism.<\/p>\n\n\n\n Unlike Becoming,<\/em> the conservation of this work requires\nthe maintenance of a relationship to the Web, and although the work is\nprogrammed in open-source software, it is dependent on the proprietary search\nengine Google. Because the functioning of the work depends on external data\ninput, Brutalism<\/em> belongs to our second typology of software-based art, networked<\/em>.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Within the mainstream archiving community, significant\nproperties are described as: \u201cthe characteristics of digital objects that must\nbe preserved over time to ensure the continued accessibility, usability, and\nmeaning of the objects, and their capacity to be accepted as evidence of what\nthey purport to record\u201d (Grace, Knight, and Montague 2009).2<\/sup> This\nspeaks very much to the concerns of the archive and record keeping community\nregarding access, authenticity, and reliability. Within a fine art context,\nsignificant properties are more closely aligned to what has been described by\nthe philosopher Stephen Davies (2001), as \u201cwork-determinative\u201d or \u201cwork\ndefining properties\u201d as described by Prof. Pip Laurenson (2006).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n We use the word dependency to describe the context under which\nchange in one or more entities has an impact on other entities of the ecosystem\nof a work. A dependency is a connection, or relation, between different\nelements in a system; if one of the elements is missing or fails, the system\nwill function differently or stop functioning altogether. Within PERICLES, a\ndependency is defined in the following way: given resources A and B, A is\ndependent on B if changes to B have a significant impact on the state of A, or\nif changes to B can impact the ability to perform function X on A. <\/p>\n\n\n\n When applied specifically to software-based artworks, resources\ninclude data, software, and hardware, but also entities that perform activities\non the system, both human and non-human. A dependency may also be qualified by\none or more intentions (Vion-Dury et al. 2015).3<\/sup> By attributing\nintentions to a dependency, we can link the concepts of dependency and\nsignificant properties. By doing this, our research extends the understanding\nof dependency to include aesthetic and conceptual considerations, in addition\nto functionality. This can be used to model the difference in value of entities\nconnected by a dependency, the key difference being whether that dependency is\nrelevant to materialize one or more of an artwork\u2019s significant properties. <\/p>\n\n\n\n We propose that a significant property informs a judgement regarding\nthe nature of dependency and change so that a dependee can change\u2014without loss\nof significance\u2014if and only if the significant properties can be maintained. In\nother words, if a property is not maintained by substitution, a dependee cannot\nbe changed without loss. A resource of an artwork can be changed without loss\nif it does not have any significant properties associated with it. <\/p>\n\n\n\n An example that reflects the definitions above is the dependency of Brutalism<\/em> on the use of small printers, the type usually installed in ATM machines (fig. 3). <\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n These types of dependencies can be further broken down into ones\nthat are more specific. While this may be an artificial divide, for now it\nhelps to distinguish between dependencies and the significant properties\nattached to them.4<\/sup><\/p>\n\n\n\n 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.<\/p>\n\n\n\n The preservation of software-based artworks such as the ones in\nour case studies should usually start with the creation of disk images of all\nthe computers\u2019 hard-drives. A disk image is \u201ca digital representation of what\nwould traditionally have been the contents of a physical disk drive. The actual\ndata content of a disk image is identical whether it is stored as a raw disk image\nfile or on a physical drive\u201d (Ensom 2018). Disk images can also be created with\nan emulation or virtualization platform, installing an operating system and\nthen the artwork software and required libraries. <\/p>\n\n\n\n Disk images have many advantages for preservation, but it is\nparticularly relevant that an exact copy can be created, as a digital file.\nThis allows the content of a hard-drive to be accessed and analyzed without\nrisk of hardware failure or making unwanted changes to the original system. The\ndisk image can also be used to run the original software, in its original\nenvironment, in either emulators or virtualization platforms.<\/p>\n\n\n\n In our tests we created disk images using these 2 methods: <\/p>\n\n\n\n Here we will only discuss running\ndisk images on virtualization software, such as VMWare (http:\/\/www.vmware.com\/uk<\/a>) or Virtual Box (https:\/\/www.virtualbox.org\/<\/a>). <\/p>\n\n\n\n It is important to understand that having a disk image does not\nmean that the artwork\u2019s software will be correctly\nexecuted. This will depend on the features supported by the emulation\/virtualization\nplatforms, for instance, a disk image may contain software that uses the USB\nstandard for communication. If the emulation\/virtualization platform supports\nthat, which currently most do, then that function in the artwork software can\nbe maintained. <\/p>\n\n\n\n Creating and running disk images on an emulation\/virtualization\nplatform are processes that can be seen both as a diagnostic tool and a\npreservation strategy. When used as a diagnostic tool, they help to identify\nand document technical dependencies, enabling us to learn more about a specific\nartwork and its technical make. Virtualization is one element in the\nconservator\u2019s toolbox for software preservation for\nworks produced within the x86 architecture, so roughly, most versions of\nWindows, Linux, and Mac OSX. <\/p>\n\n\n\n As we will show in the next section, if a disk image is created\ncarefully and thoroughly checked, it can maintain significant properties and\nsupport some peripherals. Similar to other software, virtualization has limitations\nand it will itself eventually become obsolete. The continued ability to boot\nand run a disk image may require maintenance procedures, namely the need to\ncopy and alter the copied disk image to make it compatible with new emulators\nor virtualization platforms. <\/p>\n\n\n\n These new platforms must also maintain the support for\nhistorical Operating Systems and peripherals may require further\nintervention. As with many other areas\nof conservation, the mode of operating is one of ongoing maintenance rather\nthan a single treatment. Hence, disk imaging can be seen as a stabilization\nprocess, while virtualization might be regarded as a playback process for a\nwhole operating system. <\/p>\n\n\n\n When running a disk image on a virtualization platform, it is essential to compare the system supplied by the artist\u2014or that it is confirmed to run to the artist\u2019s specification\u2014and 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.<\/p>\n\n\n\n Because each significant property may require multiple\ndependencies, for the purpose of this article, we have limited the number of\ndependency examples per significant property to a key dependency.<\/p>\n\n\n\n EXAMPLE 1: BECOMING, <\/em>MICHAEL\nCRAIG-MARTIN<\/p>\n\n\n\n As mentioned, Michael Craig-Martin\u2019s Becoming<\/em>can be classified as contained. It\nconsists of an executable file running on Windows XP. The computer used to run\nthe work is built-in at the back of the display screen and there are no other\nsources or inputs. Since 2003 the gallery has been engaged in an ongoing\ndialogue with the artist and the programmer to understand the work and its\nsignificant properties. This history includes three specifically intense points\nof engagement linked to the acquisition of the work, the development of\nconservation strategies, and the display of the work as part of the re-hang in\nTate Britain in 2013\/14. For this particular work, we distinguished the\nfollowing dependencies and significant properties:<\/p>\n\n\n\n Significant Properties <\/em><\/p>\n\n\n\n Data related:<\/p>\n\n\n\n This work does not have Significant Properties specifically\nrelated to data.<\/p>\n\n\n\n Hardware related:<\/p>\n\n\n\n Key dependency<\/em>:\nA monitor must exist to display the images produced by the software.<\/p>\n\n\n\n Software related:<\/p>\n\n\n\n Key dependency<\/em>:\nAll the significant properties above rely, among other elements, on the Becoming <\/em>software running correctly.<\/p>\n\n\n\n Knowledge related:<\/p>\n\n\n\n Key dependency<\/em>: A display specification must be kept on record with this information.<\/p>\n\n\n\n In this example a range of significant properties that can be\nmaintained by virtualization are identified. This is only ensured by comparison\nbetween the physical and virtual systems. Further to that, settings in the\nvirtual machine\u2014for instance the number of cores in a\nCPU\u2014can be altered to test the software being run. We\ncould test this for Becoming<\/em>, in that we were\naware of a dependency between processing speed and the speed at which the\nimages would fade in and out, which we explain in more detail below. By\nchanging the settings in the virtual machine, we were able to view this.<\/p>\n\n\n\n Clearly, virtualization does not maintain knowledge-dependent\nsignificant properties. Virtualization will also not help maintain significant\nproperties related to the specific aesthetic qualities of the screen and the\ndependency between the screen and the computer. Nevertheless, it frees the work\nfrom the dependency on computer hardware, as, in this case, the specific nature\nof this hardware is not significant and the functions can be maintained via virtualization.<\/p>\n\n\n\n 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\u2019s 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, \u201cthe 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\u201d (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.<\/p>\n\n\n\n EXAMPLE 2. BRUTALISM, <\/em>JOSE CARLOS MARTINAT MENDOZA<\/p>\n\n\n\n Brutalism <\/em>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\u00e3o 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<\/em> as examples:<\/p>\n\n\n\n Significant Properties<\/em><\/p>\n\n\n\n Data Related:<\/p>\n\n\n\n Key dependency<\/em>:\nthe terms exist in a text document, from which they are randomly drawn by the\nsoftware. <\/p>\n\n\n\n Hardware related:<\/p>\n\n\n\n Key dependency<\/em>:\nthere is a hardware dependency in that printers are required to produce the\nprints.<\/p>\n\n\n\n Software related:<\/p>\n\n\n\n Key dependency<\/em>:\nconnection to a live search engine.<\/p>\n\n\n\n Key dependency<\/em>:\nsoftware must run, and it requires an Ubuntu OS to do so, among many other\ndependencies.<\/p>\n\n\n\n Knowledge related:<\/p>\n\n\n\n Key dependency<\/em>:\na display specification must be kept on record with this information.<\/p>\n\n\n\n As with Becoming,<\/em> a range of\ntechnical dependencies that can be maintained by virtualization were\nidentified. Similarly to Becoming<\/em>,\nvirtualization will not help to maintain the significant properties related to\nthe specific aesthetic qualities of the printers. However, as for Becoming<\/em>, it will free the work from the dependency on\nthe computer hardware, as in this case the specific nature of this hardware is\nnot significant.<\/p>\n\n\n\n Another challenge is the work\u2019s 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Despite the networked dependencies, virtualization is still a\nvaluable tool for Brutalism<\/em>. It encapsulates a\ncopy of the complete system on the computer, which includes the artwork\u2019s software, including the MySQL database where the search\nresults are stored, and the programming tools used by the artist\u2019s programmer. This\nwill allow the retrieval of past entries from the saved database, re-use or\nperformance of past experiences, as well as the possibility of recreating the\nwork in the future when necessary. Software can be copied and stored easily\n(and cheaply). Strategies that allow for the maintenance of the correct\nsoftware environment are consequently being investigated in the context of the\nconservation workflow at Tate.<\/p>\n\n\n\n In 2019, as we review this paper for publication, disk imaging\nhas been identified as the first step to preserve whole software systems, both the\noperating system and any other installed software, and allow their preservation\nas a file.<\/p>\n\n\n\n The key advantages can be summarized as:<\/p>\n\n\n\n With our first two case-studies, we found that virtualization of\nsoftware-based artworks can have several advantages and limitations that we can\nsummarize as follows:<\/p>\n\n\n\n Limitations<\/em>:<\/p>\n\n\n\n Advantages<\/em>:<\/p>\n\n\n\n In the next section we will describe how virtualization fits within and adds to a conservation workflow.<\/p>\n\n\n\n Over the past twelve years, Tate has developed a workflow for\nsoftware-based artworks that includes the following:<\/p>\n\n\n\n Tate\u2019s 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\u2019s 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. <\/p>\n\n\n\n For the preservation of an artwork, we must learn about the\nartwork\u2019s production and technology, define what is\nimportant to preserve, and ensure that the work can continue to be displayed in\nan acceptable form. We do this by working closely with the artist and\nprogrammer to understand the significant properties and dependencies of an\nartwork, creating a technical documentation of the systems, storing and\nmaintaining the hardware elements, and creating a copy of the hardware\/software\nsystem for exhibition. With disk imaging we address the dependency of an\nartwork\u2019s software on specific hardware and enable the\nwork to be contained within a file and therefore be portable.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This paper is part of ongoing research in which strategies that\nallow for the maintenance of the correct software environment are consequently\ninvestigated in the context of the conservation workflow at Tate. We would very\nmuch like to acknowledge the contributions of Michael Craig-Martin, Daniel\nJackson, Jose Carlos Martinat, and Arturo Diaz, who, over the years, were\nalways happy to collaborate with us and were extremely generous with their time\nand knowledge. And finally, we want to recognize the contributions for this\nongoing discussion from the teams in Time-based Media Conservation and IS\nDepartment at Tate and the PERICLES project partners, namely Efstratios\nKontopoulos, Marina Riga, Panos Mitzias from CERTH and Jean-Yves Durion from\nXerox. <\/p>\n\n\n\n This paper was updated in 2019, ahead of its online publication<\/em>.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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).<\/p>\n\n\n\n 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\u2019s College London and The National Archives. See http:\/\/www.significantproperties.org.uk\/.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n Davies, S. 2001.\nMusical Works and Performances: A Philosophical Exploration.<\/em> Oxford:\nClarendon Press.<\/p>\n\n\n\n Dekker, A. 2016.\nTracing Authenticity in the Computational Age. In Authenticity in Transition<\/em>,\neds. E. Hermens and F. Robertson. London: Archetype Publications.<\/p>\n\n\n\n Depocas, A., J.\nIppolito, and C. Jones, eds. 2003. Permanence Through Change: The Variable\nMedia Approach<\/em>. New York, NY: The Solomon R. Guggenheim Foundation and\nMontreal: Daniel Langlois Foundation for Art, Science, and Technology.<\/p>\n\n\n\n Ensom, T. 2018. Technical\nNarratives: Analysis, Description and Representation in the Conservation of\nSoftware-Based Art<\/em>. PhD thesis, King’s College London.<\/p>\n\n\n\n Grace, S., G.\nKnight, and L. Montague. 2009. “InSPECT Final Report”<\/em> Significant\nProperties<\/em>. London: Kings College.<\/p>\n\n\n\n Graham, B. and\nS. Cook. 2010. Rethinking Curating. Art after New Media<\/em>. Cambridge, MA:\nMIT Press.<\/p>\n\n\n\n Gruber, T. R. A\nTranslation Approach to Portable Ontologies. Knowledge Acquisition.<\/em>\n5(2):199\u2013220.<\/p>\n\n\n\n Laurenson, P.\n2014. Old Media, New Media? Significant Difference and the Conservation of\nSoftware-Based Art. In New Collecting: Exhibiting and Audiences after New\nMedia Art<\/em>, ed. B. Graham. Surrey: Ashgate Publishing Ltd. 73-96.<\/p>\n\n\n\n Laurenson, P.\n2006. Authenticity, change and loss in the conservation of time-based media\ninstallations. Tate Papers<\/em>. Issue 6. <\/a><\/p>\n\n\n\n www.tate.org.uk\/research\/publications\/tate-papers\/no-6\/authenticity-change-and-loss-conservation-of-time-based-media-installations<\/a> (accessed 09\/09\/15).<\/p>\n\n\n\n Portnoy,\nM. 2012. Virtualization Essentials.<\/em> Indianapolis: John Wiley and Sons,\nInc.<\/p>\n\n\n\n Vion-Dury, J.Y., N. Lagos, E. Kontopoulos, M. Riga, P.\nMitzias, G. Meditskos, S. Waddington, P. Laurenson, and Y. Kompatsiaris. 2015.\nDesigning for Inconsistency \u2013 The Dependency-based PERICLES Approach. Paper\npresented at SW4CH, Poitiers, France.<\/p>\n\n\n\n Dr. Annet Dekker Patricia Falcao Dr. Pip Laurenson 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 … Continue reading “An Exploration of Significance, Dependency, and Virtualization in the Conservation of Software-based Artworks”<\/span><\/a><\/p>\n","protected":false},"author":46,"featured_media":0,"parent":616,"menu_order":8,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-768","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/pages\/768","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/comments?post=768"}],"version-history":[{"count":0,"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/pages\/768\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/pages\/616"}],"wp:attachment":[{"href":"https:\/\/resources.culturalheritage.org\/emg-review\/wp-json\/wp\/v2\/media?parent=768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Fig](\"http:\/\/resources.culturalheritage.org\/emg-review\/wp-content\/uploads\/sites\/15\/2019\/04\/fig_1_dekkerfalcao_2015l-763x1024.jpg\")
![\"Fig.](\"http:\/\/resources.culturalheritage.org\/emg-review\/wp-content\/uploads\/sites\/15\/2019\/04\/fig_2_dekkerfalcao_2015-856x1024.jpg\")
SIGNIFICANT PROPERTIES<\/h2>\n\n\n\n
DEPENDENCIES<\/h2>\n\n\n\n
![\"Fig.](\"http:\/\/resources.culturalheritage.org\/emg-review\/wp-content\/uploads\/sites\/15\/2019\/04\/fig_3_dekkerfalcao_2015-1024x768.jpg\")
ARTWORK LEVEL DEPENDENCIES<\/h2>\n\n\n\n
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 <\/em>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. <\/li>
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 <\/em>requires live data from Google. If this is not available, the significant property of liveness of search will be affected. <\/li>
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<\/em> requires printers to produce paper slips with the sentences resulting of the Google search. <\/li>
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.<\/li><\/ol>\n\n\n\nDISK IMAGING, EMULATION AND VIRTUALIZATION<\/h2>\n\n\n\n
VIRTUALIZING SIGNIFICANT PROPERTIES AND DEPENDENCIES IN SOFTWARE-BASED ARTWORKS, TWO EXAMPLES<\/h2>\n\n\n\n
![\"Fig.](\"http:\/\/resources.culturalheritage.org\/emg-review\/wp-content\/uploads\/sites\/15\/2019\/04\/fig_4-_dekkerfalcao_2015-1024x768.jpg\")
INTEGRATING DISK IMAGING AND VIRTUALIZATION INTO A CONSERVATION WORKFLOW<\/h2>\n\n\n\n
CONCLUSION<\/h2>\n\n\n\n
ACKNOWLEDGMENTS<\/h2>\n\n\n\n
ENDNOTES<\/h2>\n\n\n\n
REFERENCES<\/h2>\n\n\n\n
Researcher Digital Preservation, Tate
London, United Kingdom
annet.dekker@tate.org.uk <\/p>\n\n\n\n
Time-based Media Conservator, Tate
London, United Kingdom
patricia.falcao@tate.org.uk <\/p>\n\n\n\n
Head of Collection Care Research, Tate
London, United Kingdom
pip.laurenson@tate.org.uk <\/p>\n","protected":false},"excerpt":{"rendered":"