Task Force on Metadata and the Cataloging Rules
|
|
Committee on Cataloging: Description and Access Task Force on Metadata and the Cataloging Rules |
Metadata included with digital materials has significant potential as a source of information about those materials. Such metadata can be used as the basis for designing an information storage and retrieval system. Alternative, the metadata can be imported into existing data structures (such as USMARC bibliographic records) and used by existing information storage and retrieval systems.
The specific interest of the Committee on Cataloging: Description and Access is in the use of metadata as a source of information for standard descriptive cataloging records that conform to the Anglo-American Cataloguing Rules. As various metadata standards have been emerging in recent years, the Committee began to take a formal interest. The first result of that interest was a position paper by Sherry Kelley and Brad Eden, which looked at one particularly relevant metadata standard, the specifications for a file header for electronic texts encoded according to the Text Encoding Initiative.
Following a recommendation in the position paper, the Committee appointed a Task Force on the Relationship of the TEI Header and the Cataloging Rules. Quickly realizing that the TEI Header was but one metadata scheme among many, the Committee expanded the Task Force's charge to include other metadata schemes. The Task Force has been re-named Task Force on Metadata and the Cataloging Rules.
Part of the Task Force's charge is to investigate "the proposed Dublin Metadata Core Element Set and evaluat[e] its use as a source of information for cataloging." This Web page is intended to serve as the focus for that investigation and evaluation. It will consist of:
The Task Force welcomes any comments on the examples and on our comments. Or you can contribute your own examples. There will be "e-mail" icons scattered throughout the site; if your browser is set up to send mail, you can do so by clicking on one of these icons. Or you can send your comments to me at the address below:
Some of the details are included only in the Crosswalk. For example, many of the data elements may include TYPE or SCHEME attributes which characterize the data and are often necessary for accurate mapping to MARC fields.
The Dublin Core was intended to be applicable to all sorts of digital objects (e.g., sound or images as well as text). However, for convenience in sharing our examples, please select an HTML (World Wide Web) site. This makes it possible for the metadata to be formulated in a fairly simple standard manner.
You can select any site, but it will work better if (a) you actually have control over the files and can add the metadata to the file header, and (b) you are thoroughly familiar with the site. The intent of the Dublin Core effort is that the metadata will be supplied by the creator or publisher of the site. Therefore, in supplying the metadata, we will be engaged in a certain amount of role playing: What is the creator of this site likely to say about it? The first example below is a perfect case study because I created it myself. If you have created a Web site, you might want to start with that.
This convention consists of two pieces, both included between the <HEAD> and </HEAD> tags in the HTML file. One piece is a repetition of the <META> tag for each data element. The syntax is:
For example, the syntax for the Dublin Core TITLE element would be:
The other piece is a <LINK> tag containing the URL of the metadata reference description:
In our case, the link to the Dublin Core reference description would be:
Don't worry about all the detail. A template for the entire Dublin Core is available on this site. Just copy the source code and fill in the CONTENT data for each element. All Dublin Core elements are optional, so just delete anything that doesn't apply or that you don't feel like typing). And all Dublin Core elements are repeatable, so just copy-and-paste the code for any element you want to repeat.
Remember, we're role-playing here. Think of yourself as the author or publisher of the file. What would you say about it? You can also role-play as a cataloger and ask yourself what you would put in these various data element if you wanted to follow AACR2. More about that later.
A Note on qualifiers: In the template, most of the elements include qualifiers (SCHEME and/or TYPE). There is still a lot of work being done on these qualifiers, and any use of these qualifiers should be considered tentative. A recent proposal by Rebecca Guenther is available if you want to see more detail. The template includes some of the more reliable choices, separated by vertical bars. Please note that there is a default for each qualifier, i.e., an assumption to be made when the qualifier is not given. For purposes of this exercise, I would suggest that default values should be used unless there is a good reason to give a qualifier.
Resource types: It is anticipated that this element will be based on a closed list of terms. One such list is available on the Internet.
You can stop at this point and send me the raw metadata.
I can post it on the site and do the USMARC mapping.
The mapping decisions have been reduced to a workform which you can copy and fill in. There are lots of choices, indicated by "(if ... )" notes. Delete anything that doesn't apply.
Rules of the game: This part of the exercise is intended to work as if it were being done by a machine. The Crosswalk document notes that "A cataloging agency may wish to extract the metadata provided in Dublin Core style (presumably in HTML or SGML) and convert the data elements to MARC fields, resulting in a skeletal record. That record might then be enhanced as needed to add additional information generally provided in the particular catalog." That is the scenario we want to investigate.
The crosswalk is supposed to be designed so that there is always a default mapping for every metadata element, with exceptions indicated by TYPE or SCHEME attributes. There are some missing MARC elements, mostly indicator values; the workform supplies a default. One of the questions you will want to consider is whether these defaults are correct. But don't change them when you create the preliminary record; the point is to see what the machine can do all by itself. So just paste the metadata CONTENT strings literally into the appropriate MARC subfields.
Once again, you don't have to do the mapping yourself.
Just send me the metadata. On the other hand, you might want to try the mapping and
see what happens.
Finally, play your role as a cataloger. If you were creating the metadata and wanted it to conform to AACR2, which elements would be governed by AACR2 and which rules would you apply?
There is a questionnaire that goes over all of the above in more detail. Make a copy, fill it out, and send it in.
Or just send comments.
You can paste all of this into a single e-mail message, into several messages, or attach them as files (MIME type, please).
And if you don't want to contribute an example of your own, we'd still like to hear your comments on the examples already on the site.
Example 1: John Locke Bibliography
Example 2:
Cornell University Library Technical Services Manual
Example 3:
New York State Citizens' Coalition for Children home page
Example 4:
"Maintaining commitment when a child can't live at home"
Example 5:
Picture of the attendees at the recent conference on Metadata in Australia
Example 6:
List of Publications of the Bureau of American Ethnology
Example 7:
"Samuel Finley Breese Morse"
Example 8:
"Photograph of Samuel F. B. Morse"
Example 9:
"Photograph of the first public telegram in the world"
Example 10:
Electronic Journals Annotated List
Example 11:
Cataloguer's Toolbox
The Task Force is planning to submit its final report to CC:DA in June 1998. A draft of the Dublin Core section of the report is available here. The full report will be assembled on the Task Force site.
Back to: Task Force home page