Preserving the Rhizome ArtBase




Richard Rinehart




September 2002






Table of Contents


Preserving the Rhizome ArtBase.................................................................................... 1

Introduction......................................................................................................................... 3

Emulation as a Preservation Strategy............................................................................. 4

Recommendations............................................................................................................ 6

Tools................................................................................................................................. 12

Collection Policy.............................................................................................................. 13

Obtain and Store Copies of Software........................................................................... 13

Storage Migration Strategy............................................................................................ 14

Conclusion on Emulation................................................................................................ 16





 is an online platform for the global new media art community. Its programs and activities support the creation, presentation, discussion and preservation of new media art: a broad and flexible set of creative practices employing or responding to new technologies, including software, databases, network protocols, hardware, robotics, and multimedia tools. These practices take many forms, from web sites to performances and installations. New media art is often interdisciplinary, blurring the boundaries between established disciplines and involving artists and others in collaborative processes. Because new media technologies are themselves changing and converging at a rapid pace, the field is constantly in flux.


The ArtBase is Rhizome's online archive of new media art2. Initially conceived and developed as an archive of net art projects exclusively, the scope of the ArtBase has since been expanded to include other forms of new media art, such as software, games, and web-based documentation of installation and performance works. The ArtBase includes works of historical significance that are submitted by the artists themselves, or by the owners of commissioned artworks, through an online submission process. The term ArtBase here refers to both the tools and system used to document the artworks as well as the artworks themselves.


This paper outlines the key steps Rhizome should consider taking toward preserving the works of art included in the Rhizome ArtBase, and indicates measures Rhizome may take in the near future to test the strategy of emulation in particular. It outlines a general method for preserving new media art. Although it discusses some of Rhizome’s current policies, it also includes steps, which may be impractical for Rhizome to take at this stage. Overall, this paper defines a research agenda for a long-term new media art preservation project to be undertaken by the arts and cultural community in the future, with the ultimate goal of developing solutions for the preservation of new media art. It is thus both a working paper for Rhizome and a map of Rhizome’s contribution to the larger effort to preserve artworks in digital and other variable media.


This effort builds on Rhizome’s existing systems for the submission, storage and display of artworks and their accompanying metadata (descriptive and technical information about the artworks). A key part of this system, the ArtBase Artist Questionnaire, gathers information necessary for guiding future preservation measures, including documentation, migration, emulation and reinterpretation. This questionnaire was developed in conjunction with the Guggenheim Museum’s Variable Media Initiative3. The testbed project proposed in this paper is a further step in the community-wide effort to develop a working strategy for preserving new media art, and dovetails with concurrent initiatives within the community, such as Archiving the Avant-Garde4, one of the first practical test cases preparing to use the strategy of emulation for preservation. Computer emulation has been proposed by Jeff Rothenberg in several papers to the digital libraries community as a strategy for preserving digital documents5, and has also been suggested as a partial preservation strategy for new media art6.


Emulation as a Preservation Strategy


One of the central problems facing preservationists in the future will be how to run old, obsolete software and documents on new systems. As a strategy for addressing this problem, emulation is especially suited to works of digital media art. Hardware emulation involves writing a new piece of software for a future computer that causes that computer to mimic, or emulate, all of the hardware behavior of an earlier computer. For instance, if one wanted to run a piece of software from 1999 (say a work from the ArtBase) on a computer in 2050, then one would write a piece of software called an “emulator” which would cause that 2050-era computer to appear to all software as if it were an computer from 1999. Once this emulation software was in place, one could run the original software from 1999, including the operating system, the application program and all the document files. The original software would run because it interfaces to the computer itself through the emulator which translates all the requests of the original software into contemporary terms for the computer hardware and vice versa. This is not the only way one might preserve a work of new media art (other possible strategies include re-creating the work from scratch in contemporary media based on instructions from the artist, documenting the work with more stable media, and migrating the work to a newer standard or platform), but emulation could comprise one key component in an overall strategy intended to serve multiple goals.


To understand emulation, it is helpful to outline the layers of which current computer systems are comprised. These layers form a ladder climbing from the bottom hardware/machine level to the individual document/file and include:



Application/program software

Operating System (OS)



Rothenberg makes a strong case for emulating only the bottom, hardware, layer, and then running the original OS, application and document within the hardware emulator. He argues that hardware is well documented on a technical level, and that this approach gives us the most leverage for the investment (for the work of writing just a few hardware emulators, we could run dozens of operating systems, thousands of applications, and millions of documents).


This strategy has potential advantages and disadvantages when applied to new media art. For instance, all current forms of emulation focus on the stand-alone computer and not the network per se. Many net artworks integrate the Internet into the work – for instance, calling in live data-streams from servers around the world. Emulation will never be able to emulate the entire Internet environment needed for some artworks, but there may be ways to mitigate this condition. One might be to record the specific types of network functionality the artwork relies on, so that this too may be emulated in the future. For instance, if a current work pings IP addresses on the Internet, but in the future both Ping and IP are obsolete protocols, then an IP-style number generator could take the place of real IP pinging in the future work. It is nonetheless likely that emulation will be able to preserve only some or most of the aspects of a work and that, in many cases, the emulated artwork will serve primarily as a snapshot or fragment to preserve some critical historical evidence in original form. Anyone involved in the preservation of art will recognize that well-preserved fragments can have great historical value.


There are additional challenges to be overcome if emulation is to become a vital strategy for the preservation of new media art . For instance, will emulators be stand-alone applications or network-based application services? Will emulators be entirely server-based, or will they be able to divide functionality between server and client? These challenges are daunting, and raise significant artistic as well as technical issues, but the key fact is that they are surmountable, and the potential for preserving original new media art into the long-term is highly motivating.




Rhizome should take the following preparatory steps in anticipation of the future need for, and availability of, emulation software:


1.      Decide which metadata to capture or create about the original work of new media art and about the original software needed to actualize that work in the future.

2.      Make a tool for collecting and managing this metadata.

3.      Draft internal collection policies, which accommodate and document Rhizome’s archiving practices.

4.      Obtain and store legal copies of software, such as operating systems, browsers and plug-ins, required to run ArtBase artworks.

5.      Develop a strategy for preserving or migrating and storing the original software and original documents of the artwork needed for future emulations.

6.      Participate in collaborations with other institutions involved in the preservation of new media art, especially those projects which may address additional issues not addressed here, such as intellectual property rights around commercial software and developing emulation software.




Metadata is "data about data." The term applies to records in the Rhizome ArtBase, as they contain information about data-based artworks. Rhizome will need to manage two types of metadata in the preservation process (some of this metadata is already captured and managed in the ArtBase). It is standard practice in the cultural heritage community to identify at least three types of metadata: descriptive (information which is used to search for, identify, and explain the artwork being described); administrative (information needed for the internal management of the artwork such as legal, storage, and non-public provenance information); and technical (information about the infrastructure and materials of an artwork necessary for preservation and handling). Rhizome should capture or create these three types of metadata, once for the artwork and again for the technology.


1.      Metadata about the original artwork (artwork metadata). This includes:


A.     Descriptive metadata (creator, date, genre, etc) that is already stored in the ArtBase database and is used for discovery and display.

B.     Administrative metadata (who owns rights to reproduce work, what parameters have the artist and/or current repository imposed for future recreations of the work, what is the general structure of the work, where are the actual files stored, etc).

C.    Technical metadata (what technologies are used to run the work, what is the function of each, etc).


2.  Metadata about the original software/technology needed to run the work (technology metadata). :


A.     Descriptive metadata (creator of software, date and current version, type of software, etc).

B.    Administrative metadata (who owns right to run or modify code, what are the parameters of such rights such as time limitations, platform limitations, limitations on purpose, where actual application files are located, the general structure and what other software is required for running, etc).

C.    Technical metadata (what bottom-level code was used to create software; for example, Flash was written in C++).


It is recommended that these two categories of information—one about the artwork itself, the other about the technology needed to run it—be maintained separately. It should be noted that while emulation requires metadata about original software, emulation is but one strategy that may run concurrently with other strategies such as re-creation, in which case metadata from the artwork becomes “unhitched” from metadata about the original software. It also keeps clear the distinction between the original artwork and the mechanisms used to represent it (such confusion often arises in museum databases with regard to metadata about an original object and metadata about a digital image of that object). The distinctive relationship between content/vehicle and original/derivative is similar in both cases, and may be valuable in the future as different presentation approaches are brought to bear on a single work of art.


It is equally important that the metadata created for this be consistent with other metadata standards in the arts and cultural heritage communities. This is to support the long-term maintenance of ArtBase metadata, to make it possible to integrate this metadata into existing collection management software as a way of ensuring that it can be used in daily institutional practice, and lastly to enable the integration of information about new media art collections with information about other types of collections from different institutions. In this last way, records of works of new media art from the ArtBase can be integrated with records of works in other variable media (installation, performance) and in fact traditional media (painting, sculpture) in large, union databases of works from several institutions such as “Museums and the Online Archive of California,”7 “Art Museum Image Consortium”8 and others.


Below is a suggested metadata scheme for the ArtBase and a crosswalk of other current metadata standards. The first column on the left indicates a set of elements based on a sub-set of the Dublin Core (an international digital library standard for describing digital documents of any type9), which is cross-walked with artwork metadata and then technology metadata in the next two columns. The next three columns provide equivalent elements in three other metadata standards: the Encoded Archival Description standard for describing collections used by archives worldwide10; the Categories for Description of Works of Art, developed by the Getty for museum art cataloging11; and MARC, the bibliographic record format standard used in libraries from the Library of Congress to local public libraries12. In a simple database management system, each metadata element could be the equivalent of one database field, but in more complex systems, each element may instead comprise a category of sub-fields. One field in particular (Artwork / description / variable media) will definitely need to be expanded to include additional relevant metadata such as that outlined in current and future iterations of the Variable Media Questionnaire which documents appearance, functions, and behaviors of the work separate from any one technology – allowing it to be re-created with different technology in the future. The element set below provides for three functions: standardized core cataloging data for management and access; documenting the original state of the work (at time of submission to ArtBase); and recording information needed for future emulation. Collecting this last type of data, in addition to the Artist’s Questionnaire metadata, will allow the ArtBase in the future to choose among emulation and re-creation strategies for various purposes.


Information about hardware is indicated below not for the purposes of hardware preservation but rather because an emulator must know which hardware to mimic. In some cases, hardware may also indicate physical installation components of a new media artwork. The addition of metadata for hardware/physical aspects of the artworks both enables emulation and also serves to update the current ArtBase metadata schema to allow for works, which have either or both digital and physical components such as gallery installations or robotic components. Below, each element/field is indicated in the table in black text; possible values and types of values for each field appear as italicized text.


DC Element




Technology *

Encoded Archival Description











Letters Through Time


Flash or

Macintosh G4



title (245)



Richard Rinehart


Macromedia Inc. or

Apple Computer Inc.



title (100)



net art



subject matter – index terms

subject (6xx)



email, memory


born in...


I remember…

original url


variable media questionnaire

elements of appearance, function, and behavior



network role





descriptive note

note (520)


date created


date released



creation- date

publish (260)





Browser or

Plug-in or

Server or



object type



Unique ID


current url




repository no.

note (024)


Contributors – agents *

Commissioner: New Langton Arts

co-creators – partners

Torchmate Inc.



anywhere (700)


Links to software & hardware

(See at right)


application or

os or

hardware or



materials - techniques



Human language *


base code






current presenter *


current owner -distributor



current locate – repository name


Note (533n)


rights and parameters

owners & restrictions

rights and permissions owners & restrictions


copyright - restrictions

rights (540a)


version *,


storage size,


storage location *,

CD no. 15

version *,

4.0 or

PPC 604 chip

storage size

* ,


storage location *

CD no. 16



publish (651)


* indicates new field, in addition to existing ArtBase metadata elements



The basic one-to-many record structure, which relates one artwork to the many types of technology needed to present it, might look like the following example (see diagram on following page). This example indicates that a full record exists in the ArtBase for one work of new media art, including all the metadata elements above such as creator, type, rights, format, etc. Links extend from the ‘format’ field in that record to the many related records in the Technology Database, which also comprise full records of creator, type, rights, etc.


Artwork Database

Record (new media artwork)

                        Format field 

                                                            Technology Database

Record (server/hardware)

            Sun Sparc Server

                                                            Technology Database

Record (client/hardware)

            Intel desktop

                                                            Technology Database

Record (server/OS)

            Unix BSD 4.0

                                                            Technology Database

Record (client/OS)

            Windows 2000/me/NT

                                                            Technology Database

Record (server/application)

            Perl 5.0

                                                            Technology Database

Record (client/application)

            Netscape 5.0



Currently, Rhizome allows artists who are submitting artworks to the ArtBase to enter metadata about their works. The Rhizome ArtBase Coordinator then reviews this artist-provided metadata and revises it as necessary before making it available to the public via the web site. It is recommended that this metadata generation and review strategy be kept as is for the time being, altered only in that artists are asked to submit the expanded metadata above. In the case of metadata about the artwork itself, each artist should be required to fill out all fields. In the case of metadata about the technology needed to run the artwork (note: not to author/edit the work), the submitting artist may choose from a list of pre-entered hardware and software records (such as those indicated in red in the example above.) These records are very similar to those already in place in the ArtBase submission form; but are here made explicit and more detailed in a separate technology database/table. If the correct record for a piece of technology does not exist in the system yet, the submitting artist may choose to create a new record.


It should be explicit to the submitting artist that they should select only as many technology choices as are minimally necessary to run the work (server OS, client-side software, plug-ins, etc.), but that they need not choose every possible configuration under which their work may run, just the one configuration under which their work runs best. It should also be noted that not every technical detail about a given software application or hardware platform need be exhaustively recorded in the ArtBase; such technology is better documented on a technical level elsewhere, but the ArtBase needs to relate such technology to specific works of art, and to contain sufficient detail about such technology to allow accurate identification of it well into the future.




It is recommended that the tool for managing both sets of metadata above be constructed as a relational database with two separate tables. Since a PHP/MySQL tool already exists at Rhizome for collecting ArtBase submissions online, perhaps it could be adapted and expanded to include the above metadata. However, years of museums’ experience in this field suggest that consideration should be given to using two tools; one for metadata gathering and public access online; another for internal metadata management. Whether Rhizome chooses to build one integrated tool or separate tools, one table in the artwork database should have a record for each artwork with a link to all relevant records in the technology database. Conversely, the technology database should have records for each instance of software, with links to all artworks that use that software.


Rhizome could develop a prototype tool using FileMaker Pro, MS Access or MySQL. This tool would need to be developed in an iterative manner to accommodate changes in the preservation methodology. One suggested strategy for near-term further development is to become involved or keep aware of other current tool development projects in the arts and cultural heritage community. For instance, the Berkeley Art Museum and the MOAC consortium have developed the “Digital Asset Management Database” (DAMD)13. DAMD has two features that may be of interest to the Rhizome and other digital preservation efforts. First, the DAMD architecture includes a complex rendering of the structure of a work, such as that indicated in the example above. In DAMD, one can catalog all the parts of an artist book and then relate each component to a multimedia representation. In the case of an artist book, this allows one to record the intellectual structure of the book (chapters), the physical structure (pages) and the virtual structure (digital images and transcriptions of pages). Similarly, new media artwork records could benefit from being broken down into component parts, with the appropriate technology/software records being linked into the appropriate components. DAMD also allows records to be exported into standards-based formats such as EAD, TEI, and METS flavors of XML, allowing the data to be shared outside the boundaries of any one organization. Whatever the strategy for development of this tool at Rhizome, it is recommended to start with a fairly simple metadata scheme and plan on updating the tool concurrently with any updates to metadata scheme or functional needs.




Collection Policy


Rhizome has implicit collection policies for acquisition and long-term maintenance of works in the ArtBase in the form of the ArtBase Linked Object Agreement and ArtBase Cloned Object Agreement. It is recommended that these agreements form the core of a more formal internal collection policy such as the recently drafted "Rhizome ArtBase Management Policy." Such a policy should be informed by the experience represented in most traditional museum collection and acquisition policies. This policy would, among other things, spell out in greater detail the internal functions that are mentioned in the ArtBase Artist Agreement, such as, “We also intend, but are not obligated, to provide access to obsolete software and to implement measures to preserve your artwork, such as documentation, migration, emulation and reinterpretation, as indicated in the Artist Questionnaire.” On this point for instance, it is recommended that this working paper constitute the amendment to the collections policy that details Rhizome’s specific strategy to “provide access to obsolete software and to implement measures to preserve your artwork….” On other points, the collection policy should specify what metadata will be created upon acquisition of a work either by the artist or by internal agents, what constitutes a minimal/core record (the metadata above is offered for these), and should specify organizational roles and responsibilities in detail. For instance, who has final approval of what gets included in the ArtBase? Who has final authority over what works are preserved? What are the exact mechanisms for obtaining updates from the artists and what constitutes a ‘good effort’ to contact the artist? What are the de-acquisition policies for works that will no longer be included or preserved? In addition, this is where Rhizome can internally outline strategies for backup, data quality control, and security provisions. It should be noted that a collections policy for Rhizome, as for any cultural institution, is more than a legal document that safeguards Rhizome; it is a working document and training manual for Rhizome professionals, and an expression of the commitment and limits of Rhizome beyond those with direct legal implications.


Obtain and Store Copies of Software


Rhizome should not, at this point, seek all the permissions necessary to preserve copies of unique or commercial software (such as operating systems, browsers and plug-ins) for the purposes of future emulation and presentation, but should rather leave this as a future project for the larger cultural community. At this point, Rhizome should operate within the existing compound of software licenses, which are usually flexible enough to allow one copy of the application software and one backup copy of the software to be kept for emergency purposes. Rhizome should endeavor to purchase or otherwise obtain legal copies of software needed to run the artworks contained in the Rhizome ArtBase. This software should then be stored and maintained in an organized fashion (see Storage Migration Strategy, below). Since emulation is not an immediate factor, this strategy should suffice for the near term. It is nonetheless clear that multiple intellectual property issues must be resolved before emulation can be adopted as a long-term strategy.


Outdated versions of most commercial software have very limited commercial value when new versions are released. This fact, along with other factors such as charity tax-relief, should help motivate commercial software companies to reach mutually beneficial agreements with cultural organizations.


Working out permissions and agreements for the re-use and potential modification of original software will be an absolute requirement for any organization using emulation as a preservation strategy. This work is perhaps better accomplished by a consortium effort, such as the Variable Media Network and Archiving the Avant-Garde project, where a collective of cultural agencies might have more bargaining power with commercial software companies and governmental agencies. Cultural agencies are encouraged to begin exploring legal options for preserving existing software such as fair use exemptions or other areas of the Digital Millennium Copyright Act14. Additionally, issues around the long-term preservation of original software should continue to head the agendas of advocacy organizations such as the National Initiative for Networked Cultural Heritage 15or Electronic Frontier Foundation16.


Storage Migration Strategy


Rhizome needs to have a backup and/or archiving strategy in place for at least three types of content: digital files comprising works of (cloned) art in the ArtBase; digital files comprising associated metadata (ArtBase database tools and files); and digital files of the original application software.


It is recommended that metadata (database and associated files) not be archived, but kept ‘online’ as a working document. This database should be routinely backed up in case of emergencies, in the case of any updates or versions, and because this data has great value in the preservation effort. But this resource could be backed up via hard disk redundancy, tape, or other media, as the idea is to keep the metadata alive, up to date, and accessible. Fixed, outdated, historical copies of the metadata are unnecessary. However, for the other two types of content—new media artwork files and original software—a more ‘archival’ storage migration strategy is recommended. The basic idea is that the original files should not be changed at all in the preservation effort, but that the storage media on which they reside will need to be routinely changed or migrated.


Original artwork files and original software will be needed to produce future emulations, so the digital files comprising the artworks and the original software should be copied onto backup copies of either an optical, read-only, fixed storage medium such as CD-ROM (using ISO 9660 standard format) or data-DVD. Dynamic, re-writable storage such as hard disk or tape could also safely be used, if extra redundancy is built in to compensate for the risk of erasure. All original software documentation (manuals in print or digital form) should be maintained as well. Metadata about the location and CD number of each CD should be recorded in the metadata tool (artwork and technology databases) for future retrieval. This content should be reviewed at least once every three years to determine if migration to a new storage format is warranted. As with all backup media, one copy of each CD should be kept on-site at Rhizome, and another copy of each kept off-site, preferably in another city, but at the very least in a separate building. Rhizome should establish a regular schedule for copying and distributing new CD’s.


This ‘archival’ strategy may seem to be at odds with any notion of the variability of new media artworks, but there are a few points that help reconcile this seeming contradiction. First, this strategy of keeping original software on fixed media supports the strategy of emulation, but emulation should form only one component of an overall preservation strategy. Emulation will in many cases recreate only a snapshot or partial function of a work of new media art. Second, while this effort to store original software in order to reproduce artwork does require maintenance of some original content, it actually serves to support variability as well. Preserving the original software saves us from having to preserve the original hardware by allowing the artwork to be reproduced on future, unknown, computer hardware through emulation. Third, if a work is completely re-created (as opposed to emulated) in the future, some or none of the original hardware or software may be used in that version of the work. However, good metadata records about what was used in the work’s original incarnation cannot help but inform all subsequent recreations. Last, most digital preservation strategies would include periodic migration of the storage media and the content (changing the format of all relevant media, software and files into contemporary formats).  However, since the specific strategy of emulation is assumed here, the only component that needs to be migrated is the storage medium itself. Everything else remains in its original format.


Conclusion on Emulation


Because of the significant expense and time involved, Rhizome need not at this point undertake the experiment of testing the actual emulation of original software and artworks on it’s own. Rhizome is encouraged to participate in future collaborative projects where artwork emulation takes place. It is clear that such emulator software, written for the purposes of long-term preservation, will need to be itself based on international standards, hopefully in an open-source manner, and will need to operate at the hardware level (emulating a chip instead of any one operating system or application). The long-term preservation of culture cannot depend on the indefinite health of any one company which may own exclusive rights to proprietary emulation software. Individual vendors surely have a role however in developing value-added emulator software and marketing and maintaining their version. Existing commercial emulators such as SoftPC provide areas of somewhat interesting experimentation, but since they emulate only the OS, and are completely proprietary, they cannot be relied upon for the long-term. Open-source or individual game emulators such as those written by game-hackers are an interesting model, but are even more limited for long-term preservation purposes because they are written to emulate one game platform (sometimes), or just one game/application (commonly). In addition, an individual is not a reliable maintenance agency for the long-term availability and maintenance of such emulation code. The bottom line is that we now have some interesting cases of emulators that show promise, but we still have work to do if we are to regard emulation as a long-term cultural preservation strategy.


Rhizome will make a unique, significant and feasible contribution to digital preservation efforts by proposing and testing solutions for metadata and policy as outlined above. Rhizome is helping to set the stage for following efforts, such as the Variable Media Network, and Archiving the Avant-Garde, in which a larger consortium of organizations will undertake the costly project of commissioning an open-source hardware emulator. Other organizations wanting to take advantage of this future emulator are encouraged to refer to this document and to establish the appropriate metadata, storage, and policy solutions in order to prepare themselves for emulating artworks or other digital documents.






2.   ArtBase

3.   Variable Media

4.      Archiving the Avant-Garde

5.      Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation, Jeff Rothenberg

6.  Artwork The Straw that Broke the Museum's Back?  Collecting and Preserving Digital MediaArtworks for the Next Century, Richard Rinehart

7.      Museums and the Online Archive of California

8.      Art Museum Image Consortium

9.      Dublin Core

10.    Encoded Archival Description

11.    Categories for the Description of Works of Art

12.    MARC

13.  Produce, Publish and Preserve: A Holistic Approach to Digital Assets ManagementGuenter Waibel


14. Digital Millennium Copyright Act

15. National Initiative for Networked Cultural Heritage


16. Electronic Frontier Foundation
















Richard Rinehart is Director of Digital Media at the Berkeley Art Museum/Pacific Film Archive, Digital Media Faculty in Art Practice at UC Berkeley, and is a net.artist. Richard can be contacted at