[DCRM-L] RDA Follow-up to "Cataloging Defensively" Webinar re edition statements

Noble, Richard richard_noble at brown.edu
Mon Nov 15 14:47:21 MST 2010


The difficulty with the supplied edition statement is that it has to be
given in the language of the item--essentially in the form of such an
edition statement as the original *might* have contained. I may be
exaggerating the difficulty of doing so; but in many cases any sort of
conventional designation wouldn't really make sense. On the other hand, I'm
willing to be counselled otherwise--that any sort of statement one can come
up with will at least suffice to prevent a merge, and then you can explain
more fully in the note.

The whole question arose for me in the context of concealed editions, which
in many cases can't be prioritized, so that you need to name the edition in
an unfamiliar tongue, not just number it; and there are languages in which
the cognates of "edition" and equivalents of "issue"have very slippery
meanings--often only designating an invariant impression that would not
require a separate record. Am I looking for the equivalent of serial
"complexity" notes? A "bibliographical relationship complexity" note that
nevertheless is tagged in such a way as to permit automatic merge-blocking.
The real problem is the burying of a fundamental manifestation distinction
in the data structure ("concealed editions" means "concealed in the
catalog") in practice; combined with the difficulty of imitating an edition
statement that doesn't exist.

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 Mon, Nov 15, 2010 at 2:16 PM, Lenore Rouse <rouse at cua.edu> wrote:

>  I'm not sure I understand the need for a new MARC field either. DCRM(G) is
> being written with a view to putting the supplied edition (or state)
> statements (and they're almost always going to be supplied for graphic
> materials) in the 250, but bracketed like any supplied text and with a note
> giving the source of the state (typically a catalogue raisonne). My guess is
> the need for this might not be so apparent in B as it is in G. I would like
> to hear from editors of other modules who might be confronting similar
> problems.
> Lenore
>
>
> On 11/15/2010 1:25 PM, Manon Theroux wrote:
>
>> I wonder how seriously MARBI would take a request for a new field
>> coming from the rare materials community, given that DCRM(B), like
>> DCRB before it, does not allow supplied edition statements; our rare
>> cataloging rules, for the past two decades at least, have always said
>> to put the information in a note. Mightn't MARBI tell us to change our
>> cataloging rules first before coming to them pushing for finer
>> granularity in MARC tagging? Do we want to do that? Could we do that?
>> Do we have a process for amendments to DCRM(B)? So far, we've only
>> done corrections to typos, formatting, and slight changes in wording,
>> nothing that affects the substance of rules.
>>
>> I guess we could point to DCRM(G), which presumably will be published
>> soon, as justification for such a request; I'm curious: is it the only
>> DCRM module to allow supplied edition statements at this point?
>>
>> Even if we were to change our rules, I'm still not sure I understand
>> the need for a new field. If the presence of a 250 field works to
>> prevent record merges, why wouldn't we just put the supplied edition
>> statement in a 250 field?
>>
>> Manon
>>
>> On Mon, Nov 15, 2010 at 12:21 PM, John Attig<jxa16 at psu.edu>  wrote:
>>
>>> We have not investigated this with MARBI, and I learned long ago not to
>>> attempt to predict their reaction to anything, but . . .
>>>
>>> I think that a distinctive MARC field for supplied edition statements
>>> might
>>> be a solution to this problem, but I'm not sure of the scope of the
>>> problem.
>>>
>>> First, RDA to the contrary, is there a general consensus (i.e., beyond
>>> the
>>> DCRM community) that supplied edition statements in the "official"
>>> Edition
>>> Statement element (field 250) are a bad idea?  My sense is that rare
>>> materials catalogers (at least in the DCRM context) are reluctant to
>>> supply
>>> data not present on the item.  However, it is not clear to me that
>>> general
>>> catalogers have the same reluctance.  So is this simply a rare materials
>>> fix?
>>>
>>> Second, is there any reason to restrict this to Edition Statements?  I
>>> could
>>> see the same argument being made for any transcribed data element, and
>>> therefore the potential for a number of other fields for supplied
>>> statements.
>>>
>>> I think that MARBI might be open to adding one or more new fields; it
>>> seems
>>> an obvious extension of the "take what you see" principle that supplied
>>> data
>>> in a transcribed element be distinctly tagged.  However, several points
>>> need
>>> to be clarified before they will see this as a problem that needs to be
>>> solved.
>>>
>>>         John
>>>
>>> On 11/15/2010 12:01 PM, dooleyj wrote:
>>>
>>> I’m interested to know whether the RBMS Bib Standards Committee has
>>> investigated possible MARBI receptiveness, and interest from the
>>> cataloging
>>> community, in a field for supplied edition statements. And given that
>>> there
>>> is growing consensus that MARC is on its last legs, not to mention the
>>> demise of the 503, do you have a sense that a new field is a likely
>>> solution? -Jackie
>>>
>> --
>> Manon Théroux
>> Head of Technical Services
>> U.S. Senate Library
>> SR-B15 Russell Senate Office Building
>> Washington, DC  20510-7112
>>
>
> --
> Lenore M. Rouse
> Curator, Rare Books&  Special Collections
> Adjunct Professor, School of Library and Information Science
> The Catholic University of America
> Room 214, Mullen Library
> 620 Michigan Avenue N.E.
> Washington, D.C. 20064
>
> PHONE: 202 319-5090
> E-MAIL: rouse at cua.edu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20101115/a139b15d/attachment.htm 


More information about the DCRM-L mailing list