None.

The agenda item for this meeting was discussion of a the idea of a "metadata framework" to guide our work as a committee and to guide further work on metadata generally at Yale.

Beacom began the discussion by suggesting that we could see the framework as articulating two different contexts for metadata: one, an "external" context--institutional, social, intellectual--in which we make and use metadata, the other, an "internal" context--primarily an intellectual context--in which we understand the metadata we create and use.

Stephen Yearl commented that the connections between these two contexts is critical and suggested that we keep our focus on how these two contexts blend together. For instance, the tools we use to create metadata, exchange it, etc. and the tools we use to make the data available to the end users--that the metadata describes (and comments on, etc.)--need to be considered together. The same can be said of support structures (job descriptions, work assignments, training support, etc.), policies and procedures, etc.

The above was the preamble to a discussion of two things: what do we think are the important parts of the "framework" and what should the committee be doing now to move ahead.

As we began to talk about the framework in the abstract, discussion quickly moved toward finding a concrete case to articulate. Questions such as Do we understand our local environment (Yale)? What use functions are required?  What are our goals?

So we began to talk about OAI PMH compliance as a hypothetical policy directive at Yale. The discussion was mostly a set of exporatory questions and some distinctions were made.

What would the effect of such a directive be?

What would be gained?

What would it cost (not simply in dollars?)

How does it fit with a tool like MetaLib?

We moved then to discussion possible areas of metadata needs at Yale on which we might focus our attention initially.

Although rights management, technical metadata, and preservation metadata were specifically mentioned, the discussion turned mostly to access needs.

Eli projects illustrate faculty needs. Visual Resources collection at Art and Architecture Library has immediate needs for more work on metadata for images. New digital/digitization projects need guidance and support on metadata. Moving existing project to next generation or to program status requires guidance on metadata. Making digital materials available within Sakai may drive some demand, too.

Management issues cross over types of materials. Rights, technical, administrative metadata issues not dependent on particular content type.

Reardon suggested we focus our discussion now on a doable first step: do something for access to digital image materials. It is an existing problem. It crosses units within the library and within the university. It affects collection building, access services, and classroom use. In the Library--VR collection, Beineck, MSSA, Divinity, and Walpole all actively engaged in creating and managing collections that include digital images--as primary objects or as metadata relating to the works in their collections.  Musuems and Gallery, too. Much discussion followed. Decision made to develop a metadata element set for images as a first step toward a fuller articulation of recommendations such as  best practices, content standards, tools, training, work flows, business models, etc.

ACTION:  Swanekamp to draft charge for a task force on a basic element set with an initial focus on images.

A task force to work on preservation metadata has been under consideration for some time. Decision made to push ahead with such a task force. This task force can develop ideas and practices narrowly focused on preservation while other groups work on other aspects of the metadata puzzle.

ACTION: Ann Green to work with Joan Swanecamp and the Chairs of the Preservation Committee to appoint members and draft charge for the Preservation Metadata Task Force under the IAC Preservation and Metadata Committees.