ALA Midwinter 2010, Boston
Machine-Readable Bibliographic Information Committee
January 17, 2010 Meeting
Notes by Liz O'Keeffe

MARBI notes for the meeting on Sunday, Jan. 17 (I missed the Saturday meeting because I was at a meeting on Descriptive Cataloging of Modern Manuscripts; maybe Sherman can share his? [I plan to get them written up and will post them at this site])

Proposal 2010-03, Place and Date of Capture

RDA provides greater granularity than the MARC21 formats in relation to Place of capture and Date of capture. The proposal offered two options for recording this information at the level of granularity required by RDA: 1) add non-coded information to a coded field (the 033); 2) add parsable fields to the 518, which was previously a free-text field. It was decided that it would be easier to add parsable fields to the 518 than to make the 033 serve as a source of eye-readable data (it was designed for data manipulation, rather than for display). Sherman Clarke suggested defining the new fields for place of capture information as both controlled and uncontrolled—-this would allow for place names that are difficult to control, e.g. "Joe's Apartment", as the place a jazz session was recorded, or "the second tomb on the left within the Royal Palace", as the place where an art object was discovered. The possibility of widening the definition of both fields to cover discovery of art works (as well as natural objects) was discussed; no one seemed against it, though it wasn't formally changed at the meeting.

Proposal 2010-04, New Data Elements for Works and Expressions

New fields are being defined for MARC to reflect data elements that RDA is requiring when needed to break a conflict (and which can be entered in the record, even if not required to break a conflict). The new fields most relevant to art catalogers are 380 (Form of Work) and 381 (Other Distinguishing Characteristics).

Form of Work (380) includes what visual resources people would call object type—it is probably the "tie-breaker" that would most often be used when trying to distinguish between two identifical headings for different works. And it is also a very valuable piece of information to have in a record, even when not needed to break a conflict. In the proposal, the field is defined as not repeatable, because of a misapprehension that RDA requires this; in fact, it doesn't, so it was redefined as repeatable (this is good for art cataloging, because some objects are defined both by form and by function, e.g. altar piece and panel painting, and some object types change over time, as their function changes).

Other Distinguishing Characteristics (381) is a catch-all for whatever tie-breakers don't fit into any other neat category. There is no way of providing rules that apply across the board, and someone said that the various communities should provide their own guidance. The LCRI on works of art based on the CAC's recommendations (25.5B, Named Individual Works of Art) lists date, medium, size, owner, catalogue raisonné number, alternative title, location, state, color, owner's accession number as possible tie breakers—quite an array. Perhaps after the dust settles on RDA, we might offer guidance on this for art works and buildings. (And also recommend including this information in authority records even when NOT required for conflict breaking; it would useful for many different purposes, from authority work to semantic web applications).

Discussion Paper No. 2010-DP03: Encoding the International Standard Name Identifier (ISNI) and the International Standard Text Code (ISTC) in the MARC 21 Bibliographic and Authority Format

This was a very interesting paper. The discussion did not include ISTC numbers (which are under revision), instead it focused on ISNI numbers, which are being assigned to public identities (not just bibliographic identities) by a consortium that includes the Society of Authors and Composers, the Performers Database, OCLC, British Library, and the Bibliotheque nationale. ISNI tracks the names of real people, pseudonyms, and fictional characters (e.g. Daffy Duck). It will provide a mechanism enabling automated processes between libraries, other data providers and different rights management societies, and enable more efficient management of rights monitoring and payments in the future. The $0 field will be used to encode ISNI numbers.

Issues that were raised included the perennial favorite, how will we know which field the identifier refers to? Mainly by its position in the string--though someone else suggested that the nature of the identifier will explain what it refers to (but this might be a problem in a heading that consists of a series of "Other distinguishing characteristics"). The issue of having multiple registries was raised: ISNI is one registry, but there might be others (cf. with the multi-lingual authority records). Multiple registries can be handled on the authority record, but not so easily on the bibliographic record (but some people want to use the bib record for these numbers because authority records are not created for every single heading). At any rate, there are growth opportunities here for registries of all sorts of names and name/title combinations, as in creator/title headings for works of art (paging CONA).

Discussion Paper No. 2010-DP02: Encoding URIs for controlled values in MARC records

There have been several earlier discussion papers on this topic. This paper suggested that instead of defining a new subfield for URIs within controlled headings fields (a tough task, since only one is left in the name fields), a punctuation convention such as angled brackets be used instead, e.g.:

110 2# $aUniversity of Texas. $bDept. of Anthropology.
$0{http://lccn.loc.gov/n86041077} $4spn {http://id.loc.gov/vocabulary/relators/spn}
[N.B. The curly brackets above are angle brackets in the proposal. My basic HTML page ate the angle brackets as you will read about momentarily.]

This would not require a change to the format (except, I guess, you would have to warn people that angled brackets had this meaning from now on).

In the discussion, it emerged that angled brackets would cause problems because they are used in XML schemas, but some other character could be used instead. Rich Greene, the OCLC rep, was unenthusiastic: it would require a significant amount of systems work, and no one has actually announced that they are going to be experimenting with this. But LC said they would try it out in their own database to see how it works; and Jennifer Bowen wants to test it for the eXtensible Catalog. [http://www.extensiblecatalog.org/]

Notes by Elizabeth O'Keefe, Morgan Library & Museum
eokeefe@themorgan.org


... go to other ALA reports ...