[DCRM-L] 8vo: another mass update gone awry?

[Noah Sheola]

I've been wondering about this as well. I've seen *a lot* of these over the
last month or so, and I share Bob's concern. The common feature I have
discerned for many (possibly all?) is a British Library Group Batchload.
Also, even in records where the  "340 ǂm 8vo" might be appropriate, I don't
believe the ǂm should end with a period, as do all of the records with this
issue I have seen.
Regards,
Noah

On Fri, Jan 25, 2019 at 11:15 AM Robert Steele <rosteele at law.gwu.edu> wrote:

> I apologize for posting to multiple lists.
>
> I have been noticing non-DCRM(B) records in OCLC with a bibliographic
> format field (340  ǂm 8vo. ǂ2 rdabf). For anyone not familiar with it, the
> rdabf tag refers to the RDA Bibliographic Format registry  (rdabf:
> https://www.rdaregistry.info/termList/bookFormat/)
>
> Unfortunately, in many cases these are books from the machine-made era.
> Here is an example from 1863: OCLC 14985739. The definition of 8vo in the
> Registry is, as it should be: "A bibliographic format consisting of one or
> more leaves that are 1/8 of the whole sheet," and of course, the size of
> the original sheet is very difficult to ascertain in a book produced in
> 1863 on machine-made paper.
>
> The records I have found so far are lacking a 300 $$c subfield. They also
> were originally entered into OCLC decades ago, but were recently updated.
> My guess is somebody decided to strip 8vo from the end of 300 and move it
> to an rda field. Unfortunately, they failed to consider that many older
> records used 8vo as a general indicator of size, and not as "Bibliographic
> Format" as defined in the registry, so we end up with records with missing
> and erroneous information.
>
> I'll be fixing this one soon, but I wonder how many there are.
>
> Bob Steele
> Cataloging Librarian
> Jacob Burns Law Library
> George Washington University
>


-- 
Noah Sheola
Special Collections Cataloging Librarian
John J. Burns Library
Boston College
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20190125/fa06875e/attachment.html>