Evergreen version: 2.5.3
This bug is possibly related to https://bugs.launchpad.net/evergreen/+bug/1307603.
If I look up Scott, Bronwyn, I get four entries (see screenshot at http://www.screencast.com/t/SFQZ18bn)
1. The first entry is a stray record with an incorrect heading.
2. I'm not quite sure where the second heading comes from. When I figure it out, I may be filing yet another bug report.
3. The third heading comes from the authority record for Bronwyn Scott. http://www.screencast.com/t/CIhMTM6ojafA. This heading appropriately shows the "See Also" heading directing the user to Nikki Poppen.
4. The fourth heading comes from the 500 field of Nikki Poppen's authority record. http://www.screencast.com/t/JWWfzcygfuN
Including the heading listed in 5xx field of an authority record leads to duplication of headings since 5xx headings point to authorized records that already have a heading in the list. We have seen the same behavior with subject authorities.
Also, the browse list should never display the contents of subfield 0. However, we have only noticed this problem in 5xx entries and believe the problem will go away once those entries are removed from the list.
Here's what I believe you're seeing, and configuration changes plus a browse reingest for both bib and auth may be required to address them.
1) incomplete heading in a bib, lacking the birth year, and not linked to an authority entry. Exactly as you suggest
2) Mis-normalized bib entry not linked to via $0 to an authority. It matches the see-also of an auth (for Poppen), though, so we follow that string-match through to the main entry record for Brownyn, which also contains a see-also for Poppen. If properly normalized, this would fold into the entry below it.
3) Correctly normalized bib heading that is linked via $0 to the Brownyn (three such bibs; this is supported by the (3) next to the Brownyn "see" in the preceding entry)
4) Mis-normalized see-also authority heading whose containing authority record's main entry is in use by, and linked to via $0, 6 bib records. If correctly normallized, this would be folded into the entry above it.
If any auth-auth linking was performed by hand early in the testing process, or the auth-auth linker was used on this data prior to the feature's final version, or certain flags (such as those disabling auth reingest) were used at some point, the data could easily get into this state. There may be other ways, as well.
For this test server (and possibly for production sites having issues similar to this) I think the best thing to do would be to clear out all browse-related data, all simple heading data, and finally do a browse-only reingest of bib followed by something along the lines of:
DO $$
DECLARE
auth authority.
ashs authority.
mbe_row metabib.
mbe_id BIGINT;
ash_id BIGINT;
BEGIN
DELETE FROM authority.
FOR auth IN SELECT * FROM authority.
FOR ashs IN SELECT * FROM authority.
INSERT INTO authority.
VALUES (ashs.record, ashs.atag, ashs.value, ashs.sort_value);
ash_id := CURRVAL(
SELECT INTO mbe_row * FROM metabib.
WHERE value = ashs.value AND sort_value = ashs.sort_value;
IF FOUND THEN
mbe_id := mbe_row.id;
ELSE
INSERT INTO metabib.
( value, sort_value ) VALUES
( ashs.value, ashs.sort_value );
mbe_id := CURRVAL(
END IF;
INSERT INTO metabib.
END LOOP;
END LOOP;
END;
$$;
That's untested, but it's cut from the authority ingest code, so should work fine. All of that should be performed on a quiescent server, especially WRT bib or auth updates.