Series Facet includes Subfield V
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://
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:/
https:/
The config.metabib for series has an xpath of
//mods32:
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
tags: | added: opac |
Changed in evergreen: | |
importance: | Undecided → Medium |
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 www.loc. gov/standards/ mods/v3/ mods-mapping. html#relatedite m ... the xslt could certainly differ from the docs, obv ;) name()= 'title' ]" on the series title index definition, then. my tuits are lacking for testing, but give it a try?
<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://
<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-
I tried adding setting the seriestitle facet_xpath to "//*[local- name()= 'title' ]" but it didn't seem to have any effect.