LISTSERV mailing list manager LISTSERV 16.0

Help for PCCLIST Archives


PCCLIST Archives

PCCLIST Archives


PCCLIST@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

PCCLIST Home

PCCLIST Home

PCCLIST  February 2000

PCCLIST February 2000

Subject:

Re: 667 vs. 680

From:

"A. Ralph Papakhian" <[log in to unmask]>

Reply-To:

Program for Cooperative Cataloging <[log in to unmask]>

Date:

Thu, 3 Feb 2000 15:20:40 -0500

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (167 lines)

hi,
"public service aid to patrons and staff" is the key.
i once tried to calculate how much time was expended
each year by librarians trying to answer questions from
patrons about open dates in catalogs for individuals who
had died in the ca. 10,000 libraries in the U.S.
it's a tough calculation. one might need the aid
of the los alamos Nirvana super computer.
-r

A. Ralph Papakhian, Indiana University Music Library
Bloomington, IN 47405 812/855-2970 [log in to unmask]
co-owner: [log in to unmask]

On Thu, 3 Feb 2000, Elizabeth Robinson wrote:

> Speaking for myself, my attraction to the 680 as a public note is that it can be written in plain language and summarize select information you may want to bring out without having to display all that is in the 670s. E.g. say you have the following pair of NARs (which are real, BTW):
>
>  040     CSmH|cCSmH
>  100  10 Allen, Hannah
>  400  10 Allen, Hanna
>  670     The humble answer of the General Councel of officers of the Army, under His Excellencie, Thomas, Lord Fairfax, 1648:|bimprint on t.p. (Hannah Allen; Crowne in Popes-head Alley)
> 670     The Kentish petition: to the Honourable, the Commons now sitting in Parliament, 1648:|bimprint on t.p. (Hanna Allen; Crown in Popes head Alley)
>  670     Plomer, H. Dict. of the booksellers and printers ... 1641 to 1667, 1907|b(Allen, Hannah, bookseller in London; widow of Benjamin Allen; Crown in Pope's Head Alley, 1647-50; last recorded work in Registers is 1650; later married Livewell Chapman)
>
>
>   07 040     CSmH|cCSmH
>  08 100  10 Allen, Benjamin,|dd. 1646
>  09 400  10 Allen, Ben.|q(Benjamin),|dd. 1646
>  10 670     Greenhill, W. Axin{229}e pros t{229}en rhizan, 1643:|bimprint on t.p. (Benjamin Allen; Popes-head Alley)
>  11 670     Lockyer, N. England faithfully watcht with, in her wounds, 1646: |bimprint on t.p. (Ben. Allen; Crown in Popes-head Alley)
>  12 670     Plomer, H. Dict. of the booksellers and printers ... 1641 to 1667, 1907|b(Allen, Benjamin, bookseller and printer in London; 1. the Crown, Popes-Head Alley, 1631-46; took up freedom Jan 12 1631; will dated and proved May 1646)
>
>
> Yes, you could display all these notes to your public, but with a 680 on each, you can display to the public very succinctly select information you may feel is clarifying:
>
> 100 1_ Allen, Hannah
> 680 __ Bookseller; widow of Benjamin Allen (d. 1646)
>
>
> and
>
> 100 1_ Allen, Benjamin, |dd. 1646
> 680 __ Bookseller and printer; succeed by his wife Hannah Allen
>
>
> I'm not suggesting one be required to do this all the time, just per cataloger's judgment -- when you want to make an association between different people or want to bring out the occupation of the person (esp. if the 670s don't make that clear or if you have people with the same or similar name operating in close time periods but who have different occupations). Yes, it is a repetition of info in the 670, but I believe it could be a quick public service aid for both patrons and staff.
>
> --Elizabeth A. Robinson
>   Principal Rare Book Cataloger
>   Huntington Library
>   [log in to unmask]
>
>
>
>
> ----------
> From:   Joan C Biella[SMTP:[log in to unmask]]
> Sent:   Thursday, February 03, 2000 8:29 AM
> To:     [log in to unmask]
> Subject:        Re: 667 vs. 680
>
> I am confused by the direction this discussion is taking, and I DO
> understand A. Franks's point, which seems to me to be that most (if
> not all?) relevant information can be put into public notes, that is,
> 670s and 675s.  Most information does have a source, which can be
> cited--"Info from author's sister, date$b(Jane Blow is widow of Joe
> Blow)"--and doesn't usually arise from the cataloger communing with
> him/herself.  The only truly "private" notes I've run across as a
> Library of Congress cataloger have been on the order of:  "author's
> year of birth  XXXX; do not make this information public until 50
> years after author's death" (I really ran across one like that).  What
> kind of truly "non-public" information are we talking about?
>
> Joan Biella
> Library of Congress
> NOT an official statement
>
> >>> Mark Scharff <[log in to unmask]> 02/03 10:24 AM >>>
> On Thu, 3 Feb 2000, Anthony R. Franks wrote:
>
> > As a purely personal matter of opinion, and not at all reflecting
> the
> > position of the Library of Congress on this matter, I will share
> with you
> > the thought that struck me this morning, in the shower:
> >
> > If information is relevant to the heading, it goes into a 670
> field; if
> > it's not relevant to the heading, it goes into a 675 field.
>
> Uh ... both of these fields are non-public notes, and I think that
> the
> discussion has migrated away from converting non-public *fields* to
> public
> fields, to putting certain kinds of information (beyond death dates,
> not
> yet clearly defined in the discussion) in a public field instead of
> or in
> addition to a non-public field.  The point of Anthony's statement is
> lost
> on me, and I welcome an explanation from someone more clever than I
> (don't hurt yourselves in the mad rush! :-)).
>
> > To paraphrase Judy Kuhagen speaking about another NAR-related
> matter,
> > introducing yet another field and set of tagging into NAR
> production is
> > not cataloging simplification.
> >
>
> Again, depending on what sorts of information are assigned to a
> public
> note, we may not be talking about adding anything to NAR
> *production*,
> that is, the initial creation of an authority record.  If the
> principal
> use is one of recording death dates, that's a post-creation task that
> need
> not involve the NAR creator at all.  If the contents extend to
> descriptors, statements of function, etc., that might be another
> matter;
> even at that, it would be unlikely that there would be a perceived
> need to
> provide this for every heading.
>
> Understanding that Anthony was speaking for himself, I hear his
> comments
> reflect what seems to be a common LC attitude toward the cooperative
> projects: a reluctance to allow participants to do something that LC
> itself does not want to do.  This was true in the NACO Music Project
> when
> participants wanted to create authority records for name-title
> headings
> that didn't require cross-references; because this ran counter to LC
> practice, it took no little amount of persuading to get LC to allow
> it
> from NMP participants.  LC eventually changed course with their
> OCLC MDAR project, creating thousands of such records themselves
> because
> it finally suited their purposes.
>
> I hope there will be more discussion of this idea among various
> constituencies, with some input from those who deal with catalog
> users and
> are in a position to know what impact adding public information
> about
> death dates and the like would have on catalog use.  Then we can
> worry
> about what impact it might have on catalog creation and maintenance.
>
> There's been little discussion thus far about displaying this
> information.
> If this idea does gain some momentum, vendors should be put on notice
> that
> their customers expect them to provide for display.  Some vendors
> can't or
> won't display public fields that are already present.
>
> OK -- enough rabble-rousing for one message.
>
> Mark Scharff, Music Cataloger
> Gaylord Music Library
> Washington University in St. Louis
> [log in to unmask]
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager