Authority record duplicating fields

[Steve Callender]

I've tested this in the 2.6 release. 2.6.0 and 2.6.1 to be specific.

This is a strange one. As an example I was using tag 650 to test, which is controlled by tag 150 in the LoC control set.

I added an subfields a, z and z. (Two subfields z) and I used it to create a new authority record.

Now when using it, and applying the full authority record to the 650 tag on a bib record, it works fine. It creates the a, z, and z and adds in the 0 as expected. However, if I already have two z subfields in the bib before I apply the full authority record with the authoritive z fields, it duplicates both z fields.

For example, I have an authority that says,

650 a:One z:Two z:Three

My marc record currently has this as the 650 tag,

650 a:One z:Dee z:Daa

I right click on the "One" and I select my new authority record, and apply full record. It changes it to,

650 a:One z:Three z:Three

Now if I was to remove both z subfields and apply full with only the a subfield left, than it works correctly and populates the authority correctly. If I do it twice in a row, it again replaces both z subfields with the same text.

[Galen Charlton (gmc)]

Also affects Evergreen master.

applyAuthority() in marcedit.js arguably is trying to be a little too fancy, particularly when applying a full heading. It tries to merge the subfields of the heading in the bib record and the heading coming from the authority record, but doesn't handle repeating subdivision subfields well.

Ideas for better behavior:

- If the existing bib heading and the authority heading are identical with the exception of the $0, just add/update the $0 and indicator values

- If the existing bib heading and authority heading do *not* match, simply completely replace the entire bib heading with the authority heading.

However, that second behavior would have the undesirable effect of removing any relator terms/codes that the cataloger may have entered, so special handling of the $4 and $e might be nice.

[Jane Sandberg (sandbergja)]

I like the better behavior that you proposed, Galen. I agree that removing relator terms and codes would be undesirable. The other catch is that there is often a comma preceding a relator term in a previous subfield. For example, in the field:

100 1_ $aAnzaldúa, Gloria, $e author

I wouldn't want the $e to disappear, and I also wouldn't want the "," after Gloria to disappear.

[Jane Sandberg (sandbergja)]

Now that I think about it, there are other subfields that would probably need to be preserved. LCSH -- which is used by most Evergreen libraries -- does not include most subdivisions for its subject headings. A cataloger would probably be unhappy if they were to type out:

650 _0 $aHiking $zOregon $zBadger Creek Wilderness $vGuidebooks.

And have it be replaced by the closest authorized heading that is likely to be in their authority file:

650 _0 $aHiking.