Unauthorized headings does not display in browse result during browse search if not in a "complete" set

[Srey Seng]

When browsing for an unauthorized heading, the expected behavior is that we would see the unauthorized heading in the browse search result, with a "See" reference to its authorized heading, if the authorized heading is linked to a bib.

However, this is not the case.

Assumptions:
(1) Auth A & Auth B has been imported into Evergreen
(2) Bibs exists that are controlled by Auth A & Auth B (bib-auth linking has been run)
(3) Auth-auth linking has purposely not been run***

Auth A:
=100 1\$aPoppen, Nikki,$d1967-
=400 1\$aPoppen-Eagen, Nikki,$d1967-
=400 1\$aEagen, Nikki Poppen-,$d1967-
=500 1\$aScott, Bronwyn,$d1967-

Auth B:
=100 1\$aScott, Bronwyn,$d1967-
=500 1\$aPoppen, Nikki,$d1967-

For example, given the above Assumptions and Auth snippets:
When I browse search for "Eagen, Nikki Poppen-, 1967-", I should get a See reference to "Poppen, Nikki, 1967-." Similarly, when I browse search for "Poppen-Eagen, Nikki, 1967-", I should get a See reference to "Poppen, Nikki, 1967-." This is not the case.

Without a "complete" bib/auth set, unauthorized headings are never exposed in the browse result list. A complete set would be where you have two authority records that is linked to each other, and at least the authority record with the targeted unauthorized heading needs to link to at least one bib.

Unauthorized headings should not have to be in a "complete" set to surface, they should surface even in an isolated set. An isolated set would be where the targeted unauthorized heading exists in an authority record that is linked to a bib without also having to be linked to another authority record.

Complete sets are a minority, and there are significantly much more authority records that lives in an isolated set****.

Notes:
----------------------------
***This is to emulate scenario where we have authority records that do not link to other authority records but do link to bibs and do have unauthorized headings. In other words, we can have authority records that have unauthorized entries but do not have cross references, either because the cross references have not been imported into the database or no cross references exists yet, or there's no 5xx in the authority record.
****Either because these authority records simply don't have cross references, or the cross references haven't been imported.
----------------------------
Attachment "records.mrc.zip" is a zip file containing the Auths mentioned here as well as sample bibs that are written by these auths, from LC.

[Kathy Lussier (klussier)]

I'm not sure I'm completely following the difference between a complete and isolated set, but is this the same issue Tim reported in https://bugs.launchpad.net/evergreen/+bug/1358392?

[Srey Seng (sreyseng)]

Hi Kathy,

Yes, you are right! I do believe this issue is a duplicate reporting of the issue reported by Tim.

But to clarify the difference between a complete and isolated set.

An "isolated" auth/bib set would be the following:

Auth A:
=100 1\$aPoppen, Nikki,$d1967-
=400 1\$aPoppen-Eagen, Nikki,$d1967-
=400 1\$aEagen, Nikki Poppen-,$d1967-
=500 1\$aScott, Bronwyn,$d1967-

Bib A:
Book by Poppen, Nikki,$d1967-

It is when you simply have an auth, and one or more bibs linked to that auth. It consists of just one auth and its associated bibs. None of Auth A's 4xx will surface when browsing for them.

A "complete" auth/bib set would be the following:

Auth A:
=100 1\$aPoppen, Nikki,$d1967-
=400 1\$aPoppen-Eagen, Nikki,$d1967-
=400 1\$aEagen, Nikki Poppen-,$d1967-
=500 1\$aScott, Bronwyn,$d1967-

Auth B:
=100 1\$aScott, Bronwyn,$d1967-
=500 1\$aPoppen, Nikki,$d1967-

Bib A:
Book by Poppen, Nikki,$d1967-

It is when you have an auth, and one or more bibs linked to that auth. Additionally, that auth is also linked to its cross reference. It's that additional interlinking between Auth A & Auth B that turns this into a "complete" set versus an "isolated" set. Now, Auth A's 4xx will surface when browsing for them.

Again, this is a duplicate reporting of bug: https://bugs.launchpad.net/evergreen/+bug/1358392?

I think we were both trying to report the fact that if there is no See Also reference for an auth, the unauthorized references for that auth do not surface in browse result, and that this should not be the case. See Also references should not have to exist for an auth for its unauthorized references to surface in browse results.

[Kathy Lussier (klussier)]

OK, I'm marking this one as a duplicate, but I'll copy your description over on the other bug since I think it adds some details that weren't in Tim's report.

Thanks!