Or 1XX/4XX/5XX subfield $h. That particular validation hasn’t been turned on for at least 25 years, and it’s badly needed now under RDA to record content type
in access points. Holdup: LC implementation again (we can’t seem to get the Z1 language forbidding $h rescinded, although I notice today the language has been changed to say “The use of subfield $h for the addition of content type in an authorized or variant
access point is pending at this time”—that’s progress, but it’s been “pending” for several years now.)
Bob
Robert L. Maxwell
Ancient Languages and Special Collections Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568
From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
On Behalf Of Casey Mullin
Sent: Tuesday, March 7, 2017 9:33 AM
To: [log in to unmask]
Subject: Re: repeating the subfield $c in a 111 authority record
Not to mention 382 $e, $r and $t…
________________________________
Casey A. Mullin
Head of Cataloging and Metadata Services
Western Washington University
Chair, Music OCLC Users Group
360-650-7458
From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
On Behalf Of Moore, Richard
Sent: Monday, March 6, 2017 11:19 PM
To: [log in to unmask]
Subject: Re: [PCCLIST] repeating the subfield $c in a 111 authority record
NACO is still waiting for LC to implement the last few MARC 21 updates. 111 $c repeatability isn’t the only thing affected – we are also still using
046 $s and $t with their former definitions, and not using 046 $q and $r.
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 Charles Croissant
Sent: 02 March 2017 18:07
To: [log in to unmask]
Subject: [PCCLIST] repeating the subfield $c in a 111 authority record
Dear collective wisdom,
I've run into a problem in trying to update a conference authority record to RDA. I think the problem is actually with OCLC's validation algorithm, but I'm wondering if others have encountered
this as well, and whether it's a "known problem."
I would like to update NAR no2002013383 to RDA. It's for the Council of Pavia-Siena, a 15th-century church council that took place in two locations.
Applying RDA 11.13.1.8.1, it appears that the RDA heading (expressed in MARC) should be:
111 2_ $a Council of Pavia-Siena $d (1423-1424 : $c Pavia, Italy; $c Siena, Italy)
i.e. with the subfield $c repeated.
According to MARC 21 for Authority Records, subfield $c _is_ repeatable. There's even a statement to this effect in the General Information X11 section:
"Multiple adjacent locations are contained in a repeatable subfield $c."
But when I attempt to validate the heading in OCLC, it fails validation, so I am unable to replace the record.
So I'm wondering, should I remove the second $c and replace the record, or should I wait to replace this record until this validation problem gets fixed?
thanks for any advice,
Charles Croissant
Senior Catalog Librarian
Pius XII Memorial Library
Saint Louis University
St. Louis, MO 63108
******************************************************************************************************************
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