Re: [ACAT] The accidental cataloger

Posting to Autocat concerning the article “Inadvertent RDA: New Catalogers’ Errors in AACR2” by Jean Harden

On 26/09/2012 21:07, Harden, Jean wrote:

In other words, RDA does seem to be in some sense intuitive, at least in the rules about description, which is mainly what this project dealt with.

Thanks for doing this work. It is quite perceptive in a way I hadn’t considered, in essence, that when people do not want to look up the guideline (or don’t have the time) that what they create tends more toward RDA-compatibility than with AACR2-compatibility. This relates to what goes into the 245$c, forms of publishers’ names, bracketed data, and most interestingly to me, the “relationships” section (because of the hot discussion on RDA-L about my latest podcast).

I would say that in the paper, the “relationships” is not so much relationships of the author to the item, as using a qualifier to distinguish one person from another.

If I may quote:
“For instance, the Ben A. Brown Collection included a popular song with lyrics by Robert Bruce. There are many persons by this name in the LC authority file on OCLC. None are our lyricist, however. Because there is also an undifferentiated personal name heading for Bruce, Robert, we cannot simply use the name from the item without conflicting with this record. Consequently, we used Bruce, Robert, $c lyricist.

In our experience student catalogers are happy with this solution immediately. When they encounter the same person acting in another capacity, say as a composer, however, they want to give the name a $c for that other capacity: Bruce, Robert, $c composer. That is, they see the $c as a relationship designator rather than as a distinguishing term to make the heading different from other headings,”

This is using $c as a type of qualifier in an authority record to distinguish one Robert Bruce from another. The students see this as very good, and probably relate it to the disambiguation pages of Wikipedia. I have also said that I think this is an excellent solution, too and consider the Wikipedia disambiguation pages much better than our methods.

This differs from the $e relator codes which would allow “Bruce, Robert, $c composer” to become an editor of a specific work. The subfield e and its consequences is what my podcast was about.

Returning to the paper. It seems to me that the 245$c, the forms of publishers’ names, and the bracketed data are of greater importance to librarians than to the public. The form of a publisher’s name is of primary importance for record/item matching for cataloging and ILL, while bracketed data is meaningful only to catalogers. Concerning 245$c, some information would be lost to specific types of indexing, e.g. RDA’s treatment “The golden west, a silv’ry nest, and you / waltz song by Al Sherman & Al Lewis.” Here, “waltz song” in the $c will not let it be found by a keyword search limited to title subfields 245a and 245b. But this is not such a momentous consequence, I think.

The biggest concern the paper raises for me however, is more philosophical: the future of catalogers’ attitudes. If RDA really is more “intuitive”, will that lead to a lack of rigor and a lowering of standards? Would it rather lead to catalogers tending toward not looking up the rule in more and more cases, in the belief that they would already be correct or that it’s not all that important? In this regard, I always compare bibliographic standards to food or environmental standards. So for instance, would we want water quality standards or construction standards for our homes to be more “intuitive”? Would that be considered a positive development for those kinds of standards? I doubt if too many people would think this would be a positive development. The water quality should follow standards for the good of the community, period.

If “intuitive” is not considered a positive development for other standards, what is the difference between those standards and cataloging standards?

Thanks again for the article. It’s made me think.



Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *