Since I moderated the undifferentiated personal names discussion at the PCC Participants Meeting on June 24, I may not be the best person to provide a summary, but I will try.  I focused on process, and did not take detailed written notes.  The following comments are my personal reflection, not an official response by the PCC.

 

There was a good turnout for the meeting—approximately 150-175 people, and the meeting lasted the full 90 minutes.  I opened the meeting with a brief description of the process so far (the preparation of a discussion paper by John Riemer and Phil Schreur; comments received by Library of Congress staff; and recognition that undifferentiated personal name records occupy less than 1% of the NAF, totaling approximately 58,000 records).  This open forum at ALA marked the closing of the comment period, and PCC Policy Committee members were present to listen to the community reaction.  In mid-July, the Policy Committee will have a conference call to make a decision and identify the next steps.  The outcomes of that call will be shared via PCCLIST.

 

Paul Frank from the Library of Congress then summarized the sense of the online comments that were received at LC.  He approached this from a statistical point-of-view; 60% of the respondents favored breaking apart these records.  An additional 13% were in favor, with qualification or cautionary notes.  The remainder were evenly divided between saying more study was needed and opposition.

 

We then very briefly heard from five people representing communities that are key stakeholders.  Thom Hickey (OCLC Research) spoke about the impact of these records on VIAF; he has posted some of his thoughts on his blog.  Karen Anderson (Backstage Library Works) described the value of working with identifiers rather than strings (a recurring theme throughout the later discussion).  Sarah Elman (Columbia University) spoke on behalf of the CJK NACO funnel and CEAL community, who are greatly affected by undifferentiated records for transliterated names which could be differentiated by their original script characters.  Should the decision be made to break these records apart, this community is very willing to assist.  Georgia Fujikawa (SkyRiver) said that her company does not want to stand in the way of a decision either way.  Berit Nelson (Sirsi/Dynix) provided a thoughtful précis about the impact on local library systems.  Sirsi/Dynix supports breaking apart the records, but noted that doing so would require changes to the underlying software.  It would be critical to understand the return on investment in order to undertake doing this, especially for a small percentage of records, and especially for legacy systems.  She recommended focusing on the future and defining the benefits in that context, which could justify the effort in making these coding changes. 

 

The microphone was then opened to the room at large.  Although we began by asking if there were compelling reasons to keep the records as is, discussion quickly veered into implementation issues.  While I cannot recall any substantive arguments against breaking apart these records, there were many concerns voiced about how record breakup might be handled.  One of the major concerns was workload, especially for libraries with few staff.  Opinions were raised about how much would be manual work and how much work could be automated (and how); how much research on individual headings/identities would need to be done; whether existing record numbers would be preserved (and used for one of the headings) or deleted; and how corrections to (and connections to the correct) bibliographic headings would be managed.  The idea of crowdsourcing was raised as a possible solution to the bibliographic maintenance problem.  Another concern focused on precision needed for this kind of work—could broken-apart records be trusted, and would errors in them be more difficult to correct? 

 

Concerns were expressed about putting these changed records through the pipeline and the downstream effects.  It was noted that—if we broke apart undifferentiated names into multiple headings with identical strings—most ILSs would treat them the same way they treat the current “composite” undifferentiated name records (i.e., ignore them).  In that case, we’re no worse off to split the headings into separate records, and can worry later about how to resolve the issue of making them unique.

 

It was pointed out that implementation could be for new records only, with a project in the retrospective file planned and managed separately.

 

There was some discussion about whether a unique string would be needed for indexing and display (in other words, would more latitude with qualifiers be necessary), or could differentiation be accomplished through identifiers (thus linking to a unique authority record).  There seemed to be agreement that we should be moving in the direction of identifiers, but that we might not be there yet.  In the absence of unique heading strings, perhaps the indexing and display of 37X fields could enable users to distinguish and select the desired entity.  There was a concern about the sensitivity of some information that might be used to create unique strings. 

 

There seemed to be a sense among the group (at least among those who spoke, and many people did speak) that, while this is a complex problem affecting a very small group of records, the benefits from resolving it are far wider.  Doing this kind of work would push us in a direction that would further improve machine processing, and (with the new 3xx elements) would allow for more customized access point displays, resulting in a more effective user interface.  One concern was expressed that if we didn’t move with the future, we would be left behind and ignored.

 

My thanks to John Riemer and Phil Schreur for refreshing my memory on several of the above points.  And thanks to the many people interested in this issue who raised their voices at this session. --  Linda

 

Linda Barnhart

Head, Metadata Services Department

UC San Diego Libraries

858-534-6759

[log in to unmask]