Authority See From Tracing not working without a separate authority record

Bug #1476661 reported by Chris Sharp
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

We have discovered that See From tracings are not working as expected when there is not a separate authority record present in Evergreen. For example, the author Ally Condie's authorized name heading is "Allyson Braithwaite Condie" with a 400 field containing "Ally Condie" (http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=6921848&v1=1&HC=1&SEQ=20150721090727&PID=dNleZEMymykEWXOLtogVnSeSVnO). However browse searches for "Ally Condie" do not produce results, and there is no discernible linkage to the correct record, which means that a patron doing browse search would walk away thinking we had no titles by that author.

Another example is the author Ursula Archer (http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=8917150&v1=1&HC=1&SEQ=20150721091401&PID=SqJGz4NTTNE0ImtyO4BwFZZqFg) whose authority record is for "Ursula Poznanski". Browse searches for "Archer, Ursula" do not produce results in the browse list.

Evergreen 2.7.2
OpenSRF 2.40
PostgreSQL 9.3
Ubuntu LTS

Revision history for this message
Mike Rylander (mrylander) wrote :

That's because the interface is based on what exists in the bib data. Specifically, only terms in use by bibs, or authorized headings /not/ in use where the unauthorized headings /are/ in use, show up in browse.

There may be a way to show unused unauthorized headings with some development, but it would take a little work. You'd need to start by changing metabib.browse_pivot() to use metabib.browse_authority_pivot() instead of metabib.browse_authority_refs_pivot(). In the end, you're going to end up with an entry for every single 4xx, 5xx, and maybe 7xx from your authorities, meaning tons of "dead" browse rows. Maybe worth a try to see if you like the output, though.

Could be made a switch, if it's a reasonable choice for some sites.

Revision history for this message
Kathy Lussier (klussier) wrote :

If I'm understanding the original report correctly, I believe this may be a duplicate of https://bugs.launchpad.net/evergreen/+bug/1358392. Can somebody confirm if this is the same issue?

Revision history for this message
Elaine Hardy (ehardy) wrote :

It does seem to be a duplicate -- this from the name authority heading and https://bugs.launchpad.net/evergreen/+bug/1358392 from a subject heading perspective.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.