bib browse index definition improvements

Bug #1662541 reported by Galen Charlton on 2017-02-07
20
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

The current config.metabib_field definitions for certain subject browse fields cause components of a heading to be broken up, which decreases the utility of the browse list.

For example, consider the heading

=650 \0$aPresidents$zUnited States$vCorrespondence.

This is a pre-composed topical heading with form and geographic subdivision. Currently, the browse entry value that gets extracted is

"Presidents"

Were the XPath for cmf entry 14 changed (or an entry added) to

//mods32:mods/mods32:subject[local-name(./*[1]) = "topic"]

the extracted browse entry would be the entire heading:

Presidents -- United States -- Correspondence

This bug will be used for changes to the bib seed data to improve browse entries.

Evergreen master

Galen Charlton (gmc) wrote :

This is part of Equinox's authority infrastructure project in bug 1638299, but work here will be able to be committed separately.

Changed in evergreen:
importance: Undecided → Wishlist
Galen Charlton (gmc) on 2017-02-08
Changed in evergreen:
milestone: none → 2.12-beta
Dan Scott (denials) wrote :

Hmm, MODS 3.2 is over ten years old; any chance of updating to MODS 3.6 if this is part of a general overhaul? There have been a ton of refinements to MODS over the years that provide much more granularity, in some places reflecting improved implementation, and in other places reflecting the adoption of RDA.

Galen Charlton (gmc) wrote :

Dan: I think upgrading to MODS 3.6 is a good idea, but with respect to timing, it's probably a better fit as a component of or bug linked to bug 1638299 and targeted for 2.13/3.0. For the purpose of this bug, the patches I'll be submitting later today will remain limited in scope to just adding additional browse index definitions using the current stylesheets.

Galen Charlton (gmc) on 2017-02-17
summary: - bib browse and facet index definition improvements
+ bib browse index definition improvements
description: updated
Galen Charlton (gmc) wrote :

A patch is available at the tip of the user/gmcharlt/lp1662541_additional_subject_browse_indexes branch in the working/Evergreen repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1662541_additional_subject_browse_indexes

tags: added: pullrequest
Kathy Lussier (klussier) wrote :

Thank you Galen! This looks good. I've merged this patch to master, but I have a follow up question.

I was wondering what the punctuation issue is with incorporating name subjects into this new feature. C/W MARS and NOBLE have had an index customization for years that is similar to this new feature where they configured 'All Subjects' to be the browse field since it also displayed the subject entries as a single entity. As far as I know, there are no problems with punctuation of the name entries in their browse lists. I just did a few sample browse searches on their systems, and nothing jumped out at me.

Also noting that this new feature addresses bug 1331506. I'll mark that one as a duplicate.

Kathy Lussier (klussier) on 2017-02-19
Changed in evergreen:
status: New → Fix Committed
Galen Charlton (gmc) wrote :

Consider a name heading of the form:

$aNapoleon$bI,$cEmperor of the French,$d1769-1821$xFiction

The traditional form of the heading would be punctuation like this:

Napoleon I, Emperor of the French, 1769-1821 -- Fiction

However, without making either code or XSLT a bit smarter, it would end up like this, which is wrong:

Napoleon -- I -- Emperor of the French -- 1769-1821 -- Fiction

Some examples of this mispunctuation can be found here in the NOBLE catalog:

http://evergreen.noblenet.org/eg/opac/browse?blimit=10;qtype=subject;bterm=napoleon%20i;locg=1;bpivot=10718912

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers