Digital Libraries- Metadata As If Libraries Depended on It

In digital library work, we often talk about metadata, what I jokingly call "cataloging by those paid better than librarians." A more serious definition would be "a structured description of an object or collection of objects." A MARC record for a book is clearly metadata but so, too, is an archival finding aid encoded in EAD, or even descriptive information embedded in META tags at the top of a web page. Metadata is increasingly everywhere-sometimes hidden, sometimes apparent.

But, as any cataloger will tell you, not all metadata is created equal. Excellent metadata is constructed in layers. First you must settle on what is important to you or to those you serve. You create containers (defined and codifed by schemas) to squirrel away the tidbits that will, taken as a whole, describe something well enough for your purposes.

A good container must solve a problem that people care about, but it must do so in a method that allows and encourages adoption (e.g., by being readily understandable). It should be extensible and alterable without breaking systems that will come to rely upon it. It also should be interoperable with systems that may have other metadata requirements.

Also, a metadata container can succeed or fail depending on how well it deals with granularity issues-how finely you chop your metadata. This is so critical an issue that next month's column will focus on it alone.

To create a new metadata container, you must imagine all required uses and provide the right hooks to make those uses possible. If you have done your work really well, you will have enabled uses that you never imagined.

When it comes to metadata containers, we live in interesting and fruitful times. Besides such longstanding workhorses as MARC, we also have the Dublin Core, Metadata Encoding and Transfer Syntax (METS), and most recently Metadata Object Description Schema (MODS).

The Dublin Core has been in development for several years and is meant to be a common meeting ground among richer descriptive metadata standards. METS is relatively new and aimed to encapsulate a digital object or set of objects in a standard wrapper. Descriptive metadata can either be embedded directly in the METS object, or the METS record can point to an external description using another metadata standard such as MODS or MARC. MODS, the newest draft standard, is much richer and more granular than Dublin Core but simpler than MARC.

Consider the following scenario: a book is digitized, and METS is used to organize all its files. The METS record points to (or embeds within it) a descriptive record using MODS. A simplified version of the MODS record is made available for harvesting so that service providers can build cross-collection search services.

More standards are not necessarily a problem, as long as they can fruitfully interoperate and exchange data when required. As libraries digitize collections, metadata is required to organize and provide access to this content outside of, or in association with, the library catalog. Also, some libraries are developing such things as working paper repositories, which have different metadata requirements. With such diversity of uses, a diversity of metadata containers is likely essential.

A good metadata container must provide for a method of qualifying the information held within a particular element, e.g, a subject heading. It may be useful to know that the text found within a subject field comes from a controlled vocabulary. If so, you can then qualify that information with a reference to the controlled vocabulary from which it comes. Using Dublin Core within an HTML META tag, this could be expressed as:

<meta name='DC.Subject' scheme='LCSH'

content='Vietnamese Conflict, 1961-1975'>

Another classic case that may require user qualification is the role that a person has in relation to the item. Dublin Core specifies a 'creator' field, but what does that mean? In one case the person identified may be an author; in another, a painter. There should be some method of providing this information.

A standard container and a means to qualify the information contained therein is only a start. Without guidelines on how the container is to be used, errors in interpretation and usage could render the metadata less useful. A classic example of usage guidelines is the Anglo-American Cataloging Rules (AACR), which defined how and with what information a cataloger was to fill the MARC metadata container.

Such guidelines are still a dream away for some recent entries into the metadata container field. But these issues are understood by the librarians involved, so it is only a matter of time before they are codified. Also, usage of these emerging metadata standards will inform and enhance the process of codifying their use.

Finally, we arrive at the ingredient that is at the very center of this enterprise-the information itself. What we know about that information both informs our intellect and limits our imagination as we develop new schema. In the 1960s, when MARC was created, who would have thought that it would help to have a place to put such things as book reviews and not so helpful to have a physical description?

Catalogers must learn new things, certainly, but also must apply much of their longstanding knowledge and many skills in new and interesting ways. Reference librarians must understand both the possibilities for user services presented by these new schema and the consequences to your mission should they not be used. Check the great list of metadata resources compiled by the International Federation of Library Associations and Institutions (IFLA).

Library administrators, pay close attention. Your library has the potential to serve your clientele in ways you never dreamed of. Your library also might be increasingly marginalized until your clientele never supports a bond issue again. Not everything libraries need to collect or provide access to can be usefully described using MARC, or accessed via a database vendor for a fee.

We're in a brave new world, in which MARC must make room for METS and MODS and whatever else becomes necessary to do our work better. Stand by your staff, give those who are eager what they need to learn and grow, and provide incentives to those who are reluctant.