[DCRB-L] MARC format change proposal: repeatability of 260 $e,f,g

John Attig dcrb-l@lib.byu.edu
Mon, 11 Aug 2003 17:37:10 -0400


<html>
<br>
As the Committee is being asked to vote, I'll indicate what I think
should be done. <br><br>
At 02:53 PM 8/11/2003, Manon Theroux wrote:<br>
<blockquote type=cite class=cite cite>John,<br><br>
Here are some additional comments (sorry to make them so close to your
original Aug. 15 deadline!):<br><br>
1) 1st paragraph, sentence beginning &quot;The rule calls
for&quot;<br><br>
Should we cite the rule number(s) here and specify that we are talking
about AACR2 (or doesn't MARBI really care...)?</blockquote><br>
Not worth the effort; they do not -- and should not -- care.<br><br>
<blockquote type=cite class=cite cite>2) 1st paragraph, last sentence:
&quot;Even when given, it is highly unusual for there to be more than one
set of subfields needed.&quot;<br><br>
For 19th-century materials, I would not say it is NOT highly unusual for
there to be more than one set of subfields needed. It is extremely
common. Any library with 19th-cent. materials that is exercising the
AACR2 option to transcribe manufacturing information in the
&quot;Publication, Distribution, Etc., Area&quot; definitely needs the
subfields repeatable. Not very many libraries have consistently exercised
this option, but that is a different matter and one you already touch
upon in the preceding sentence.<br><br>
I think I would would either delete this sentence or replace it with one
emphasizing that those libraries choosing to exercise the AACR2 option
are not currently able to so for 19th-cent materials according to
existing MARC standards. This proposal really goes beyond
DCRB.</blockquote><br>
I was trying to convey that the case arises only when (a) there is
manufacture information to be recorded, (b) there is more than one
manufacturer, AND (c) there is more than one place of manufacture [if
not, a single $f would suffice]. I think those cases are statistically
unusual. However, the point isn't worth insisting on.<br><br>
I suggest accepting Manon's suggestion to replace the sentence.<br><br>
<blockquote type=cite class=cite cite>3) 1st example<br><br>
Need a mark of punctuation between the two $f subfields - right now they
are separated by a mark of omission only.</blockquote><br>
Agreed.<br><br>
<blockquote type=cite class=cite cite>4) 2nd example<br><br>
&quot;co.&quot; should be &quot;Co.&quot; and &quot;Sergent&quot; should
be &quot;Sargent&quot;</blockquote><br>
Agreed.<br><br>
<blockquote type=cite class=cite cite>5) These examples are actually
taken from AACR2 records not DCRB records ... should I retrieve the
actual books and see what the exact DCRB transcriptions would be or are
we treating these as hypothetical examples only?</blockquote><br>
These examples may eventually appear in the MARC documentation, so it
would be a good idea to follow DCRB (or what we expect DCRB will say?).
If you can find some books and do the full transcription of the 260
field, that would be helpful. Or we could wait until the proposal is
approved. The present examples are sufficient to illustrate the point of
our proposal. We can submit examples for the MARC documentation
later.<br><br>
<blockquote type=cite class=cite cite>6) Neither of the examples includes
a repeated $g. I'm not sure if this is a problem but I thought I would
point it out.</blockquote><br>
I noticed that, but didn't feel it would be a problem; I doubt that we
will have troubles convincing them to treat all 3 subfields consistently
even without examples. On the other hand, if we had an example . .
.<br><br>
<blockquote type=cite class=cite cite>7) Final paragraph: &quot;The
revised DCRB will call for ...&quot;<br><br>
I seem to recall some disagreement on the Bib Standards Committee as to
whether we should transcribe all manufacturing information in the 260
field (no matter where in the publication it appears) or do so only when
it appears on the chief source (transcribing data that appears elsewhere
in a note). Since the revised DCRB rules are still in their
&quot;alpha&quot; form, do you think we should soften this wording to
allow us &quot;wiggle-room&quot;? Something like: &quot;Current drafts of
the revised DCRB call for ...&quot;&nbsp; ? Or doesn't it
matter...</blockquote><br>
Isn't it a really really good bet that the DCRM(B) rules will call for
transcribing the manufacture information in the 260 field <b>in some
cases</b><i>. </i>The fact that it may not do so in every case (or even
in the cases of the examples we submit) is something that can be our
little secret.<br><br>
<blockquote type=cite class=cite cite>8) Attachment, first
question<br><br>
Form has typo &quot;guildine&quot; - we might want to point this out to
the appropriate person/group.</blockquote><br>
Noted.<br><br>
<blockquote type=cite class=cite cite>9) Attachment, answer to second
question<br><br>
Add the following as a second group that would be affected by the
change?:<br><br>
Catalogers of 19th-century machine-press books applying the AACR2 option
to routinely include manufacturing data in the &quot;Publication,
Distribution, Etc., Area&quot;</blockquote><br>
Agreed.<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>&nbsp;&nbsp;
Before you send the proposal forward, one more typo: 10.
&quot;Miniscule&quot; should<br>
be &quot;Minuscule,&quot; I believe.</blockquote></blockquote><br>
I'll either correct the spelling or find a word I know how to
spell.<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>&nbsp;&nbsp;
One thing I worry about is the impact that this might have on
catalogers<br>
using AACR2.&nbsp; Will people take advantage of the format, and is this
a problem?<br>
On the other hand, I could see how catalogers of visual materials might
find it<br>
useful.</blockquote></blockquote><br>
We always tell people that you apply the rules before you apply the MARC
coding, i.e., that you don't repeat something unless the RULES tell you
to do so . . . however, I agree that some catalogers don't seem to be
listening.&nbsp; I've decided that this is their problem and that it
shouldn't stop us from doing what is needed.<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>John<br><br>
</html>