Print

Print


I was tempted to try to create a duplicate record, to prove I wouldn’t get a warning, but didn’t want to make trouble J

 

I do admit to having done so accidentally in the past, and was saved from the embarrassment of reporting it to LC by these instructions at:

 

http://www.loc.gov/aba/pcc/naco/bfmguide.html#duplicate

 

3. Duplicate name heading reporting

OCLC also sends to LC an error report identifying duplicate headings in the authority database, allowing LC staff to resolve conflicts and to maintain affected bibliographic records. As of result, exact duplicates do not need to be reported to LC. However, logical duplicates for the same entity that use different 1XX forms do still need to be reported to LC.

I would be very happy to be informed of any advances of technology that provide a more efficient way of avoiding duplicates.

 

Amy

 

 

 

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Ian Fairclough
Sent: Thursday, August 25, 2016 6:03 PM
To: [log in to unmask]
Subject: [PCCLIST] prohibitive warning

 

PCCLIST readers:

 

In my post with subject " T.J. Winter is Abdal Hakim Murad" I mentioned that the action did not prompt a prohibitive warning that the data in field 100 of  nr 94042948. (Murad, Abdal Hakim) normalizes to a 400 field in n  92084331 (Winter, T. J.).  To which Amy Turner responded, "Does this ever happen?  I can’t recall seeing such a warning and thought it was up to the cataloger to search  both access points and variants thoroughly to prevent duplication." 

 

I apologize for introducing what turned out to be a red herring in the discussion!  No such duplication actually exists in the situation I was addressing - though it looked suspiciously like it might.  And had there been an attempt at such duplication by provision of a 400 field which was indeed called for, the situation that now needs to be addressed might have been avoided.

 

However, concerning the prohibitive warning: I have encounted such, if not with a 100/400 conflict between NARs then between two NARs having the same 100 field,  not as a consequence of a failure to search, but in an attempt to address an undifferentated NAR.  The AAP in the new unqualified NAR conflicted with the existing undifferented one that was to be reported for deletion.  So I couldn't create a new NAR in this case.  I don't recall how this was resolved (probably by adding a qualifier, which LC doesn't always do in such cases).  But the point is, that Connexion didn't allow the conflict to be created between two NARs with identical AAPs.  And in my opinion, it should also prevent creation of a conflict between an AAP in one NAR and a VAP in another.  If Connexion (or any other system) doesn't warn about a 100/400 conflict, perhaps it can be upgraded to do so.

 

Sincerely - Ian

 

Ian Fairclough

Cataloging and Metadata Services Librarian

George Mason University

703-993-2938

[log in to unmask]