I think Ralph Papakhian's note had a perfect example of a really
public note. The 680 could be used to provide a brief biographical
summary that could be displayed in the opac if you wanted (and your
system allowed it), for example: Bernstein, Leonard, 1918- Composer,
conductor, and pianist. Dates: 1918-1990
The 670s and 675s give the information in shorthand and not
necessarily in a single source.
Sherman Clarke, NYU - [log in to unmask]
> Date: Thu, 3 Feb 2000 11:29:46 -0500
> Reply-to: Program for Cooperative Cataloging <[log in to unmask]>
> From: Joan C Biella <[log in to unmask]>
> Subject: Re: 667 vs. 680
> To: [log in to unmask]
> 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
> > 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
> discussion has migrated away from converting non-public *fields* to
> fields, to putting certain kinds of information (beyond death dates,
> 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
> 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
> > 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
> note, we may not be talking about adding anything to NAR
> that is, the initial creation of an authority record. If the
> use is one of recording death dates, that's a post-creation task that
> not involve the NAR creator at all. If the contents extend to
> descriptors, statements of function, etc., that might be another
> 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
> 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
> participants wanted to create authority records for name-title
> 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
> from NMP participants. LC eventually changed course with their
> OCLC MDAR project, creating thousands of such records themselves
> 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
> death dates and the like would have on catalog use. Then we can
> about what impact it might have on catalog creation and maintenance.
> There's been little discussion thus far about displaying this
> If this idea does gain some momentum, vendors should be put on notice
> 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]