Print

Print


I might be in favor of using the relationship designators instead of $wnnnc, but I don’t think I agree with doing away with the established procedure for dealing with multiple pseudonyms (which has nothing to do with RDA or AACR2). It is true that RDA (and AACR2) appear to expect us to simply link all the names to all the other names, and this is probably better for most users than sending them to the “basic” form to find out all the names. The NACO procedure, it is true, is slightly less helpful to the user, but in my opinion it’s sensible and less prone to error on the part of the cataloger. Let’s suppose we have a person with five identities, and therefore five records, each with four 500s linking to the others. We now discover a sixth identity. If we weren’t following the NACO procedure the cataloger would have to create the new record and also go into all five existing records and add another 500 to each pointing to the new identity. Then when a seventh identity is found (not unheard of), the cataloger creates a new record and must go into all SIX existing records, adding 500s pointing to the new identity. Etc. To me this winds up being a more complex procedure than the current policy. Under the current NACO procedure, whenever a new identity is found a record needs to be created for it, but only one existing record needs to be updated, the record for the “basic” identity. In my opinion this is a sensible compromise between convenience of the user and the needs of the cataloger (who are “users”, too!), to say nothing of the likelihood that mistakes will be made.

 

Robert L. Maxwell
Head, Special Collections and Formats Catalog Dept.
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568

"We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued"--Eliza R. Snow, 1842.

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Moore, Richard
Sent: Thursday, June 13, 2013 12:34 AM
To: [log in to unmask]
Subject: Re: RDA relationship designators for pseudonyms in NARs

 

Stephen

 

Thank you for pointing me to this FAQ.

 

It seems the answers are:

 

1.    LC/PCC policy suggests that if Sw I $r is used instead of $w nnnc, then 663 should not be used. I now find a link to this in LC-PCC-PS for 30.1.1.3.

 

2.    In the case of unused real names we are asked to record the unused name in 400 and not use relationship designators. Here I tend to agree with what John Hostage says about the limitations of MARC. Whether to record in 400 or 500 is a bit of a false dichotomy.

 

3.    The FAQ says to use “old” $w nnnc and 663 practice and basic headings for multiple pseudonyms.

 

I agree with what you say anout suppressing 500s. Our systems never did this anyway.

 

The FAQ preserves a lot of AACR2 and LCRI practices, and I’d like to see it reviewed so we can move to fuller implementation of the App K relationship designators:

 

1.    I’d like to be able to record “Explanation of relationship” (30.2.1) in 663, “if considered important for identification or clarification”, when $r relationship designators have been used in 500 instead of $w nnnc.

 

2.    I’d like to be able to use $r alternate identity in the 400 for an unused real name.

 

3.    I’d like to be able to use relationship designators in NARs for multiple pseudonyms, together with 663, and do away with basic headings.

 

Is this something PCC would be willing to discuss?

 

Regards

Richard

 

_________________________

Richard Moore

Authority Control Team Manager

The British Library

                                                         

Tel.: +44 (0)1937 546806                      

E-mail: [log in to unmask]                            

 

 

 

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: 12 June 2013 16:45
To: [log in to unmask]
Subject: Re: [PCCLIST] RDA relationship designators for pseudonyms in NARs

 

Responding to 1. re the use of $w nnnc on 500s in cases of pseudonyms: DCM Z1 points to a document titled "FAQ--LC/PCC RDA and AACR2 practice for creating NARs for persons who use pseudonyms" ( http://www.loc.gov/catdir/cpso/pseud.pdf ), which says among other things:

 

Q5. Can the 663 note be used without coding the 500 field with subfield $w nnnc? (MARC 21 Format for Authority Records, 663 field)

A5. No, the 663 note must have a corresponding 500 field (see-also reference) with a subfield $w coded nnnc. The subfield $w should only be used in the see-also reference (500 field) of a NAR that contains a 663 note.

 

So whether $w r and $i are used is a separate question not affecting the instruction to suppress the 500s with $w ?nnc.

 

Still, the suppression of the 500 references has always been a dubious practice.  The 500 reference appears as a See Also access point; the 663 appears as a note attached to the 100's access point. By suppressing the 500, we make it more difficult for users to find works by the person they're seeking if they search with an alternate name. Indexing the names in $b's from the 663 might help with this, but the fact that the name in $b lacks the subfielding the corresponding 100 would have could be problematic; and I haven't seen a system that does it. If we let the 500s display, then the complex reference information in the 663 would be available to users searching with any of the name variants. It could also mean that a 500 would index when no bib usage for that heading appears in my catalog, but I'd be OK with that, given that the 500 would connect users to something I do have.

 

Stephen

 

 

On Wed, Jun 12, 2013 at 3:06 AM, Moore, Richard <[log in to unmask]> wrote:

Three questions:

1. 500 $w nnnc and 663

When making simple see-also references between real names and pseudonyms, where multiple names are concerned we would (formerly) code the 500 fields $w nnnc (suppressed, in theory), and use 663.

I assume, rightly or wrongly, that we would not use $w nnnc with 500 fields containing the RDA App K relationship designators "real identity" and "alternate identity", but would still (usefully) record a 663, as this maps to RDA 30.2.

Old practice (for a joint pseudonym):

1001 |a Hampton, Peter
5001 |w nnnc |a Franks, Peter
5001 |w nnnc Moore, Simon
663   |a Pseudonym used by Peter Franks and Simon Moore, For works by these authors under their own names, search also under: |b Franks, Peter; |b Moore, Simon

RDA practice:

1001 |a Hampton, Peter
5001 |w r |i real identity |a Franks, Peter
5001 |w r |i real identity |a Moore, Simon
663   |a Pseudonym used by Peter Franks and Simon Moore, For works by these authors under their own names, search also under: |b Franks, Peter; |b Moore, Simon

Is this correct?

2. Unused real names

It also occurs to me that, in order to use these relationship designators at all in LC/NAF, between names, there needs to be an authorised access point and a NAR for all names, even if there are only two names. Does this mean we need to review the practice of treating the unused real name of one pseudonym as a 400?

Old practice:

1001 |a Shute, Nevil, |d 1899-1960
4001 |a Norway, Nevil Shute, |d 1899-1960

RDA practice:

1001 |a Shute, Nevil, |d 1899-1960
5001 |w r |i real identity |a Norway, Nevil Shute, |d 1899-1960

1001 |a Norway, Nevil Shute, |d 1899-1960
5001 |w r |i alternate identity |a Shute, Nevil, |d 1899-1960

Has PCC considered this point?

3. List names

Do we still use list names, or should we now refer from each name to every other?

Many thanks for any observations.

Regards
Richard


_________________________
Richard Moore
Authority Control Team Manager
The British Library

Tel.: +44 (0)1937 546806
E-mail: [log in to unmask]



**************************************************************************
Experience the British Library online at http://www.bl.uk/

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

Help the British Library conserve the world's knowledge. Adopt a Book. http://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 mailto:[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



 

--

Stephen Hearn, Metadata Strategist

Technical Services, University Libraries

University of Minnesota

160 Wilson Library

309 19th Avenue South

Minneapolis, MN 55455

Ph: 612-625-2328

Fx: 612-625-3428

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

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