Mary Charles, I agree 100% that it would be good to move away from
undifferentiated name records.

Furthermore, if the cataloging rules would allow an author's field of study
in the $c, this would serve as a more useful identifier, for both
catalogers and users, than the additions that are currently authorized.
Imagine index screens that look like this:

Turner, David, economist.
Turner, David, electrical engineer.
Turner, David, political scientist.

Rather than this:

Turner, David, 1945-
Turner, David, 1947-
Turner, David, Ph.D.

As automated authority control improves, retrospective changes to headings
should become easier and easier.   Perhaps the catalogs of the future will
have headings like:

Turner, David  (architect)
Turner, David, 1945-  (electrical engineer)
Turner, David, 1947-  (political scientist)


Amy H. Turner
Monographic Cataloger & Authority Control Coordinator
Duke University Libraries
Durham, NC   27708-0190
[log in to unmask]

             "Lasater, Mary C"                                             
             ANDERBILT.EDU>                                             To 
             Sent by: Program          [log in to unmask]                
             for Cooperative                                            cc 
             <[log in to unmask]>                                     Subject 
                                       Re: [PCCLIST] undifferentiated name 
             11/04/2006 11:33                                              
             Please respond to                                             
                Program for                                                
             <[log in to unmask]>                                             


You have touched on a topic/problem that I hope we can 'do better'
under RDA. I would like to see us move toward using those phrases
that we construct as $c's with the author's name and setting these
authority records up that way. THEN when we find out more about the
author, we can change the 'distinct' AR instead of the 'non-unique
AR if necessary. Several years ago I mentioned in a talk at ALA
that I spend too much time looking for how these have changed and
would prefer not to even have the non-unique AR. With a linked
authority system those changes can be really bad with people
writing books 100s of years before they were born. If instead of
constructing non-unique's we created individual AR's with the
phrases (that we already construct for the non-unique authority
records) and then changed that AR when we have more info, linked
authority system changes would automatically change the 'correct'
authority record, only. Much/all of the time spent looking for the
changed heading that is no longer on the non-unique (Is this the
Tom Smith born in 1952, or 53, or is it Tom T. Smith or Tom Smith,
Ph.D.) would be eliminated.

Music catalogers already get to add these phrases and we see this
type of 'qualification' on various web tools. What are the
disadvantages? Do they outweigh the benefits?

Mary Charles Lasater

--On Friday, November 03, 2006 2:21 PM -0800 "Paul J. Weiss"
<[log in to unmask]> wrote:

> I note that the practice of bracketing data in one 670 per person
> in an undifferentiated name record is not actually given as
> policy anywhere. The MARC authority format give it as one
> possibility ("subfield $a may contain a descriptive term for an
> author enclosed within brackets "). DCM  Z1 touches on it in the
> introduction and at 670. The NACO Participants Manual describes
> the practice, but our NACO reviewer at LC continues to remind me
> that the PM does not set policy.
> Do any of you _not_ follow that practice? If not, what was your
> thinking behind your decision? Have any of you considered some
> other practice?
> Thanks,
> Paul
> UCSD NACO Coordinator
> _______________________________________
> Paul J. Weiss
> Catalog Librarian and NACO Coordinator
> Metadata Services Department
> UCSD Libraries
> 858-534-3537
> [log in to unmask] _______________________________________

Mary Charles Lasater
Vanderbilt University
Email: [log in to unmask]