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-boun...@list.georgialibraries.org] On Behalf Of Janet 
Schrader
Sent: Thursday, May 26, 2016 9:34 AM
To: open-ils-general@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
jschra...@cwmars.org<mailto:jschra...@cwmars.org>


From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh 
Stompro
Sent: Wednesday, May 25, 2016 10:37 AM
To: 
open-ils-general@list.georgialibraries.org<mailto:open-ils-general@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

Reply via email to