Preserving the
Rhizome ArtBase
Richard
Rinehart
September
2002
Table of
Contents
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 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:
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).
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.
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
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 |
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://coyoteyip variable media questionnaire elements of appearance, function, and behavior |
description, interface-controller network role server-side or client-side |
scopecontent |
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 * Commissioner: New Langton Arts |
co-creators – partners Torchmate Inc. |
origination |
creation-commission |
anywhere (700) |
|
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 |
reproduction 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.
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 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.
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.
Notes
1. Rhizome.org
2. 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
http://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
9.
Dublin Core
10. Encoded
Archival Description
11. Categories for
the Description of Works of Art
http://www.getty.edu/research/institute/standards/cdwa/
12. MARC
13.
Produce,
Publish and Preserve: A Holistic Approach to Digital Assets ManagementGuenter
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
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 rinehart@uclink.berkeley.edu.