Print

Print


The date ranges have always been very helpful in determining which of our bibs belongs with each AAP at the point where the change comes to us locally.

I much prefer to have the original record cancelled and new records created.  We have been looking at next generation catalogs and, depressingly, they seem to operate on an extremely simplistic basis regarding AAP changes.  Exchange on a one to one basis is the only option we have seen so far.  None of the systems are yet designed to consider some changes more complex and queue them in some way for review.  

Thanks!

Jenifer



Jenifer K. Marquardt
Asst. Head of Cataloging & Authorities Librarian
University of Georgia
Athens, GA 30602-1641

________________________________________
From: Program for Cooperative Cataloging [[log in to unmask]] on behalf of Theroux, Manon (Secretary) [[log in to unmask]]
Sent: Tuesday, October 14, 2014 4:53 PM
To: [log in to unmask]
Subject: [PCCLIST] Corporate bodies that revert back to a previous name

We have identified a number of cases in which an existing authority record for a Congressional committee needs to be split into two records. These represent situations where the committee used one name (let’s call it Name A) for a period of time, then changed to a different name (Name B), then reverted back to the previously held name (Name A). Under AACR2, we were expected to follow LCRI 26.3B-C and use Name A to represent both the earlier and later instances of the name. Under RDA PCC policy, the two bodies need to be differentiated. Here is an example:

Existing record (n  79043116):
110 United States. $b Congress. $b Senate. $b Committee on Public Lands

According to our reference source, this name was used from Dec. 10, 1816-Apr. 18, 1821, and then again from Jan. 2, 1947-Jan. 2, 1948. So, in the RDA environment, we would need two access points:

110 United States. $b Congress. $b Senate. $b Committee on Public Lands (1816-1821)
110 United States. $b Congress. $b Senate. $b Committee on Public Lands (1947-1948)

We have done some research to identify which Congressional committees are affected. Using reference sources, we have also come up with the chronological qualifiers that could be used to differentiate the bodies. According to LC PCC Policy Statement for 11.13.1.1, a qualifier would get added to each of the names. The changes would carry down to the names of any subcommittees established under these committees as well.

However, before we start making changes to authority records and embarking on what will be a huge in-house maintenance project for us (and presumably for many other libraries and OCLC as well), we’d like to get feedback on a few questions:


1)      Should the date qualifier be the date range? RDA 11.13.1.5 simply says “Add a date or dates associated with the body …” We prefer to use a date range but have come across examples in existing authority records where only one of the two access points has been qualified and only the beginning of the date range has been used to differentiate, e.g.:
n  79029813:
110 1# United States. $b Congress. $b House. $b Committee on Science and Technology
no2007035638:

110 1# United States. $b Congress. $b House. $b Committee on Science and Technology (2007)

2)      There isn’t any movement afoot to introduce an LC-PCC PS to revert back to the old LCRI practice, is there? It seems doubtful, but we don’t want to go to the trouble of making these changes only have to undo them down the road.

3)      If an existing authority record needs to be split into two, rather than updating the existing record and creating one additional record, wouldn’t it be better to create two new records, then have the existing record deleted? That way incorrect heading flips could be avoided. The situation seems very similar to subject heading splits.

4)      Anything else we should be sure to do (or not do)?
Thanks,
Manon


--
Manon Théroux
Head of Technical Services
U.S. Senate Library
SR-B15 Russell Senate Office Building
Washington, DC  20510-7112
202-224-3833 (phone)
202-224-0879 (fax)
[log in to unmask]<mailto:[log in to unmask]>