I’m somewhat more concerned that one of those records is $b eng despite looking for all the world like a German record. #1056989349 is coded as English but the only fields that appear to be English are the 336 and 338 fields, which are in turn missing $a. 300, 500, and all subject headings are in German (this, despite the majority of the subject headings being 650 _0.)

I suspect this is the result of an automated process that might need some refining. Since these are both coded level M, that further indicates this as the result of problematic automation. Perhaps we should preserve these records as they are as an example of why we actually need human catalogers!

Regarding the $e rda part of the message, it is my understanding that PCC does not require members to upgrade every record touched to full RDA. Additionally, I’m quite certain the policy governing this states that unless a record is fully converted to RDA, one is not to insert the subfield $e rda. The policy notes that there will be a number of “hybrid” records that will not be coded as RDA but will appear as RDA. I’ve seen a number of these in my cataloging, as I’m sure we all have. That’s not a problem in my book (if we see that a record is fully RDA, we can certainly add the field) but I would say that getting the language of cataloging right is certainly important.

Preston Salisbury

Assistant Professor and Monographic Cataloger

Mississippi State University

(662) 325-4618

[log in to unmask]

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Yang Wang
Sent: Thursday, April 11, 2019 8:24 AM
To: [log in to unmask]
Subject: [PCCLIST] Modified vendor records

 

When a vendor record is touched (read: edited) and submitted to OCLC by a PCC member institution, one would expect to see a decent description of the resource. One would expect, at least, the record to have $b eng and $e rda, even at the minimal or less-than-full level. Is it a fair and reasonable expectation?

Here are two examples I encountered earlier today in OCLC: (OCoLC)on1056989349 and (OCoLC)on1082199020.

In the online catalogs of the two holding libraries that touched the records last, records have been improved to some degree. But why are changes not reflected in OCLC? The LC call numbers are still very broad, however, vendor-assigned by any chance? What is happening to cooperative cataloging?

Yang
https://listserv.loc.gov/cgi-bin/wa?A3=ind1904&L=PCCLIST&E=quoted-printable&P=2101273&B=--_000_BN6PR01MB27220BBF1CACBD8595FAE3F6902F0BN6PR01MB2722prod_&T=text%2Fhtml;%20charset=us-ascii
listserv.loc.gov
crawl=CC-MAIN-2022-33
6857
application/http; msgtype=response
sha1:XZ6O6XBA6362QVDXBH6MJGIKAI6A3LNO
<urn:uuid:311f0338-07d8-460a-ad1e-6ce69e1a3792>
2022-08-12T09:24:19Z
140.147.239.86
text/html
sha1:2TA4FWEV3QYWTLSYLGZ6CC2WQFLK536E
<urn:uuid:93f07b54-617a-4ad0-b9ac-9222dc280bfe>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1904&L=PCCLIST&E=quoted-printable&P=2101273&B=--_000_BN6PR01MB27220BBF1CACBD8595FAE3F6902F0BN6PR01MB2722prod_&T=text%2Fhtml;%20charset=us-ascii
response
<urn:uuid:7b9574b2-490a-4a3c-af23-c21cef07b38a>
isPartOf: CC-MAIN-2022-33
publisher: Common Crawl
description: Wide crawl of the web for August 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-65
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/