Ruta: Doesn't BIBCO Op have a system whereby people accept
responsibility for addressing particular quality concerns. If so, the
record in question should be referred to the person currently performing
that function. Also, a reminder should be issued to PCCLIST and AUTOCAT
as to how to deal with questionable records via this mechanism. John
Margaretta Yarborough wrote:
>
> The RLIN angle would have solved the mystery neatly, but in this case the
> offending record was indeed an OCLC record, input by a BIBCO library last
> January. We've already input the NACO record, minus any reference to the
> PCC record, and I'm only waiting on the 005 field to show up before I let
> the library in question know, for information only, that we've added it.
> (So if you see email from me in your inbox, run!!) It seemed much simpler
> (barring this discussion, of course) for the cataloger here to input the
> record rather than having to pitch her work and have someone at another
> institution reinvent the wheel. But as I noted earlier, if we'd at all
> disagreed with the form, we would have done just that.
>
> mjy
> ____________________________________________________________________
> Margaretta Yarborough [log in to unmask]
> Monographic Cataloging
> Davis Library CB# 3914
> UNC-CH (919) 962-9693
> Chapel Hill, NC 27514-8890 fax (919) 962-4450
>
> On Mon, 12 Jul 1999, Robert Maxwell wrote:
>
> > There is one point that has not been brought out in this thread, and that
> > is that the record in question may not have been a PCC record at all, if it
> > was found in RLIN. An RLIN PCC record (A), when derived by a non-PCC
> > library (B), does not lose its 042 PCC designation (or the fixed field
> > code) unless the deriving library manually removes it. Then the deriving
> > non-PCC library (B) might change the access points in the record, or add
> > access points without doing NACO work. Therefore when a cataloger in
> > library C spots an RLIN cluster containing, now, at least two PCC records,
> > he/she might not pick the "real" PCC record to derive from; if the "PCC"
> > record from library B is chosen, that record will contain headings not
> > reflected in the NAF.
> >
> > This is NOT simply a hypothetical situation. We are encountering it more
> > and more frequently as the BIBCO program progresses, and have concluded
> > that records marked "PCC" found on RLIN (i.e., our universe of findable
> > records, we being an RLIN library), while likely to be correct and have all
> > the authority work done, cannot in fact be taken at face value; we have to
> > check the authority anyway, because the "PCC" record chosen might not
> > actually have been created by a PCC library. We have taken this up with
> > RLIN and they seem unable to deal with the problem.
> >
> > This is one reason I have proposed before the possibility of a database of
> > PCC records similar to the NAF, which would be shared by both the utilities
> > (another problem with the BIBCO database as it now exists is that the RLIN
> > database of PCC records is quite different from the OCLC database of PCC
> > records since there is little sharing of PCC records between the two).
> > Records derived from this database would no longer be coded PCC in RLIN,
> > but would look like any other record in an RLIN cluster. The "master" (to
> > borrow OCLC terminology) PCC record in the cluster could stand alone and
> > should be updatable by any PCC library (and then forwarded to the shared
> > database, just as updates to NACO records are).
> >
> > Bob Maxwell
> >
> > At 09:12 AM 7/9/99 -0700, you wrote:
> > >Margaretta,
> > > Agreed, point well taken, etc. I would also hope that this
> > >situation simply does not arise again. But I would just like to
> > >suggest a possible different approach to this: rather than ignore the
> > >existence of the PCC record, contact the PCC liaison at the institution
> > >(from the 040 of the bib record) and (somehow nicely) request that they
> > >finish the work that they started... Neither your institution nor any
> > >other should take up the slack for this "unfinished business" (IMO).
> > > --Jain Fletcher, UCLA
> > >
> > >On Fri, 9 Jul 1999 11:42:51 +0600 Margaretta Yarborough
> > ><[log in to unmask]> wrote:
> > >
> > >> Point well taken, which is why this hasn't been a hot topic. The fact
> > >> remains, however, that this was a PCC record we encountered (minus an
> > >> accompanying AR), for which we are supplying the missing authority record.
> > >> Perhaps the best policy would be to ignore the BIBCO record's existence
> > >> entirely in creating the NACO record!
> > >>
> > >> mjy
> > >>
> > >> ____________________________________________________________________
> > >> Margaretta Yarborough [log in to unmask]
> > >> Monographic Cataloging
> > >> Davis Library CB# 3914
> > >> UNC-CH (919) 962-9693
> > >> Chapel Hill, NC 27514-8890 fax (919) 962-4450
> > >>
> > >> On Fri, 9 Jul 1999, A. Ralph Papakhian wrote:
> > >>
> > >> > hi,
> > >> > why would a pcc record require a new naco record?
> > >> > i had thought that the primary defining feature of a
> > >> > pcc record was that all authority work had been accomplished.
> > >> > --r
> > >> > A. Ralph Papakhian, Indiana University Music Library
> > >> > Bloomington, IN 47405 812/855-2970 [log in to unmask]
> > >> > co-owner: [log in to unmask]
> > >
> > >Jain Fletcher
> > >Head, Monographic Cataloging Section
> > >Research Library - UCLA
> > >
> > >
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > Robert L. Maxwell
> > Special Collections and Ancient Languages Cataloger
> > 6428 Harold B. Lee Library
> > Brigham Young University
> > Provo, UT 84602
> > (801) 378-5568
> > [log in to unmask]
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
--
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ John D. Byrum, Jr. ^^
^^ Chief, Regional & Cooperative Cataloging Division ^^
^^ Library of Congress LM-535 ^^
^^ Washington, D.C. 20540-4380 LL ^^
^^ LL CCC ^^
^^ (202) 707-6511 LL CC CC ^^
^^ FAX (202) 707-2824 LLLLLLLL ^^
^^ CC CC ^^
^^ [log in to unmask] CCC ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|