[DCRM-L] FW: Slides and Recording from Nov. 1 "When to Input a New Record" Webinar
Noble, Richard
richard_noble at brown.edu
Wed Nov 3 08:33:13 MDT 2010
Thanks, Jackie. But it's more than "Hmm". It is most peculiar that DCRM(B),
concerned as it is with the direct representation of evidence that, among
other things, distinguishes editions; and now RDA, concerned (at least as
its creators profess it to be) with the usefulness of metadata across the
boundaries of various activities, should so utterly frustrate our
ability--anybody's ability--to ensure that recognition of fundamental entity
distinctions should be easily programmable in so basic a database process as
de-duping.
Jay said up front that the *best* way to protect a record against false
de-duping is to add a 250.* Dupes are a scourge--the body of pre-1801
records is now hopelessly infected with them--but at least they are for the
most part available for inspection in the result set of a sufficiently broad
search. False merges are infinitely worse: unrecognizable without an "item
in hand" (and, even with one, seldom recognizable) and all but impossible to
reverse. (How does one re-assign correct holdings to a record or records
resurrected from the limbo of 019?)
If the makers of RDA prove resistant to further change, is there not a role
for OCLC to provide for effective "defensive cataloging" by way of its own
bibliographic standards? It seems to matter to the folks in Quality Control,
and I don't see why they should have to throw up their hands and say
"Sorry--you're defenseless."
___________________________________
*This is not a MARC-specific problem--in general terms, it's an instance of
functionally inadequate data definition. It is, by the same token, too bad
that the 503 was killed--at least a programmer could have worked with that,
absent the 250. There are, however, unassigned 25X values, one of which
(251?) could be established, if only in the OCLC database, as the
distinctive tag for a supplied edition statement backed up by a note.
Obviously OCLC is reluctant to depart from the "rules"; but it could be said
that there are such things as rules that depart from acceptable standards.
*Obiter dictum*: I have very dark feelings about the mind-set that clearly
regards the minimizing of expertise as the governing imperative for the
creation of metadata. "Cataloger judgment" is what we are supposed to "get
over", along with ourselves. But we are, in this instance at least, talking
about the integrity of the database as an accurate record of bibliographical
entities. What else is it for? Retrospective quality control of metadata
that turns out to be inadequate is a lot harder than quality control in its
creation--i.e. ("in english"): Doing it over is more expensive (and often
less possible) than doing it right in the first place.
RICHARD NOBLE : RARE BOOKS CATALOGER : JOHN HAY LIBRARY : BROWN UNIVERSITY
PROVIDENCE, RI 02912 : 401-863-1187/FAX 863-3384 : RICHARD_NOBLE at BROWN.EDU
On Tue, Nov 2, 2010 at 5:44 PM, dooleyj <dooleyj at oclc.org> wrote:
> Some of you no doubt attended this OCLC webinar yesterday and have
> already received this message. For those who didn’t, Jay Weitz gave an
> overview of how the guidelines for when to input a new record intersect with
> OCLC’s latest de-duping algorithms. While much of the information was quite
> basic, he did touch on some issues particular to rare materials during the
> Q&A—including verifying that no records for pre-1800 imprints are ever
> de-duped.
>
> Lots of questions about supplying edition statements in various contexts,
> in response to which Jay repeatedly noted that RDA doesn’t allow catalogers
> to add ed. Statements in the 250 if they don’t appear on the piece. Putting
> them in a 5xx field won’t get picked up by the de-duping algorithms. Hmm.
>
> --
> Jackie Dooley
> Program Officer
> OCLC Research and the RLG Partnership
>
> 949.492.5060 (work/home) -- Pacific Time
> 949.295.1529 (mobile)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20101103/96b2b257/attachment.htm
More information about the DCRM-L
mailing list