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?
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
> the thought that struck me this morning, in the shower:
> If information is relevant to the heading, it goes into a 670
> 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
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
> 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
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
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
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]