Minutes of July 16, 2003 Meeting
Present: Isaiah Beard (recorder), Anne Butman, Tom Frusciano, Judy Gardner, Michael Giarlo, Nick Gonzaga, Dave Hoover, Patrick Huey, Ron Jantz, Linda Langschied, Sam McDonald, Ann Montanaro, Lynn S. Mullins, Robert E. Nahory, Jeffrey Triggs, Karen Wenk, Yu Yang (all group members present)
The Digital Project Process (see attachment 1) was presented and reviewed by the group to assess where DAWG stands in its ability to evaluate and support a digital project if an individual or group were to present one.
Re: Considerations for project acceptance - In discussion, KW suggested that perhaps two review streams need to be developed: one to approve content and one to approve the project based on collection criteria, support requirements, etc. AM stressed that importance also needs to be given to what value the project has in showing what Rutgers has to offer to the community.
Re: Post-acceptance - LL raised issue of student labor, and the consideration needs to be made of where such funding will come from. Availability of equipment, scheduling, and file storage are also important factors
Re: Data preservation - RJ posed the question: what gets preserved and what doesn't? Preservation of all data is a massive undertaking and we will need to determine what we should archive and preserve and what should not be archived once support is dropped. DH, IB suggested the possibility of placing archival responsibilities in the hands of requestors in cases where we choose not to backup using Fedora and the mass storage device.
DH reviewed discussions with Grace Agnew on what role the mass storage device would play in archiving and backing up data. Per the original concept, the MSD would primarily store metadata and objects. Other individual server components (OS, interface, server apps) would be backed up locally. In such a case, Fedora would act as the store-and-use interface through which MSD would be accessed.
Per group suggestions, there should also be directly accessible partitions for server backups to occur. The MSD will not be directly accessible to servers not sharing the same local network, but options such as ftp can be used to transfer files directly to these partitions.
Consensus is that the Fedora interface is a preservation platform for external applications, as well as a native application environment for new projects.
RJ presented several models for the Book/Complex Object Structure (see attachment 2), along with pros and cons for each model. Models vary based on data streams, etc and some were based on suggested models by the University of Virginia.
Based on group discussion, Book Object Example 1b seems to best meet our needs.
[Note: Post-meeting, RJ submitted a revised model, Example 1c, which has been included in attachment 2. Object model 1c incorporates some of the changes to 1b that were discussed in the meeting. 1c should be used as the preferred model for books until we learn more from experimentation.]
Development on workflow continues. Feedback currently being sought from RJ, and waiting for a list of metadata fields to incorporate.
Fedora 1.0 is running. Currently two interfaces are available: a search page for end users, and a management page to upload, expunge and manipulate objects. Photographs and simple objects have been ingested, and presently looking for complex objects to test with.
For the next meeting, JT is to test items for Book Object Structure 1b using Fedora, including full text searching. JT is to use books from the Realiti project for testing purposes.
Several draft documents are ready. A one page standards summary detailing the image specification requirements for NJDH was distributed, along with a document summarizing quality control factors and workflow, and a third document outlining environmental and basic hardware requirements for lab set up. Group members were asked to review these documents and provide feedback and suggestions.
Next Meeting: Wednesday, August 20, 9:30 a.m. in the Heyer Conference Room.
Book Object Example 1
(Simple object with only two datastreams)
Book Object Example 1a
(Simple object with multiple datastreams)
Book Object Example 1b
(Simple object with multiple datastreams, separate objects for tiffs)
Book Object Example 1c (Simple object with multiple datastreams, separate objects for tiffs)
Book Object Example 2 (complex object - separate objects for page images)