Bug 32726 - Authority search result display and relator terms in 22.05
Summary: Authority search result display and relator terms in 22.05
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Marius
QA Contact: Testopia
URL:
Keywords:
Depends on: 11083
Blocks:
  Show dependency treegraph
 
Reported: 2023-01-25 15:58 UTC by Marius
Modified: 2024-02-26 19:39 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 32726: Authority search result display and relator term (2.63 KB, patch)
2023-01-25 17:40 UTC, Marius
Details | Diff | Splinter Review
Subject: [PATCH] Bug 32726: Authority search result display and relator term (1.58 KB, patch)
2023-01-27 15:28 UTC, Marius
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marius 2023-01-25 15:58:32 UTC

    
Comment 1 Marius 2023-01-25 17:40:55 UTC
Created attachment 145667 [details] [review]
Bug 32726: Authority search result display and relator term

This pacht displays the relator term in Authority search results in summary column.

1. Go to authorities-home.pl
2. Do a search by personal names (Take one that has no relator term).
3. Edit the authority.
4. Add a Relator term.(100$e)
5. Check in Authority search results the relator term does not appear in summary.
6. Apply patch.
7. Repeat step 5. Now you should be able to see the telator term in summary.

 Current status: NEW
Comment 2 Marius 2023-01-27 15:28:16 UTC
Created attachment 145757 [details] [review]
Subject: [PATCH] Bug 32726: Authority search result display and relator term

This pacht displays the relator term in Authority search results in summary column.

1. Go to authorities-home.pl
2. Do a search by personal names (Take one that has no relator term).
3. Edit the authority.
4. Add a Relator term.(100$e)
5. Check in Authority search results the relator term does not appear in summary.
6. Apply patch.
7. Repeat step 5. Now you should be able to see the telator term in summary.
Comment 3 Blou 2023-01-31 16:03:18 UTC
Seems to be a correction for a display issue caused by Bug 11083.
Comment 4 David Nind 2023-02-02 22:08:58 UTC
Should there be two patches with similar titles and contents?

Maybe this should be squashed - not sure of the protocol here...

(Can confirm it works, so happy to sign off.)
Comment 5 Fridolin Somers 2023-02-17 18:04:26 UTC
(In reply to David Nind from comment #4)
> Should there be two patches with similar titles and contents?
> 
> Maybe this should be squashed - not sure of the protocol here...
> 
> (Can confirm it works, so happy to sign off.)

Same author.
One should squash the two patches
Comment 6 Fridolin Somers 2023-02-17 18:13:40 UTC
(In reply to Blou from comment #3)
> Seems to be a correction for a display issue caused by Bug 11083.

I think not.
Looks like en enhancement.

And this is strange :
In perl :
  heading => $field->as_string(),
  relator  => ( $field->subfield( 'e' ) // undef ),
In TT :
  [% authorize.heading | html %] [% authorize.relator | html %]
"authorize.heading" should already contain subfield $e no ?
Comment 7 Phil Ringnalda 2023-06-14 21:24:46 UTC
No, with more context authorize.heading doesn't contain $e, because in

            $subfields_to_report = $handler->get_auth_heading_subfields_to_report($tag);

            if ($subfields_to_report) {
                push @authorized, {
                    heading => $field->as_string($subfields_to_report),
                    hemain  => ( $field->subfield( substr($subfields_to_report, 0, 1) ) // undef ),
                    field   => $tag,
                };
            } else {
                push @authorized, {
                    heading => $field->as_string(),
                    hemain  => ( $field->subfield( 'a' ) // undef ),
                    field   => $tag,
                };
            }

$subfields_to_report will be true for 100/110/111 and will not include the relator subfield (which is $e for 100/110, but $j for 111), because it is not what people tend to think it is. In an authority record, the relator describes the relationship between the name and the work in a name-title heading, like "$aBlum, Leon,$d1872-1950,$edefendant$tLeon Blum devant la Cour supreme, Riom.$lHebrew" as explained in https://www.loc.gov/marc/authority/adx00.html

Having a 100/110 with a $e but no $t or a 111 with a $j but no $t is wrong. That doesn't necessarily mean that Koha shouldn't show it (particularly because it autocreated authority records that way for years), but not with this patch: blindly adding $e to every heading whether it's defined as relator, defined as something other than relator (it's a repeatable "subordinate unit" subfield for meeting names), or undefined, is not the right solution.
Comment 8 Shi Yao Wang 2024-02-26 15:04:50 UTC
(In reply to Phil Ringnalda from comment #7)
> No, with more context authorize.heading doesn't contain $e, because in
> 
>             $subfields_to_report =
> $handler->get_auth_heading_subfields_to_report($tag);
> 
>             if ($subfields_to_report) {
>                 push @authorized, {
>                     heading => $field->as_string($subfields_to_report),
>                     hemain  => ( $field->subfield(
> substr($subfields_to_report, 0, 1) ) // undef ),
>                     field   => $tag,
>                 };
>             } else {
>                 push @authorized, {
>                     heading => $field->as_string(),
>                     hemain  => ( $field->subfield( 'a' ) // undef ),
>                     field   => $tag,
>                 };
>             }
> 
> $subfields_to_report will be true for 100/110/111 and will not include the
> relator subfield (which is $e for 100/110, but $j for 111), because it is
> not what people tend to think it is. In an authority record, the relator
> describes the relationship between the name and the work in a name-title
> heading, like "$aBlum, Leon,$d1872-1950,$edefendant$tLeon Blum devant la
> Cour supreme, Riom.$lHebrew" as explained in
> https://www.loc.gov/marc/authority/adx00.html
> 
> Having a 100/110 with a $e but no $t or a 111 with a $j but no $t is wrong.
> That doesn't necessarily mean that Koha shouldn't show it (particularly
> because it autocreated authority records that way for years), but not with
> this patch: blindly adding $e to every heading whether it's defined as
> relator, defined as something other than relator (it's a repeatable
> "subordinate unit" subfield for meeting names), or undefined, is not the
> right solution.


What would be an ideal solution for this bug?

Only add the relator $e for 100/110 and $j for 111?
Are there more relator fields other than those?
Is hardcoding for every possible relator a good solution? (I would think it's not)

I'm not familiar enough with marc. Suggestions?
Comment 9 Phil Ringnalda 2024-02-26 19:39:00 UTC
The ideal solution would be to invent time travel, use it to go back to the MARC Advisory Committee meeting where defining a relator in name authorities only for use in name-title authorities was approved, and convince them that it was a terrible idea which would never be used correctly, only incorrectly.

Second best solution would be to implement the FIXME in https://git.koha-community.org/Koha-community/Koha/src/commit/5a188651e484517f28367e44183b680fa77ad77b/C4/Heading/MARC21.pm#L43 and move the definition of which subfields belong in bib records and which belong in authority records from a hardcoded set affecting everyone to a configuration file where individual libraries can choose to do things in a non-interoperable way.