A. Montanaro reported that DAWG has not met since the last Data Arch meeting. They are completing the RFP for a mass storage device.
R. Bogan reported that the group has met once since the last Data Arch meeting. They have formed two smaller groups to work on descriptive metadata and context metadata. RB is leading the latter group. Context metadata is metadata that is extrinsic to an object. Some examples she gave were: collections of which the object is a part, exhibitions in which the object has been included, grant funding sources to develop the object, educational uses of the object in packages for learning objects, and reviews or citations of the object.
METS has not developed the technical metadata requirements. KA and RM have consulted various instantiations of digital collections including the MIC, the RUL Fedora prototype, Library of Congress (American Memory), and Stanford University's digital project site. They have an undifferentiated list of elements that needs to be organized under a TechMD structure. There is some difficulty determining when some elements should be in TechMD, DigiProvMD, and SourceMD.
KD and GS also have consulted many documents. They defined source metadata for the committee as that pertaining to the tangible source of the digital object. It includes both identity and descriptive elements. Many elements will likely have controlled vocabularies, and those could be extensive. KD attended a meeting convened by L. Langschied of archivists who are advising the New Jersey Digital Highway. The archivists advised NJDH on the content of the controlled vocabulary for source metadata. KD shared the vocabulary lists with the committee. Source metadata should be something that is provided once (preferably at the time of digitization) and will not have to be changed. KD and GS also remarked that some elements in SourceMD (pertaining to the physical object) will be the same as elements in TechMD (pertaining to the digital object).
MAC and HI distributed a brief explanation of DigiProvMD, along with an element outline. DigiProv tracks the life cycle of the digital object, as it is modified digitally. The group questioned whether every displayed image requires metadata (presumably in DigiProvMD), and in the end the preponderance of opinion was that only separately stored images require specific metadata. There is no need for metadata to manage an image created "on the fly."
RM summarized the role of these parts of the administrative metadata as follows, glossing over many details in the process:
The administrative metadata does not have to be organized so strictly in actual application. Some redundant information could be entered once and copied to multiple elements. We are using this hierarchical structure in order to understand the elements, and their relationships to the object and to each other.
In addition to looking at numerous examples of METS headers, RB and EL consulted with R. Jantz about how Fedora handles the METS header. It doesn't, so elements have to be moved to other administrative metadata areas. RB distributed a chart of the METS header elements. Only the metsHeaderID, createDate, modifyDate, and recordStatus remains in the METS header.
Discussion of work on the best practices manual was deferred until the November meeting.
L. Langschied demonstrated the Workflow Management for Digital Objects that P. Huey in the SCC is developing for NJDH. It helped to ground our theoretical discussions to see how administrative metadata could be supplied on a web-based form in Plain English (well, almost) for ingest into a digital repository.
Next Data Arch meeting: Monday, November 17, 9:30 a.m., TSB Conference Room