ARCHIVAL NATURE OF OUR MATERIALS
I agree with previous comments that the White Paper seems to be informed by
experience with discrete objects (photographs and books) rather than by
archival concerns. Archival objects are defined by their contextual links,
and it is important that the metadata capture and reflect the multiple
relationships of the archival object. I would be interested in particular
to see if the metadata proposed for this project encompasses all the
metadata identified by the University of Pittsburgh Electronic Records
project. Their guidelines, available at <http://www.sis.pitt.edu/~nhprc/>,
are designed to ensure that electronic objects can serve as evidence.
While we might conclude that not all the Pittsburgh elements are required,
we do want to make sure that digital objects created in this project meet
the archival requirements of evidence.
DEFINITION OF THE ARCHIVAL OBJECT
I was struck on p. 6 where the definition of the "Diary" object class
includes both scanned TIFF page images and textual transcriptions. Aren't
transcriptions new records, and new representations of the archival object,
rather than the equivalent of the original object? We must be clear that a
transcription of an archival document may be a new category of metadata,
but it is not equivalent to or a replacement for the original document.
ADMINISTRATIVE METADATA
I noticed that the administrative metadata described in the paper refers to
the digital image. The owner of the image, for example, refers to the
"copyright on the digital image only, not the work(s) represented in the
digital image." Where do we capture the metadata associated with the
original archival object? (This seems especially important since most of
the material we are scanning is unpublished and hence still protected by
copyright.)
CAPTURE AND STORAGE OF METADATA
While the White Paper emphasizes on p. 21 that no common storage format for
the metadata is advocated, I am still confused on how the MOA2 project will
work in practice. If our metadata is to be combined and made
"interoperable" at Berkeley, it would obviously be advantagous to develop
it in a common format. We have heard talk of templates and databases, but
I need a much clearer indication of what tools we will be using, and when.
OBJECT MODEL
I was intrigued by the idea of including "methods" with "objects" (p. 7-8).
I will show my ignorance of object-oriented databases and ask whether
there are any migration problems associated having methods part of the
database?
NEXT STEPS?
On an entirely different front, we need to begin our planning very quickly
if we are to actually move into a production environment. When can we
expect final word on what NEH actually funded, and what is the new time
frame for working on the project?
---------------------------------------------------------------
Peter B. Hirtle
Assistant Director pbh6@cornell.edu
Cornell Institute for Digital Collections 607/255-4033 (ph)
2B Kroch Library 607/255-9524 (fax)
Cornell University <http://cidc.library.cornell.edu/>
Ithaca, NY 14853
----------------------------------------------------------------