Series Facet includes Subfield V

Bug #1502328 reported by Josh Stompro
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

The series title facet includes more than just the 490 subfield a, it looks like it grabs everything. So if there is a subfield v entered, (which number in the series the bib is) then you get multiple entries in the Series Title facet.

This seems like incorrect behavior since I cannot limit to just a series by clicking on an entry in the series titles facet. I can only limit to specific titles in the series that have the same subfield v set.

Example:
http://egcatalog.larl.org/eg/opac/results?query=agatha%20raisin;qtype=series;locg=1;long_facet=seriesseriestitle
A search for Agatha Raising results in a Series Title Facet that looks like.
Series Title
Agatha Raisin 23 (3)
Agatha Raisin; 22 (3)
Agatha Raisin 25 (2)
Agatha Raisin; 24 (1)
Agatha Raisin; 4 (1)
Agatha Raisin; 6 (1)
Agatha Raisin; 8 (1)

I think that the correct behavior would be to have one entry for "Agatha Raisin" that once selected would show only titles in that series.

Let me know if including the subfield V is the intended behavior. Maybe users do want to be able to pick the exact number in the series from that facet, and not just to limit to that series.

There are several other bugs that mention series display issues, I'm not sure if they all have the same root problem.
https://bugs.launchpad.net/evergreen/+bug/1353092
https://bugs.launchpad.net/evergreen/+bug/1083796

The config.metabib for series has an xpath of
//mods32:mods/mods32:relatedItem[@type="series"]/mods32:titleInfo[not(@type="nfi")]

There is no facet_xpath set.

Kathy suggested that maybe it would be better to use a seperate entry for the series facet that uses a //marc instead of //mods so the subfields can be specified. I don't know enough of why mods is used in this case vs something else to know if that is the general answer.

Tested on a 2.8.4 system .
Thanks

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

And some more discussion on IRC after I submitted this.

* eeevil reads up ... so, the MODS 3.2 tranform says that 440av (all together) goes into <relatedItem><titleInfo><title> ... I haven't checked later MODS revisions
<eeevil> however, 490[ind1=0]a is different, and is stored separate from $v
<jeff> I have, and grew frustrated.
<eeevil> so, cataloging can control it today. just use 490[ind1=0] instead of 440. easier said than done, I know
<eeevil> 3.3 and 3.5 are the same in this respect
<jeff> eeevil: Memory (and a quick check just now) serves that subfields a and v of the 490 are concatenated into the same element in MODS. Are you seeing a MARCXML to MODS XSLT that creates series info from just the 490$a?
<eeevil> jeff: I'm just reading the rules at http://www.loc.gov/standards/mods/v3/mods-mapping.html#relateditem ... the xslt could certainly differ from the docs, obv ;)
<eeevil> also...
* eeevil is now known as miker
<miker> jeff: that suggests 440 has a and v concatenated, but 490 with ind1=0 should not
<miker> if I'm reading it right, of course
<miker> if so, a facet_xpath should be able to grab just <title> and not <partNumber>
<miker> (but, again, docs...)
<Stompro> miker, our series titles are stored with 490[ind1=0], so that shouldn't be an issue.
<miker> if I'm, indeed, correct, you could set the facet_xpath to "//*[local-name()='title']" on the series title index definition, then. my tuits are lacking for testing, but give it a try?

I tried adding setting the seriestitle facet_xpath to "//*[local-name()='title']" but it didn't seem to have any effect.

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

Ran across what appears to be same issue in Evergreen 3.2 webclient

Related bib portion below:

=490 1\$aDuff MacCallister western ;[$v9]
=490 1\$a[MacCallister, the eagles legacy (Series) ;$v09.]

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

This continues to be an issue in 3.5 in both the current and angular catalogues.

tags: added: cataloging
tags: added: opac
Revision history for this message
Elaine Hardy (ehardy) wrote :

I agree that it shouldn't consider the volume number in the facet display.

I would prefer that the series facet just display the 8xx field and not also the 490, if both are present in the record. The 490 will vary based on what is on the piece but the 8xx field should be the authorized form for tracing.

For those older records with just 490s or 440s, then I would want them displayed in the facet list.

Changed in evergreen:
status: New → Confirmed
Changed in evergreen:
importance: Undecided → Medium
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.