Not sure if this is a mapping or linker problem. Two authors with the same names, but one has a $c - Titles and other words associated with a name $aHarris, Ken $aHarris, Ken $c(Writer on railroads) In this case the linker is linking titles to Ken Harris that should have been linked to Ken Harris (Writer on railroads) because it did not look at the subfields. To further complicate, the only authority record in the system is for Ken Harris. No authority record exists for Ken Harris (writer on railroads). In other words, the linker should not have linked this particular bibliographic record to anything because it did not appropriately match the existing authority of Ken Harris. These settings are in place: LinkerModule: Default LinkerOptions: broader_headings AutoCreateAuthorities: don't generate RequireChoosingExistingAuthority: don't require AuthorityMergeMode: loose
May be related to bug 29577
(In reply to Esther Melander from comment #0) > LinkerOptions: broader_headings That's precisely what broader_headings does: if there's no match for a heading with more than one subfield, it removes the last one until it finds a match or runs out of subfields to remove. As the manual says, "This feature is experimental and shouldn’t be used in a production environment until further expanded upon." The feature has been untouched since it landed in 2012. It would be possible to fix this particular problem by teaching it to not remove subfields in the name portion and name-title portion of https://www.loc.gov/marc/authority/adx00.html but then doing the same for x10 and x11 will be complicated by the way that you can actually have more than one $d or $n, where one is part of the name and one is part of the title in a name-title heading. Perhaps a config file for what subfields may be removed from each bib field (since it would be reasonable to have different choices for 100/600/700/800)? Or, in far fewer lines of code, remove the feature which has been experimental and non-production and untouched for over 13 years.
I ran into another example with a corporate term. In this case these system preferences were enabled. AutoLinkBiblios = on LinkerOptions = broader_headings The terms were: AuthId = 559641 110 $aChurch of Jesus Christ of Latter-Day Saints AuthID = 360524 110 $aChurch of Jesus Christ of Latter-Day Saints $x Presidents Bibliographic records with the first term were incorrectly auto linking to the second term. Attempts were made to manually edit the bibliographic record with the correct authority id $9 559641, but upon saving the authority was relinking to the second term. There may be a second bug in this situation, but it appears that LinkerOptions was interfering with linking to the correct heading because it was ignoring the second subfield $x and just linking to the first available option, which corresponds to AuthID 360524. Since LinkerOptions is clearly interfering with other system preferences and causing anomalous linking, it is probably best to remove this system preference altogether.
That's unlikely to be anything to do with broader_headings, since it only takes effect when the full heading in the bib isn't found in an authority, and it then tries removing subfields from the end until it finds a match or runs out of subfields. Since your problem is with a heading with no subfields, broader_headings won't actually apply. That sounds more like the way my system had an old version of ByWater's default Elasticsearch mappings which included Match-Heading entries, and bug 24269 plus bug 25273 only work to fix the problem of a search for just Church of Jesus Christ of Latter-Day Saints returning a heading that's actually Church of Jesus Christ of Latter-Day Saints -- Presidents if you remove mappings for Match-Heading. With LinkerModule: Default that means both would be returned, and the bib heading wouldn't be linked, but if you have LinkerModule: FirstMatch, then the lower numbered authority, 360524, would be returned. It's not a fun read, but see ByWater ticket 109725 for my struggle out of that exact same problem.
I ran some tests on a test site where LinkerOptions was disabled. LinkerModule was set to first match. AutoLinkBiblios set to Do. I had these authorities: Auth ID=50 110 $aChurch of Jesus Christ of Latter-Day Saints $d Presidents Auth ID=51 110 $aChurch of Jesus Christ of Latter-Day Saints Added a new authority to a record to match AuthID 51. Upon saving the record it correctly linked to Authority 51. No other authorities in the record linked incorrectly. Repeated the above but enabled LinkerOptions with broader_headings and deleted $9. Got these results: 110 $aChurch of Jesus Christ of Latter-Day Saints $9 51 610 $aChurch of Jesus Christ of Latter-Day Saints $vHymns $9 51 The 610 authority was not in the system. So possibly LinkerOptions is interfering with LinkerModule, though it seems like LinkerOptions did what it was supposed to do linking an authority because it did match the broader heading. Repeated the test again with LinkerOptions enabled on the same record and deleted $9. I added the Presidents topical term to the record and added an authority for the Hymns and got these results: 110 _ _ ‡aChurch of Jesus Christ of Latter-Day Saints‡9 51 610 _ 0 ‡aChurch of Jesus Christ of Latter-Day Saints‡vHymns‡9 52 610 _ _ ‡aChurch of Jesus Christ of Latter-Day Saints‡xPresidents‡9 51 Disabled LinkerOptions again, deleted $9 and got these results (which are correct): 110 _ _ ‡aChurch of Jesus Christ of Latter-Day Saints‡9 51 610 _ 0 ‡aChurch of Jesus Christ of Latter-Day Saints‡vHymns‡9 52 610 _ _ ‡aChurch of Jesus Christ of Latter-Day Saints‡xPresidents‡9 50 The short answer is that LinkerOptions is linking in unexpected ways, and possibly conflicting with LinkerModule.