authority control - merge and other issues

[George Duimovich]

EG 2.0.8
PG 9
OpenSRF 2.0

We can reproduce the following issues on the community 2.0.9 test server located at http://75.101.133.94

1) Merge two authority records. Merge is completed. But if the bib record implicated includes BOTH merge master and merge target values in, say, 650, you get two identical entries:

http://75.101.133.94/opac/en-US/skin/default/xml/rdetail.xml?r=14460

650 0. ‡0(CONS)10 ‡aShipwrecks ‡zAegean Sea.
650 0. ‡0(CONS)10 ‡aShipwrecks ‡zAegean Sea. [Formerly the merge target; was different value]

2) Duplicate authorities: I managed to create duplicate authorities for value "Shipwrecks Aegean Sea" (viewable in Manage Authorities). I thought this wasn't permitted? -- The two records differ in that id = 10 has 040 set to "CONS" but id = 70 is set to "Set cat.marc_control_number_identifier in Library Settings" --

Other issues:

a) Messaging -- when modifying an authority record (eg changing heading or merging auths) linked bibiliographic records are auto-updated. The message should be more explicit as to whether any related bib records were updated. Right now it just says "Record saved" when modifying an authority, but bibs were modified too (so maybe we should see something like: "Authority record saved, and X bibliographic records updated" -- I think it's fairly important to note if any bibs were auto-updated.

b) The automated authority record linking script puts the |0 link ID at the end position of the tag. Don't know what most prefer or what's standard practice, but this makes sense to me and is our cataloger's preference. But auto updates to bibs re-position the |0 value at the beginning of the tag.

c) "Create immediately" a bit confusing without messaging or something noticeable happening (or maybe this is a training only issue?) You can create a new authority entry by using "create immediately" but I don't see any system response, and not sure why you would "create immediately" and not want a link made? (new authority record entry is there) So perhaps message should at least confirm that authority "record created successfully"

[Jason Stephenson (jstephenson)]

Needs confirmation in 2.1+.

[George Duimovich (george-duimovich)]

Tested and confirmed the following in 2.2.0 / OpenSRF 2.1.0

1) Regarding duplication following Auth record merge

Before merge on record id 8150421

=650 \0$aShipwrecks$0(NRCAN-RNCAN)602196
=650 \0$aWilderness survival$0(NRCAN-RNCAN)550211
=650 \0$aUnderwater exploration$0(NRCAN-RNCAN)603799

I then use Auth Control to merge authorities, using "Underwater exploration" as the "Master" and "Shipwrecks" as the target.

After authority record merge Shipwrecks is gone from Authority list (good, expected)

But when I return to id 8150421 I see:

=650 \0$0(NRCAN-RNCAN)603799$aUnderwater exploration
=650 \0$aWilderness survival$0(NRCAN-RNCAN)550211
=650 \0$0(NRCAN-RNCAN)603799$aUnderwater exploration

Side note: The record counts don't display following subsequent searches in Authority Control. Even if I open a new tab, re-clear the cache, or in this case, also exit and return to staff client I no longer see the auth-bib link counts for each row.

Messaging comment above: save wishlist recommendation. When bibs are touched as a result of Authority work (e.g. auth merging) there should be a message indicating "x bibs have been modified".

b) & c) above in first report also stand in 2.2.0

[Mike Rylander (mrylander)]

George,

Regarding (1) the "doubling" of the headings, you merged 602196 into 603799, as far as I can tell. Headings stand entirely on their own, so the resulting record is expected. The fact that you see the same heading used twice is a side-effect of how the test was set up.

Regarding (2), because import of duplicate authority records from other systems, say, during migration, is so common we were forced to relax that no-duplicates restriction. This may very will be the case in your installation. Once duplicates have been purged from your system a UNIQUE index can be created to make sure that doesn't happen in the future. However, even the 040 difference may be at fault if the record uses a locally defined thesaurus.

Regarding (b), as far as MARC is concerned $0 can live anywhere in the field. I would suggest creating a separate wishlist bug for this.