Bibliographic browse headings show relator information

[Kathy Lussier]

Evergreen version: 3.0

I've noticed relator information showing up in some author headings in a browse search.

As an example, although most records for titles by John Grisham are connected to the heading that displays as Grisham, John, we also have a handful connected to a heading that displays as

Grisham, John creator author

See screenshot at http://www.screencast.com/t/tuhuv4bSSftX.

Here is the MARC for one of the records linked to that browse entry:
https://pastebin.com/W6wHgwYY

[Beth Willis (willis-a)]

Evergreen version: 3.0.7

I see the same thing. Screenshots attached of browse search and one MARC record linked to heading with relator information.

[Jennifer Pringle (jpringle-u)]

I see the same thing on 3.1 as well.

[Jane Sandberg (sandbergja)]

I did a bit of digging here. It seems that all the problematic browse entries all have the same config.metabib_field. Its ID is 37 in our system. Here it is:

 id | field_class | name | label | xpath | weight | format | search_field | facet_field | browse_field | browse_xpath | facet_xpath | restrict | authority_xpath | browse_sort_xpath | joiner | display_xpath | display_field
----+-------------+---------+--------------+--------------------------------------------------------------------------+--------+--------+--------------+-------------+--------------+--------------+-------------+----------+-----------------+-------------------+--------+------------------------------+---------------
 37 | author | creator | All Creators | //mods32:mods/mods32:name[mods32:role/mods32:roleTerm[text()='creator']] | 1 | mods32 | t | f | t | | | f | | | | //*[local-name()='namePart'] | t

It looks pretty similar to all the other author metabib_fields. Could the MARC->MODS transform be at fault here?

[Jane Sandberg (sandbergja)]

Update: I looked at the MODS via supercat, and it seemed correct: http://libcat.linnbenton.edu/opac/extras/supercat/retrieve/mods33/record/147068

But this record still shows up in our author browse as "Bieber, Justin 1994- creator performer. prf" (see https://libcat.linnbenton.edu/eg/opac/browse?blimit=10&qtype=author&bterm=Bieber%2C+Justin+1994-+creator+performer.+prf&locg=1)

What are the next steps in troubleshooting this issue?

[Dan Wells (dbw2)]

It looks like the issue here is that config.metabib_field for ID 37 does not define the same browse_xpath as the other author fields. The other author browse fields (7, 8, 9, and 10) set browse_xpath to:

//*[local-name()='namePart']

Were we to put that into the config for 37, it should collapse these values in the same way.

That said, I think perhaps a better solution here for a standard configuration would be to not have config 37 be defined as a browse field at all (i.e. browse_field = 'f'). I'm guessing field 37 was added to aid in combined search of all creators (or possibly a shared display field?), and is functionally duplicative of the other four fields when it comes to browse, since browse fields are never by their nature combined. But this suggestion is just my supposition, and testing may reveal a reason to keep this as a duplicate browse definition for creators.

Dan

[Jane Sandberg (sandbergja)]

Thanks so much for taking a look at this, Dan! I can confirm that updating the browse_xpath of ID 37 to match the other author fields fixes the issue. Turning off browse_field also makes sense to me, but I haven't been able to test/investigate that very much.

For now, I think we'll just change the browse_xpath value in our system, until an official fix is decided on.