{"id":827,"date":"2019-04-05T16:39:16","date_gmt":"2019-04-05T20:39:16","guid":{"rendered":"http:\/\/resources.culturalheritage.org\/emg-review\/?page_id=827"},"modified":"2019-04-14T17:26:50","modified_gmt":"2019-04-14T21:26:50","slug":"engel-hellar","status":"publish","type":"page","link":"https:\/\/resources.culturalheritage.org\/emg-review\/volume-4-2015-2016\/engel-hellar\/","title":{"rendered":"Computational Provenance and Computational Reproducibility: What Can We Learn about the Conservation of Software Art from Current Research in the Sciences?"},"content":{"rendered":"\n

Mark Hellar and Deena Engel
The Electronic Media Review, Volume Four: 2015-2016<\/em><\/p>\n\n\n\n

ABSTRACT<\/h2>\n\n\n\n

The field of\nart conservation has relied on advances in scientific research throughout\nhistory, whether from studying contemporary approaches to chemical analysis of\nmaterials to taking advantage of new imaging techniques or many other examples.\nOur field is the study of the conservation of time-based media and software\nart. To this end, we have focused on the theoretical framework and practical\napplication of two fields of study in applied mathematics and the sciences\nknown as computational provenance<\/em> and computational reproducibility. <\/em>Our\ngoal is to ascertain whether and how these approaches could inform our work on\nthe conservation of time-based media and software art.<\/p>\n\n\n\n

We will begin\nwith an overview of the techniques used in the sciences to ensure that results\nare reproducible. It is a basic premise of the sciences that experimental\nresults must be consistent in order to be validated; however as current\nscientific research relies heavily on computational techniques, the software\nand technologies used to obtain current scientific results must be preserved so\nthat those same scientific results will be achieved in the distant future. This\nis analogous to the goal of art conservation as museums will wish to re-exhibit\ncontemporary works of time-based media and software art over time.<\/p>\n\n\n\n

Through this model we will consider how the artist\u2019s intention can be preserved and authentically represented throughout an artwork\u2019s lifespan and exhibition history. We will look at the depth of what should be considered to accurately execute or replay data such as digital media or execution of software code by understanding the metadata of its computing environment, such as codecs, compilers, the operating system, and hardware. In addition, we will look at how this model can apply to documentation of physical and environmental factors (such as installation details, sculptural details, lighting, etc.). <\/p>\n\n\n\n

INTRODUCTION<\/h2>\n\n\n\n

The field of\nart conservation has relied on advances in scientific research throughout\nhistory. For example, conservation scientists use contemporary approaches to\nchemical analysis of materials in order to study pigments and grounds, e.g. the\nCourtauld Institute\u2019s work on C\u00e9zanne\u2019s watercolors in 2004-2008 (Buck 2008).\nConservation scientists have a long history of using imaging techniques; for\nexample, early x-ray techniques were used to study Rembrandt\u2019s paintings in\n1916 at the Kunsthistorisches Museum in Vienna (Von Sonnenberg 1995), while the\nuse of x-rays and ultra-violet lights were used at the Museum of Modern Art in\nNew York City to study and conserve Jackson Pollock\u2019s (1912-1956) One:\nNumber 31<\/em> (1950) in 2013 (Vogel), to cite two of many examples.<\/p>\n\n\n\n

Our study focuses on the theoretical framework to assess the possible practical application of two current fields of study in applied mathematics and the sciences: the study of computational provenance<\/em> and the field of computational reproducibility<\/em>. The goal of our research is to ascertain how and whether these approaches could inform our work on the conservation of time-based media and software art.<\/p>\n\n\n\n

CONCEPTUAL\nFRAMEWORK<\/h2>\n\n\n\n

A basic premise\nin the natural sciences is that experimental results must be consistent in\norder to be validated. Science students learn early on that they must document\ntheir materials and techniques (often referred to as a \u201clab notebook\u201d) so that\nanother scientist can use the same materials and the same techniques to come up\nwith the same result. This is a guiding principle in scientific research.<\/p>\n\n\n\n

However,\ncurrent scientific research often relies heavily on computational methods and\ncomputational processes to obtain results. Therefore, it is crucial to the\ncredibility of the results that all of the technologies that are used in the\ncomputational processes to produce the results (including all of the hardware\nand software) must be documented and preserved in some way so that those same\nscientific results will be achieved in the distant future. <\/p>\n\n\n\n

We posed two questions in our research as follows: first, is this work in the natural sciences and applied mathematics analogous and therefore relevant to our research on the conservation of time-based media and software art? Second, if so, can we learn from this approach in order to assist museums and galleries who will wish to re-exhibit works of time-based media and software art in the future? Are there specific practical guidelines, methodologies, and approaches that we can learn from contemporary scientists that would facilitate art conservation practices?<\/p>\n\n\n\n

COMPUTATIONAL\nPROVENANCE<\/h2>\n\n\n\n

The term computational provenance comes from\nthe art world (Dawson 2012). This term refers to documenting all of the steps\nin a science experiment, including not only the techniques, but also the\nmaterials used and all of the relevant data required for a future scientist to\nreproduce the experiment and obtain the same result. Whereas provenance in the\nart world refers to a documented history of the ownership and\/or location of a\nwork of art, scientists use the term provenance in this context to refer to all\nof the steps in their work. Scientists typically document the design of an\nexperiment, how the experiment was performed, how the raw data were acquired,\nand all of the steps in the ensuing computation, data manipulation, and data\npresentation. <\/p>\n\n\n\n

Art conservators are typically trained to document all of the steps that they undertake as they assess, repair, and prepare works of art for conservation and re-exhibition. In this sense, the practice of art conservation is in keeping with the principles of computational provenance.<\/p>\n\n\n\n

COMPUTATIONAL\nREPRODUCABILITY<\/h2>\n\n\n\n

Reproducibility is a term in the sciences used to capture the concept that an experiment can be repeated with the same results. Computational reproducibility specifically addresses scientific research that relies on computer hardware and software applications to support the results. All computer simulations, calculations, data processing, data analysis, and related tasks must be documented so that they can be reproduced in the future. <\/p>\n\n\n\n

Differences Between Computational Reproducibility\nand the Conservation of Time-based Media and Software Art<\/em><\/p>\n\n\n\n

We found several general\nareas of difference in scientific practice and art conservation activities:  areas of concern, goals of research, and\npractical differences in workflow.<\/p>\n\n\n\n

With respect to scientific\npractice, scientists have three general areas of concern to their research that\ndo not apply to the conservation of time-based media and software art. First, floating\npoint arithmetic is of great importance to scientists, but the level of\nprecision that scientists need is not typically relevant in the creation of\nsoftware art. Second, while there are some works of art that rely on data and\ndata sources, art conservators do not have the storage and processing concerns\nto address that would merit the time and attention that scientists need to\ndevote to research that involves big data<\/em>.\nThird, works of art are relatively small applications and do not require parallelization\nor other powerful processing techniques that are important in the sciences. <\/p>\n\n\n\n

On the other hand, art\nconservators have a number of concerns with respect to the conservation of\ntime-based media and software art that are not typically relevant to\nscientists. Art conservators are necessarily concerned with aesthetic factors\nsuch as fidelity to color and color spaces implementation, visual design, the\nspeed of any animation, the resolution needed to properly display the works,\nand other aesthetic factors that are crucial to current and future viewers for\na given work of art. In essence, scientists seek to reproduce calculated\nresults (\u201cto get the same answer\u201d), while art conservators seek to reproduce\nthe viewer\u2019s experience. These different goals inform different working\npractices.<\/p>\n\n\n\n

From a practical perspective, the workflows differ as well. Research scientists are generally expected to manage concerns about reproducibility before publication. Artists however often turn their works over to museums and galleries without specific conservation goals or plans in mind and it is the responsibility of the museums, galleries, and archival institutions to conserve these works of art. It is possible that as museums and galleries ask that artists turn over their source code and document their works of software art, that this practice will change in the near future.<\/p>\n\n\n\n

Similarities\nBetween Computational Reproducibility and the Conservation of Time-based Media\nand Software Art<\/em><\/p>\n\n\n\n

We found three general areas\nthat are described in the literature on computational reproducibility that do\napply to the conservation of time-based media and software art and are\ncurrently in use in some museums. We believe that formally and consistently\naddressing these three areas will greatly benefit art conservators as they\nstrive to conserve and re-exhibit time-based media and works of software art. <\/p>\n\n\n\n

The first and most\nimportant common practice in these two fields is the importance of obtaining\nand preserving source code. There is a growing pressure on scientists to submit\nall of their source code along with the raw data for every publication that\nrelies on computation for results. This is analogous to galleries and museums setting\nup standards and protocols to require that artists provide source code along\nwith the work of software art at the time of acquisition.<\/p>\n\n\n\n

Along with source code,\nscientists are now typically asked to document the computation environment,\nincluding factors such as the operating system and version, hardware setup\n(RAM, processor, etc.), and the programming languages used. Scientists are also\nasked to document any software dependencies (such as external libraries) that\nare required to maintain and run the source code. Software documentation is a\nstandard software engineering practice and an important component of software\nmaintenance in general. Some museums have undertaken software documentation as\npart of their conservation practice (Wharton and Engel 2014).<\/p>\n\n\n\n

Scientists are also required to provide raw data with their results. We believe that artists should also provide all relevant media files (images, sound files, etc.) for their works at the time of acquisition in uncompressed formats. Artists who create works of database art should also provide museums with stand-alone copies of all of the relevant data along with the hardware and software tools to continue retrieving data, if that is relevant to the work of art.<\/p>\n\n\n\n

WHAT ART CONSERVATORS CAN\nLEARN FROM COMPUTATIONAL REPRODUCIBILITY<\/h2>\n\n\n\n

In our research, we came\nacross two additional areas of practice in software engineering that have had very\npositive outcomes with respect to computational reproducibility and we believe\nshould inform standard conservation practices for works of software art going\nforward. These two practices are as follows:<\/p>\n\n\n\n

  1. Implementing version control<\/li>
  2. Differentiating between code and a system\nconfiguration and parameters<\/li><\/ol>\n\n\n\n

    We then shifted our\nresearch to focus our case studies on these two areas, which we believe can further\nstrengthen art conservation efforts for software art.<\/p>\n\n\n\n

    Software\nVersion Control<\/em><\/p>\n\n\n\n

    Software version control is\na system of managing and tracking changes to a collection of information, such\nas the source code of a computer program. Many of us have developed our own\nbasic systems of version control, such as saving multiple copies of a document\nwe were working on, perhaps with a date stamp or revision number in the\nfilename. It\u2019s a familiar approach; however, for a complex collection of computer\nsource code, such a system has the potential to be error prone. Software\ndevelopers realized the need for more structured systems based on this same\nprincipal, to keep track of how a document has changed over time and who made\nthe changes.<\/p>\n\n\n\n

    One of the earliest systems of software-based version control was called the Source Code Control System (SCCS) and was developed at Bell Labs in 1972 by Marc Rochkind. SCCS allowed one individual at a time to modify a source code file and would record those changes to a special history file.  The history contained a cumulative record of which files were changed along with a user id and timestamp. SCCS had a number of commands that would allow one to compare differences across files, revert to older versions, and make a branch or derivative version of the source code, among many others. SCCS was the dominant version control software for many years and was eventually superseded by the Revision Control System (RCS) that was initially released in 1982 by Walter F. Tichy at Purdue University. RCS introduced a more space efficient way of tracking changes; this was important at the time, as hard drive space was a precious resource. <\/p>\n\n\n\n

    Version\ncontrol systems have continued to evolve in their efficiency and add complex\nfeature sets through today. The current dominant system is called Git, which\nwas developed by Linus Toravalds, the inventor of the Linux operating system in\n2005. <\/p>\n\n\n\n

    All\nof the version control systems share some common core concepts:<\/p>\n\n\n\n

    – A\nrepository <\/em>is a database of changes\nto the code, documents, or information for the project. It contains all edits\nand historical versions of the files.<\/p>\n\n\n\n

    -A working\ncopy <\/em>is a local copy of all the files in the project. These are the files\none would make changes to. The set of files is also sometimes referred to as a checkout\n<\/em>as one would check it out from the repository. Once a change has been made\nto the working copy, it is checked in or committed<\/em> to back to the\nrepository with information about the author, a comment on what was added or\nchanged, a record of what changes were made, and a timestamp.<\/p>\n\n\n\n

    -A branch\n<\/em>is a set of files that are forked or split off into a new copy of the code.\nThis code could be manipulated in different ways or at a different pace from\nthe code it was branched from independently. It is possible to merge a branch\nback into the version it was derived from.<\/p>\n\n\n\n

    As\nversion control was developed to manage increasingly complex software projects,\nit offers a great deal of advantages to those who are conserving software-based\nworks of art, if one has acquired the source code along with the artwork. Some\nof these advantages are:<\/p>\n\n\n\n

    -Version control offers the ability to store the history of changes to the artwork. If the creator of a program used version control earlier on, the conservator would have a granular set of records about its creation. For example, the media art programming language Processing <\/em>(https:\/\/processing.org\/<\/a>) has used version control since its inception and has tracked every modification, addition, and deletion over 14 years (see fig. 1).<\/p>\n\n\n\n

    \"Fig.
    Fig. 1 The Processing version control repository has tracked every change to the project from its beginnings in 2001 up through today. There are 10,848 check-ins or commits<\/em>. (Source: <\/em>https:\/\/github.com\/processing\/processing<\/em><\/a> )<\/em><\/figcaption><\/figure>\n\n\n\n

    -Version control offers the ability to make further changes to the code for its continued operation, without altering the original. Software and hardware environments change, languages evolve, and this increases the possibility of have to migrate source code in order to keep it running. Options such as creating a branch <\/em>offer the possibility of creating a research copy to test migration strategies without affecting the original acquired code. Also, a documentation branch could be created in order to add comments to the code so that it could be understood in the future.<\/p>\n\n\n\n

    Separating System Configuration and Parameters from\nSource Code<\/em><\/p>\n\n\n\n

    A number of software\nprograms, operating systems and programming languages offer the ability to\nconfigure initial settings about their operation. This is typically done\noutside of the executable software in the form of a configuration file.\nConfiguration files are typically written in ASCII plain text and contain a\nnumber of parameters that inform their accompanying software how to run. The\nparameters can cover a wide range of options depending on how the software was\nauthored. For example, a configuration file parameter may define how much\nsystem memory the program is allowed to use, the color depth and screen\nresolution it should run at, etc. The possibility for parameters is limitless\nand unique to each piece of software. Programs typically read the configuration\nfile on startup, and some may periodically check for changes as they execute.<\/p>\n\n\n\n

    The following is a snippet of the main configuration file for DOSbox (http:\/\/www.dosbox.com\/<\/a>), a Microsoft Disk Operating System (DOS) emulator. This section specifies what language the emulator should run in, the amount of memory it should use, type of machine it should emulate, and how the text should be encoded:   <\/p>\n\n\n\n

    # language — Select another language file.
    # memsize — Amount of memory dosbox has in megabytes.
    # machine — The type of machine tries to emulate:hercules,cga,tandy,pcjr,vga.
    # codepage — Specify a code page number.
    language=EN
    machine=vga
    codepage=437
    memsize=16<\/p>\n\n\n\n

    One advantage to separating out the parameters from the main program is that it gives flexibility in altering how a program runs without having to recompile the source code. Additionally, parameterization of system operating variables could offer a level of portability if a program needed to move to new hardware.<\/p>\n\n\n\n

    CONCLUSIONS<\/h2>\n\n\n\n

    In conclusion, we recommend\nfurther periodic research (perhaps every year or more) so that conservators of\nsoftware art and time-based media might continue to learn from the model of\ncomputational reproducibility in the sciences. We would like to add the\nfollowing recommendations, so that museums would implement and\/or continue to\nimplement the following practices:<\/p>\n\n\n\n