[OPEN-ILS-GENERAL] Series facet fix from conference.

[Josh Stompro]

Janet, In our case it just comes down to a decision to use incorrect cataloging for simplicity and to work around an issue with Millennium indexing where multiple 490/440/8xx fields would result in multiple search results that were annoying to users.  We made the decision long ago so we currently have to deal with the records we have.

I feel like I need the "I'm not a cataloger, but I know enough MARC to annoy them at parties" t-shirt.

Evergreen out of the box is using the mods conversion of the marc record to get the series info.
http://www.loc.gov/standards/mods/v3/mods-mapping.html#relateditem

I think the marc to mods conversion in Evergreen is done by the name='mods32' entry in the config.xml_transform table.
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/953.data.MODS32-xsl.sql

The 490 ind1:0 $a$v is included in the mods <title> with no <titleInfo> type attribute.  490 ind1:1 is skipped since you should have an 8xx field.

So a 440 entry (I know that 440's are depreciated and should be converted) gets converted to a string that includes subfield $a and $v, and then there are two entries for it, one marked with <titleInfo type='nfi'> and one not marked.  If 440 ind2 is greater than zero, the non filing characters are removed from the <title> and shown in the <nonSort> element.

The 830 is similar but all the subfields are included as the title string.

If you wanted to always exclude the 490 value from your series facet, you could copy the "Series Title (browse)" xpath in the Admin -> Server Settings -> MARC search/facet fields over to the "Series Title" entry to exclude entries without the "nfi" attribute.  It might not be that simple though, the 800,810,811 field would never be included since they don't get the nfi attribute.

Maybe the best way would be to create a custom mods32 transform that doesn't include the 490 in any way.

There is a new unAPI feature in 2.10 that lets you view the mods32 version of a bib record in the catalog that has been useful to me while I've been trying to understand this.  https://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_10.html#_expand_unapi_api


Josh Stompro - LARL IT Director

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Janet Schrader
Sent: Thursday, May 26, 2016 9:34 AM
To: open-ils-general at list.georgialibraries.org
Subject: Re: [OPEN-ILS-GENERAL] Series facet fix from conference.

Perhaps I'm misunderstanding something here, but why is it the 490 that shows in the facets? The 490 is not the authorized series tracing, it's a transcribed field from the item. The first indicator is used to show if the series is traced. If it is, the series' tracings are in 8xx fields. It's the 8xx subfield 't' or 830 fields that should be the entries in the facets.


Janet

Janet Schrader
Bibliographic Services Supervisor
C/W MARS Inc.
67 Millbrook Street, Suite 201
Worcester, MA 01606
Tel: 508-755-3323 ext. 325
Fax: 508-757-7801
jschrader at cwmars.org<mailto:jschrader at cwmars.org>


From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Josh Stompro
Sent: Wednesday, May 25, 2016 10:37 AM
To: open-ils-general at list.georgialibraries.org<mailto:open-ils-general at list.georgialibraries.org>
Subject: [OPEN-ILS-GENERAL] Series facet fix from conference.

Hello All, I was notified by Brent Mills (Sage) on IRC that one of the presentations at the conference covered fixing the issue with the series facet where the 490 subfield v is included.  So instead of one entry for the series, you get one entry per volume of the series.  I just wanted to bring it up here in case anyone is searching for it in the future.  I would be for this just being included in the default system, but I'm not a cataloger so I don't know if this is generally applicable or not.

The presentation was Metadata Abattoir by Mike Rylander
https://evergreen-ils.org/wp-content/uploads/2015/11/eg16-Prime-cuts.pdf

Our 490a data wasn't all uniform, the space before the semicolon is missing in many cases, so I adjusted the regexp from " ;.*" to ";.*" so more of our 490's would get fixed without needing to modify the marc data.

We also have a bunch of 490 entries that leave out the semicolon, so I either need to fix the marc for all of those, or find out how to not include the 490v in the first place.  I need to learn much more about xpath and mods before I can figure that out though. (oh, looks like Mike explained how to do that back in 2012 - http://markmail.org/message/l7cfk7fcj2xmw27t - sweet!)

A reingest is needed after the new normalizer is specified before you will see changes in the facet data.  I used the following to only reingest the records that contained a semicolon in the series facet, limited to 9000 records in a batch.

select metabib.reingest_metabib_field_entries(source) from metabib.facet_entry where field=1 and value ~ ';.*$' limit 9000;

Thanks
Josh

Lake Agassiz Regional Library - Moorhead MN larl.org
Josh Stompro     | Office 218.233.3757 EXT-139
LARL IT Director | Cell 218.790.2110

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160526/3c138b34/attachment.html>