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 <stomp...@exchange.larl.org>
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:
> 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
>
>
>
>
>
> *From:* Open-ils-general [
> mailto:open-ils-general-boun...@list.georgialibraries.org
> <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
> *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