Authority entries in 5xx field should not be listed as a main entry in browse list
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Medium
|
Unassigned |
Bug Description
Evergreen version: 2.5.3
This bug is possibly related to https:/
If I look up Scott, Bronwyn, I get four entries (see screenshot at http://
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://
4. The fourth heading comes from the 500 field of Nikki Poppen's authority record. http://
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. record_ entry%ROWTYPE; simple_ heading% ROWTYPE; browse_ entry%ROWTYPE;
ashs authority.
mbe_row metabib.
mbe_id BIGINT;
ash_id BIGINT;
BEGIN
DELETE FROM authority. simple_ heading;
FOR auth IN SELECT * FROM authority. record_ entry WHERE NOT DELETED LOOP
FOR ashs IN SELECT * FROM authority. simple_ heading_ set(auth. marc) LOOP
INSERT INTO authority. simple_ heading (record, atag,value, sort_value) 'authority. simple_ heading_ id_seq' ::REGCLASS) ;
VALUES (ashs.record, ashs.atag, ashs.value, ashs.sort_value);
ash_id := CURRVAL(
SELECT INTO mbe_row * FROM metabib. browse_ entry
WHERE value = ashs.value AND sort_value = ashs.sort_value;
IF FOUND THEN browse_ entry
mbe_id := mbe_row.id;
ELSE
INSERT INTO metabib.
( value, sort_value ) VALUES
( ashs.value, ashs.sort_value );
mbe_id := CURRVAL( 'metabib. browse_ entry_id_ seq'::REGCLASS) ;
END IF;
INSERT INTO metabib. browse_ entry_simple_ heading_ map (entry, simple_ heading) VALUES (mbe_id,ash_id);
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.