Preserving the Rhizome ArtBase

Preserving the Rhizome ArtBase.   Richard Rinehart.   September 2002.

Discussion of preservation strategies for new media and net art.

<> With thanks to Rhizome for permission to reproduce.

Preserving the Rhizome ArtBase
Richard Rinehart
2
Table of Contents
Preserving the Rhizome ArtBase................................................................................... 1
Introduction....................................................................................................................... 3
Emulation as a Preservation Strategy .......................................................................... 4
Recommendations ........................................................................................................... 5
Tools................................................................................................................................ 11
Collection Policy ............................................................................................................. 12
Obtain and Store Copies of Software ......................................................................... 12
Storage Migration Strategy........................................................................................... 13
Conclusion on Emulation .............................................................................................. 14
3
Introduction
Rhizome.org 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
4
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 a 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:
Document/file
Application/program software
Operating System (OS)
Hardware
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).
5
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.
Recommendations
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.
6
Metadata
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
7
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 subfields.
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
8
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
ArtBase
Artworks
ArtBase
Technology *
Encoded
Archival
Description
CDWA MARC
title title
Letters
Through Time
name
Flash or
Macintosh G4
unittitle title title (245)
creator artist
Richard
Rinehart
creator
Macromedia Inc.
or
Apple Computer
Inc.
origination creation-creator title (100)
subject genre
net art
subject subject matter –
index terms
subject
(6xx)
description keywords,
email,
memory
biography,
born in...
statement,
I remember…
original url
http://coyoteyi
p
variable
media
questionnaire
elements of
appearance,
function, and
behavior
description,
interfacecontroller
network role
server-side
or
client-side
scopeconte
nt
descriptive note note (520)
date date created
01/23/1999
date released
09/22/1999
unitdate creation- date publish
(260)
type Type
interactive
Type
Browser or
Plug-in or
Server or
robotics
genreform object type (007)
identifier Unique ID
09933
current url
http://rhizome
unitid repository no. note (024)
contributor Contributors –
agents *
Commissione
r: New
co-creators –
partners
Torchmate Inc.
origination creationcommission
anywhere
(700)
9
Langton Arts
format Links to
software &
hardware
(See at right)
format
application or
os or
hardware or
installation
physdesc materials -
techniques
(007)
language Human
language *
English
base code
C++
lang inscriptions
publisher current
presenter *
coyoteyip
current owner -
distributor
Macromedia
repository current locate –
repository name
reproductio
n
Note
(533n)
rights rights and
parameters
owners &
restrictions
rights and
permissions
owners &
restrictions
admininfo copyright -
restrictions
rights
(540a)
coverage version *,
1.0
storage size,
15mb
storage
location *,
CD no. 15
version *,
4.0 or
PPC 604 chip
storage size
* ,
45mb
storage location
*
CD no. 16
geogname measurements 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.
10
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 Rhizome.org 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
11
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.
Tools
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.
12
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
13
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
14
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 its 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
15
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 gamehackers
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.
Notes
1. Rhizome.org
https://rhizome.org
2. ArtBase
http://rhizome.org/artbase
3. Variable Media
http://www.guggenheim.org/variablemedia/
4. Archiving the Avant-Garde
http://www.bampfa.berkeley.edu/ciao/avant_garde.html
5. Avoiding Technological Quicksand: Finding a Viable Technical Foundation for
Digital Preservation, Jeff Rothenberg
https://www.clir.org/pubs/reports/rothenberg/contents.html
6. Artwork The Straw that Broke the Museum's Back? Collecting and Preserving
Digital MediaArtworks for the Next Century, Richard Rinehart
http://switch.sjsu.edu/web/v6n1/article.htm
7. Museums and the Online Archive of California
http://www.bampfa.berkeley.edu/moac
8. Art Museum Image Consortium
https://www.amico.org
9. Dublin Core
https://www.dublincore.org
16
10. Encoded Archival Description
https://www.loc.gov/ead
11. Categories for the Description of Works of Art
http://www.getty.edu/research/institute/standards/cdwa/
12. MARC
https://www.loc.gov/marc
13. Produce, Publish and Preserve: A Holistic Approach to Digital Assets
Management Guenter Waibel
http://www.bampfa.berkeley.edu/moac/imaging/index.html
14. Digital Millennium Copyright Act
http://www.loc.gov/copyright/legislation/dmca.pdf
15. National Initiative for Networked Cultural Heritage
http://www.ninch.org
16. Electronic Frontier Foundation
https://www.eff.org
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 [email protected].