sorting of name headings with relator codes

Bug #1308090 reported by Elaine Hardy on 2014-04-15
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned
2.10
Undecided
Unassigned
2.11
Undecided
Unassigned

Bug Description

Name headings created under RDA rules often have a relator code in the |e that is not present in headings created under AACR2R rules. These headings (1xx and 7xx fields) sort separately from those without those codes. For example:

100 1 |a Roth, Veronica.

vs.

100 1 |a Roth, Veronica, |e author.

sorts as two different headings. While this is OK in browse search since both names are displayed, in advanced search, clicking on one heading in a search result list does not lead immediately to the other heading. (From the OPAC display of a record, it does).

Since we will have databases with both kinds of headings for a very long time, ideally, having the indexing/sorting ignore the relator code should be considered provided it does not adversely affect other sorting/indexing issues.

Mike Rylander (mrylander) wrote :

It looks to me like we should:

 1) Not include the relator in the display on search results (tempalte change)
 2) Not include the relator in facet or browse data (config change; partial reingest)
 3) Normalize away "." and "," in facet and browse data (config change; partial reingest)

This would cause facets, author links on results, and browse entries to fold the two headings together. So, we'd be looking at configuration + partial reingest (facet and browse -- the rest are will be unaffected by this change), and a template change for author link building in search results.

As a side note, we should take this into account if/when the "display fields" work continues, as the same normalizations would be appropriate there.

Elaine Hardy (ehardy) wrote :

What template in 1? (Of course, I won't be the one making any of these changes, so don't panic)

Thanks!

Mike Rylander (mrylander) wrote :

It looks like we could add subfield e to the list of ignored subfields in the get_graphic_880s macro in misc_util.tt2 ... But that would have an effect on 100, 110, 111, 245, 260, 264, 250 and 505, so it might need to be tag-specific logic (or, better, an "additional ignore list" that macro callers could supply).

As of now, we would only want it to apply to the 100, 110, 111, 700,710,711
fields and perhaps 800, 810, 811

Elaine

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304

404.235-7128
404.235-7201, fax
<email address hidden>
www.georgialibraries.org
www.georgialibraries.org/pines

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Mike
Rylander
Sent: Wednesday, April 16, 2014 2:17 PM
To: <email address hidden>
Subject: [Bug 1308090] Re: sorting of name headings with relator codes

It looks like we could add subfield e to the list of ignored subfields in
the get_graphic_880s macro in misc_util.tt2 ... But that would have an
effect on 100, 110, 111, 245, 260, 264, 250 and 505, so it might need to be
tag-specific logic (or, better, an "additional ignore list" that macro
callers could supply).

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1308090

Title:
  sorting of name headings with relator codes

Status in Evergreen - Open ILS:
  New

Bug description:
  Name headings created under RDA rules often have a relator code in the
  |e that is not present in headings created under AACR2R rules. These
  headings (1xx and 7xx fields) sort separately from those without those
  codes. For example:

  100 1 |a Roth, Veronica.

  vs.

  100 1 |a Roth, Veronica, |e author.

  sorts as two different headings. While this is OK in browse search
  since both names are displayed, in advanced search, clicking on one
  heading in a search result list does not lead immediately to the other
  heading. (From the OPAC display of a record, it does).

  Since we will have databases with both kinds of headings for a very
  long time, ideally, having the indexing/sorting ignore the relator
  code should be considered provided it does not adversely affect other
  sorting/indexing issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/evergreen/+bug/1308090/+subscriptions

Elaine Hardy (ehardy) wrote :

As of now, we would only want it to apply to the 100, 110, 111, 700,710,711 fields and perhaps 800, 810, 811

Sarah Childs (sarahc) wrote :

I'm just commenting with the RDAese for relator codes, relationship designators, in case it might lead more people to find this bug and add heat.

Remington Steed (rjs7) on 2015-05-11
tags: added: authority
Jeanette Lundgren (jlundgren) wrote :

I am confirming this is an issues in EG 2.8.4. Our libraries don't like that Personal Authors are displayed twice in the facet. One with a period at the end (non RDA) and one without the period (RDA). We are finding this more frequently as we have more records using RDA relator codes.

For example, a keyword search on Roth, Veronica returns the facet

Personal Author
Roth, Veronica. (13)
Roth, Veronica (8)

Changed in evergreen:
status: New → Confirmed
Janet Schrader (jschrader) wrote :

Agreeing with Elaine that the tags affected are 100, 110, 111, 700, 710, 711, and 800, 810, and 811. Adding that in addition to relator terms in subfield e there may also be relator codes in subfield 4 in these fields. I think subfield 4 existed in AACR2 before |e became the standard in RDA.

Kathy Lussier (klussier) wrote :

Adding a link to the related bug/fix at https://bugs.launchpad.net/evergreen/+bug/1427331

Dan Pearl (dpearl) on 2016-04-26
Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Jason Stephenson (jstephenson) wrote :

Given the heat from all of the "This bug affects mes," I'm going to target this as a bug fix.

If anyone disagrees, please chime in on the comments and we can discuss it.

Changed in evergreen:
milestone: none → 2.11-beta
Dan Pearl (dpearl) wrote :
tags: added: pullrequest
Dan Pearl (dpearl) on 2016-08-29
Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Kate Butler (kreb) wrote :
tags: added: signedoff
Kathy Lussier (klussier) wrote :

Adding a note that, according to the commit, the code also adds relators to the record details page that had previously been missing. I don't think that piece of the code was tested today, so I'm adding a note as a reminder to test it before merging the code.

Kathy Lussier (klussier) wrote :

I tested the change to relators on the record detail page. Previously, the subfield e displayed along with the author name, followed by what I'm guessing is the pre-RDA relator code, resulting in the display of duplicate information. Now, the subfield e displays as the relator, eliminating the duplicate relator display. This looks good.

The one problem I found was with the PgTAP. When I initially ran the test, 3 of the tests failed. Two were due to typos in the script. After fixing the typos, I am still left with the following results when I run the test:

lp1308090-facet_punct.pg .. 1/12
# Failed test 5: "Initial w/o preceding space (period)"
# have: X
# want: X.
# Looks like you failed 1 test of 12
lp1308090-facet_punct.pg .. Failed 1/12 subtests

Test Summary Report
-------------------
lp1308090-facet_punct.pg (Wstat: 0 Tests: 12 Failed: 1)
  Failed test: 5
Files=1, Tests=12, 3 wallclock secs ( 0.08 usr 0.01 sys + 0.08 cusr 0.06 csys = 0.23 CPU)
Result: FAIL
opensrf@mlnc2:~/Evergreen/Open-ILS/src/sql/Pg/t$ pg_prove -h localhost -U evergreen -d evergreen lp1308090-facet_punct.pg
lp1308090-facet_punct.pg .. Password for user evergreen:
lp1308090-facet_punct.pg .. 1/12
# Failed test 5: "Initial w/o preceding space (period)"
# have: X
# want: X.

I fixed the two typos in the top commit at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/LP1308090_relatorA , but the final test needs to be fixed.

Thanks for your work on this Dan!

Kathy Lussier (klussier) wrote :

Oops. Hit Post Comment too soon. I asked this question in IRC, but I'll ask it here as well.

I'm okay with treating this as a bug fix, but I see it requires a partial reingest. Are there any concerns about backporting the fix if it requires a reingest? Jeff suggested in IRC that the reingest could be optional. Not running it means you won't see the fix, but it doesn't cause any other problems.

Dan Pearl (dpearl) wrote :

I think the PgTap test that failed is faulty, likely due to a cut and paste error when creating the test. The code attempts to turn xxxx. into xxxx if and only if the xxxx doesn't look like an initial. "Slattery,Francis X." => same, but "Smith,John." => "Smith,John".

The "X." should go to "X", so the pgTap test is expecting the wrong value.
(Yeah, it's kind of a degenerate case.)

Kathy Lussier (klussier) wrote :

In that case, then, should we remove the test in question or is there something that can be done to it to ensure that it passes? FWIW, I didn't cut and paste code when testing the test. I merged the git branch and then ran the test.

Dan Pearl (dpearl) wrote :

I think the PgTap test that failed is faulty, likely due to a cut and paste error when creating the test. The code attempts to turn xxxx. into xxxx if and only if the xxxx doesn't look like an initial. "Slattery,Francis X." => same, but "Smith,John." => "Smith,John".

The "X." should go to "X", so the pgTap test is expecting the wrong value.
(Yeah, it's kind of a degenerate case.)

Kathy Lussier (klussier) wrote :

OK, Dan. Would you be able to sign off on the commit I added and then make the change to the faulty test?

Dan Pearl (dpearl) wrote :

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

I'm not sure whether to base the final change on this file, or the previous version. I think I'll base it off this file; it might make the final merge easier(?)

no longer affects: evergreen/2.9
Changed in evergreen:
milestone: 2.11-beta → 2.next
Kathy Lussier (klussier) on 2017-02-06
Changed in evergreen:
milestone: 2.next → 2.12-beta
Kathy Lussier (klussier) wrote :

Due to the need to reingest records after this code is put into place, I'm removing the targets for 2.10 and 2.11 and setting this to Wishlist.

Changed in evergreen:
importance: Undecided → Wishlist
Kathy Lussier (klussier) wrote :

Many thanks Dan! Merged to master for inclusion in 2.12

Changed in evergreen:
status: Confirmed → Fix Committed
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