Typical series for public libraries are 490/800 combinations rather than the 490/830. Excluding them might have a negative impact on retrieval. .
Elaine J. Elaine Hardy PINES & Collaborative Projects Manager Georgia Public Library Service/PINES 1800 Century Place, Ste. 150 Atlanta, GA 30045 404.235.7128 Office 404.548.4241 Cell 404.235.7201 FAX On Thu, May 26, 2016 at 3:45 PM, Josh Stompro <[email protected]> wrote: > 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: > [email protected]] *On Behalf Of *Janet > Schrader > *Sent:* Thursday, May 26, 2016 9:34 AM > *To:* [email protected] > *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 > > [email protected] > > > > > > *From:* Open-ils-general [ > mailto:[email protected] > <[email protected]>] *On Behalf Of *Josh > Stompro > *Sent:* Wednesday, May 25, 2016 10:37 AM > *To:* [email protected] > *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 > > >
