Print

Print


And I would say that if the access point includes birth and/or death dates, the fuller form is not important for identification, and probably not in many other cases.

 

------------------------------------------

John Hostage

Senior Continuing Resources Cataloger

Harvard Library--Information and Technical Services

Langdell Hall 194

Harvard Law School Library

Cambridge, MA 02138

[log in to unmask]

+(1)(617) 495-3974 (voice)

+(1)(617) 496-4409 (fax)
ISNI 0000 0000 4028 0917

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Moore, Richard
Sent: Thursday, December 01, 2016 11:03
To: [log in to unmask]
Subject: Re: [PCCLIST] n 50083205 and adding Jr. when upgrading names

 

No, it doesn’t. It says to include it when not necessary, if the cataloguer considers it important for identification.

 

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Gene Fieg
Sent: 01 December 2016 15:59
To: [log in to unmask]
Subject: Re: [PCCLIST] n 50083205 and adding Jr. when upgrading names

 

See my latest post, where LCPS says to include it even when not necessary.

 

Gene

 

On Thu, Dec 1, 2016 at 7:52 AM, Moore, Richard <[log in to unmask]> wrote:

Perhaps because $q is only required if needed to distinguish one authorized access point from another (RDA 9.19.1.4), or, optionally, if the cataloguer considers it important for identification (corresponding LC-PCC-PS).

 

Regards

Richard

 

________________________

Richard Moore

Authority Control Team Manager

The British Library

                                                                       

Tel.: +44 (0)1937 546104                                  

E-mail: [log in to unmask]      

 

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Gene Fieg
Sent: 01 December 2016 15:45


To: [log in to unmask]
Subject: Re: [PCCLIST] n 50083205 and adding Jr. when upgrading names

 

Will check, but why isn't there a $q in the 100 field?

 

Gene

 

On Thu, Dec 1, 2016 at 7:14 AM, Prochazka,David <[log in to unmask]> wrote:

Yes, adding such references from former versions of a headings are VERY useful for automated updating of access points on bibliographic records in some ILSs, e.g. III.

 

David—

 

David Procházka | Music/Special Materials Cataloger | The University of Akron | Bierce Library—261C | Akron, Ohio  44325-1712 | 330-972-6260 | [log in to unmask]

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Adam L. Schiff
Sent: Thursday, December 01, 2016 8:51 AM
To: [log in to unmask]
Subject: Re: [PCCLIST] n 50083205 and adding Jr. when upgrading names

 

The previously established form should also be recorded in a 4XX field.  Over the weekend I closed out Fidel Castro's dates, and earlier this week I was contacted by LC because I did not include a reference from the former form.  I did not think such a reference was normally made, but I was pointed to the FAQ on personal names: https://www.loc.gov/aba/pcc/naco/personnamefaq.html#13

 

Example 2

AACR2:
100 1 $a Walter, David, ‡d 1948-
RDA:
100 1 $a Walter, David, ‡d 1948-2012
400 1 $a Walter, David, ‡d 1948- $w nne

a) Date of death added and record recoded to RDA
b) Reference is valid under RDA

So, your record should probably look like this:

100 1 Espenshade, Edward B., ǂc Jr., ǂd 1910-2008
375    Males $2 lcdgt
377    eng
378    $q Edward Bowman
400 1 Espenshade, Edward Bowman, ǂd 1910- ǂw nnea

 

Note that the fuller form of name should have been recorded in 378 as above.  I updated the 375 to reflect current PCC policy to prefer controlled vocabulary for this element, and the recommendations that PCC Policy Committee have recently approved from the ad hoc group on coding gender: http://www.loc.gov/aba/pcc/documents/PoCo-2016/Gender_375%20field_RecommendationReport.pdf  Finally, I believe that the coding of the $w in the 400 in this case should be nnea because there's no evidence that the name without Jr. in it represents usage of the person, so in this case the previous AACR2 form is not a valid reference in RDA.

 

Adam Schiff

University of Washington Libraries


From: Program for Cooperative Cataloging <[log in to unmask]> on behalf of John Hostage <[log in to unmask]>
Sent: Wednesday, November 30, 2016 4:49:18 PM
To: [log in to unmask]
Subject: Re: n 50083205 and adding Jr. when upgrading names

 

Not only is Jr. part of Espenshade's preferred name, but the evidence in the 670s indicates that his name is Edward B. Espenshade, Jr.  In other words, his middle name should be represented by an initial.  As Bob indicated, when making a change to an authorized access point, you have to evaluate the name as to whether it reflects the preferred name according to RDA.  Older authority records like this are especially likely to deviate from that standard, even if they have been coded RDA by machine.

Also, best practice is to put 040 $e before $c for consistency.

 

------------------------------------------

John Hostage

Senior Continuing Resources Cataloger

Harvard Library--Information and Technical Services

Langdell Hall 194

Harvard Law School Library

Cambridge, MA 02138

+(1)(617) 496-4409 (fax)
ISNI
0000 0000 4028 0917


From: Program for Cooperative Cataloging [[log in to unmask]] on behalf of Shorten, Jay [[log in to unmask]]
Sent: Wednesday, November 30, 2016 18:09
To: [log in to unmask]
Subject: [PCCLIST] n 50083205 and adding Jr. when upgrading names

I recently closed n  50083205 Espenshade, Edward Bowman, d 1910- , which was already coded as the RDA form, to Espenshade, Edward Bowman, d 1910-2008 . It has been pointed out to me that the source I quoted and some bibliographical records have “Jr.” as part of the name. Should I therefore have upgraded the name to Espenshade, Edward Bowman, ‡c Jr., ‡d 1910-2008 ? I had the idea somehow that when closing dates, if the name is indicated to be RDA or RDA-compatible, for the sake of not making needless changes, you accept the name heading as is and you don’t completely re-cast the name into an RDA form unless there is either an error in the name or the date or it has the dreaded 667 note.

 

e.g. In adding the death date to Espenshade, Gilbert H. ‡q (Gilbert Howry), ‡d 1912- you would not re-cast the name as Espenshade, Gilbert H., ‡d 1912-1992, even though that is a valid RDA form, since the current form is equally valid under RDA. But if it turned up that he was born in 1913 or that his middle name was Lowry and not Howry, then you could re-cast the name to Espenshade, Gilbert L., ‡d 1913-1992.

 

So I guess another of asking this question is: Is the absence of “Jr” in the name considered an error?

 

Jay Shorten

Cataloger, Monographs and Electronic Resources

Associate Professor of Bibliography

Catalog Department

University Libraries

University of Oklahoma

Co-owner, PERSNAME-L, the list about personal names in bibliographic and authority records

[log in to unmask]

 


 
******************************************************************************************************************

Experience the British Library online at www.bl.uk

The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html

Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook

The Library's St Pancras site is WiFi - enabled

*****************************************************************************************************************

The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [log in to unmask] : The contents of this e-mail must not be disclosed or copied without the sender's consent.

The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.

*****************************************************************************************************************

Think before you print