TPAC - series link in record fails with non-title series entries

Bug #1102739 reported by Ben Shum
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Medium
Unassigned

Bug Description

Evergreen master

In record display, the links to series information shows all the subfields related to the various series tags of any given record. However, the metabib config only ships with indexing of series title. So, for example using the new Harry Potter and the Goblet of Fire record that was added recently to master's sample bib records.

The series links for record details of that bib show up as:

Year four at Hogwarts
Harry Potter: Year four at Hogwarts
Rowling, J. K. Year ... at Hogwarts
Harry Potter: Year four at Hogwarts

The third link for "Rowling, J. K. Year ... at Hogwarts" will never find any matches if you click on it. This is because it's generated from 800a which is a series author entry while the index only contains the entry for 800t for series title.

So ideally, I think we should change the series links to only show the tag and subfield combinations for series title information. Or we could add more metabib indexes for different kinds of series data.

Tags: opac series
Ben Shum (bshum)
Changed in evergreen:
importance: Undecided → Medium
milestone: none → 2.4.0-alpha
status: New → Triaged
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-alpha1 → 2.4.0-beta
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-beta → 2.4.0-rc
Revision history for this message
Steve Callender (stevecallender) wrote :

This is a good find. I just stumbled across this issue myself. I think the series tags being used to build the links on the screen need to be extremely specific for series. No authors and parts. Just use the specific fields from mods for the title. Such has 490 only if it has ind=0 set, or 800 subfield t, and things like that. Right now the majority of the time the links do not match what is indexed for the searching which causes the broken link issue.

Revision history for this message
Steve Callender (stevecallender) wrote :

Another thought after talking to Mike Rylander about this, is that there may be an API out there that can be used to cross reference the data with the DB to make sure that it exists before building the link. It could be used to eliminate dead links. Just throwing this out there to spark ideas, not as a definitive solution.

Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-rc → none
Revision history for this message
Holly Brennan (hollyfromhomer) wrote :

+1 for what Steven said above. Having author/personal name and volume numbers just screws up the search. The search should just do a series query for 800 $t, since that is the series title.

Revision history for this message
Ben Shum (bshum) wrote :

For me, I think maybe what we should try here is to disentangle the series information (with the full statements and details) vs. the actual search series links, which we may only want to include titles for. Perhaps either putting the rest of the series statements in with record details further above in the record summary, or just starting a new series area but make them plain text, not links. Followed by then links just to series titles, and for this we spend more time focusing on how we get those to display. If there's an 800t, go for it, but only show me the 490 if ind1=0 or similar, so that we avoid repetitive links. A sort of hierarchy of what's considered most important as it were?

Putting a tentative target for 2.next because this would be nice to solve during the 2.7 development cycle. Looking for further feedback / opinions by end users.

Changed in evergreen:
milestone: none → 2.next
assignee: nobody → Ben Shum (bshum)
status: Triaged → In Progress
Revision history for this message
Mike Rylander (mrylander) wrote :

Just a note: the "display fields" idea worked on at various times by Dan Scott, Bill Erickson, and myself would go a /long/ way to addressing this issue and many of its ilk. See: bug 1251394.

Revision history for this message
Ben Shum (bshum) wrote :

2.someday. :\

Changed in evergreen:
assignee: Ben Shum (bshum) → nobody
status: In Progress → Triaged
no longer affects: evergreen/2.3
no longer affects: evergreen/2.4
Revision history for this message
Tina Ji (tji) wrote :

Is this considered fixed? I still see the same behaviour described by Ben on 3.0.2.

Revision history for this message
Scott Thomas (scott-thomas-9) wrote :

Still a problem in 3.1.

Scott

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

While this is still an issue in 3.0, because 3.1 uses display fields it should not be a problem there.

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

Confirming what Mike just said. Looking at the Concerto dataset, on my VM running 3.0, I see "Rowling, J. K. Year ... at Hogwarts" listed as the series link on record 210. On an identical VM running 3.1, I see "Year ... at Hogwarts." The author is no longer part of the link.

I also checked this on a live 3.1 catalog to verify that author's are no longer showing.

Another improvement for the series link would be to subdivide it so that a record with:

‡tHarry Potter series ; ‡v6.

would allow you to click the first part just to retrieve records with Harry Potter series, but when clicking the 6, you search the entire string. This is the way Subject links used to work prior to bug 1770453. This is behavior we really want to see returned and possibly extended to the Series links.

tags: added: opac
removed: tpac
Revision history for this message
Terran McCanna (tmccanna) wrote :

I'm going to mark this Won't Fix since the problem that was originally reported is no longer an issue.

Comment #10 may warrant a wish list if it is desired.

Changed in evergreen:
status: Triaged → Won't Fix
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: 3.next → none
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.