OLAC Newsletter
Vol. 29 | No. 1| March 2009

The OLAC Newsletter (ISSN: 0739-1153) is a quarterly publication of the Online Audiovisual Catalogers, Inc. appearing in March, June, September and December. Permission is granted to copy and disseminate information contained herein, provided the source is acknowledged.

In this issue

From the Editor

Treasurer's Report

OLAC Meeting Minutes:

• CAPC
• Executive Board
• Membership

Conference Reports:

• MARBI
• CC:DA
• AMIA

LC Update

MOUG/OLAC Liaison Report

Reports from the 2008 OLAC/MOUG
Conference, Part II:

Workshops:

• Elect. Resources
• Form/Genre Headings
• Integrating Resources
• Metadata for Audiovisual Materials
• Worldcat Local
• RDA Program
• Poster Sessions
  

News and Announcements

Announcement of New Officers

Book Reviews:

• Metadata
• Kidzcat

OLAC Cataloger's Judgment:

• Sounds & Silence
• Edition or contents
• Order of names in 505
• PowerPoint on CD-ROM
• Mysteries of the 007
• Which came 1st 508 or 511
• True colors
• Computer file vs. video
• Auteur theory questioned

News from OCLC

** REPORTS FROM THE **
2008 OLAC-MOUG Conference
Cleveland, Ohio
Part II

Jan Mayo
Column Editor

INTEGRATING RESOURCES
Presented by Joseph Hinger
St. John's University

--reported by Amy Pennington, Saint Louis University

This workshop was a condensed version of the longer SCCTP Integrating Resources Cataloging Workshop that Hinger has given in various locations.

Hinger began by giving some brief background to the development of cataloging rules, guidelines, and codes relating to integrating resources, due to the changing
"bibliographic landscape." These new AACR2 rules, LCRIs, and Leader Bibliographic level code "i" were implemented in 2002. He explained that AACR2 Ch. 12 (Continuing Re-
sources) now has two parts for each rule: one that relates to serials and the other to integrating resources. In addition, there are two types of integrating resources: print (updates are integrated into the original base volume), and electronic (updating Web site). He made the point that, just because a print resource "has holes" and lives in a binder, that does not make it an integrating resource; you have to look at the content and intent. The concept of "updating" is central to the definition of an integrating resource.

Hinger also spent some time explaining some of the differences between monographs and continuing resources (including both serials and integrating resources), and how to
tell them apart (LCRI 1.0). Continuing resources have no predetermined conclusion, but the various parts or updates may remain discrete (serials) or not (integrating resources). A monograph, on the other hand, is either complete in one part or a finite number of separate parts. He went on to explain, however, that even a finite updating Web site (a conference Web site, for example) is still an integrating resource, and that online and loose-leaf format resources may be monographic, serial, or integrating. A CD-ROM or any other direct access e-resource cannot be an integrating resource. In terms of re-
mote access resources, if you can access the earlier iterations you probably have a serial or multi-part monographic item; if you cannot access the earlier iterations, you have an integrating resource. If you truly cannot determine what it is, consider it an integrating resource.

The first steps in original cataloging of an integrating resource include: determining the aspect of the resource that your bibliographic record will represent, the type of issuance,
the primary content (which affects the Type of Record and 008 / OCLC workform you will use), and the iteration you have (which affects how you record dates of publication). He
went on to describe in more detail the MARC leader and control fields that are used for these resources.

The next part of the workshop dealt with bibliographic description (using AACR2 12.0B1b). Those areas that are based on the current iteration include: title and statement
of responsibility; edition; publication, distribution, etc. (except dates); physical description (optional for e-resources); and series. Areas based on the first and/or last iteration(s) include: dates of publication, distribution, etc. Areas based on
all iterations and any other source include: notes; standard number and terms of availability. One change since the 2004 update of AACR2 is that one is no longer required to use the 516 field (type and extent of resource); rule 9.3 was deleted
with this update.

An important point made concerning publication information is that square brackets are not needed as long as the information comes from anywhere on/in the resource.

When discussing publication dates, Hinger emphasized that DtSt fields are extremely important, and that getting something in the Date 1 field is much better than nothing
(even if it is just 199u). If you have the publication date of the first iteration (unlikely), it can be put in the 260 field. If no explicit statement of publication date of first iteration appears, put estimated date (or range of possible dates) in the 362 field.
It was also pointed out that a copyright date should not be considered an explicit statement of date of publication. Although, if a range of copyright dates appears, one can probably assume a correspondence with publication dates.

Concerning note fields, Hinger mentioned that he does not generally use a system requirement note about Adobe Acrobat Reader being required, or a mode of access note that specifies "World Wide Web." He thinks those are obvious in this day and age. A source of title proper note is absolutely required.

Hinger also discussed some concerns with 856 fields. One important thing to remember is that the URL used in the 856 must match the granular level of the description (link for
home page if home page is being described, for example). He recommended not using $z (Public Note) for link text (or for explaining restrictions, etc.) in OCLC records. Obviously you can do what you want or have to do to make things displays properly in your local system.

When it comes to updating integrating resource records, anything can change (just like serials), but all the changes must be reflected in the same bibliographic record.

One last important thing that was discussed was the use of the 247 and 547 fields with integrating resources. 247 $a is used for the title proper when it changes, and $b is used
for the corresponding dates, if known. The 245 field always reflects the current title proper, and all former titles go in 247 fields. The 547 field is a complexity note that goes with it, if further information about the 247 field(s) is needed.

Hinger kindly provided copies of his full SCCTP workshop presentation slides as a handout, and even though we did not quite make it through the whole thing, everyone was extremely pleased with the amount of quality information and guidance received about cataloging these tricky resources.

Return to Table of Contents

METADATA FOR AUDIOVISUAL MATERIALS
AND ITS ROLE IN DIGITAL PROJECTS
Presented by Jenn Riley
Indiana University, Bloomington

--reported by Lauren K. Marshall, John Carroll University

Jenn Riley took her audience on a "whirlwind tour" of a representative sample of metadata standards compatible for use with images, audio, and video. The primary focus was on those standards used by cultural heritage institutions (e.g. libraries, archives, museums). She emphasized the importance of finding the right fit between one's needs and an appropriate metadata format. Also significant was the idea that metadata
standards reflect the values of those who created them to serve specific needs in describing, managing, and/or providing access to their resources. Objectives of the workshop were to lessen apprehension about metadata formats and to aid par-
ticipants in knowing what questions to ask themselves in making metadata decisions for digital projects.

The workshop began with an introduction to XML (extensible markup language), which is used to encode many metadata formats. The use of XML as a background encoding
of metadata formats enhances the shareability/interoperability of formats across systems and environments. Riley then explained four general types of metadata: descriptive, administrative, structural, and markup languages. Descriptive metadata serve to describe properties of resources, such as title, dates, publishers, etc. Administrative metadata help manage aspects of resources, such as preservation information, usage rights, or technical information. Structural metadata help the
user navigate within a resource or between related resources, e.g., within a digitized set of 10 audio CDs, organizing information related to the order and navigation of the CDs, tracks, and related text. Markup languages are not technically metadata, but are XML coding that "marks up" the full content of a resource with metadata, e.g., "header," "paragraph," etc., within a text document.

The next part of the workshop was a barrage of metadata schema examples (only a few of which are mentioned here), with information about their properties, interoperability, and usage. First, general descriptive metadata schema, e.g. MARC, Dublin Core, were covered. These are intended for use with a variety of media/resource types and tend to be bibliographic in nature. Media-specific descriptive metadata formats were discussed next; these standards reflect specific needs related to the description and access of a particular media type (still images, music, artworks, video, etc.) and do not
work well for generalization to other types of resources. Media-specific administrative metadata formats emphasize technical information involved in the creation, storage, and access of resources, e.g., file type and size, or camera/audio equipment settings at time of creation, and are often created by machine directly from digital file information. The primary structural metadata format discussed was METS (Metadata Encoding and Transmission Standard), which Riley termed a"wrapper" for packaging many types of metadata for a resource together, connecting descriptive and technical metadata with content, for example. METS documents would be generated by software tools, not people.

Riley concluded the workshop by presenting several scenarios and possible choices for implementation of metadata standards to meet the needs of those situations. She emphasized that in order to implement any metadata format, there must be tools and systems available to utilize it, and it must address the needs of the users and resources. Decisions about metadata implementation need not be constrained to the formats currently available, and Riley encouraged participation and leadership from the cataloging and metadata specialist community to contribute to the creation of useful metadata
formats and the tools/systems needed to implement them. Overall, despite the rapid pace of the presentation, Riley succeeded in imparting a level of understanding that should increase comfort levels of working with and making decisions about metadata formats and their uses.

Power Point presentation:
http://www.dlib.indiana.edu/~jenlrile/presentations/olac2008/olac.ppt

Handouts:
http://www.dlib.indiana.edu/~jenlrile/presentations/olac2008/handout.pdf

Return to Table of Contents