Bug 21302 - Link in 780/785 should search for $t in title and $a in author
Summary: Link in 780/785 should search for $t in title and $a in author
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 34482
  Show dependency treegraph
 
Reported: 2018-08-31 14:51 UTC by Caroline Cyr La Rose
Modified: 2024-03-05 21:53 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caroline Cyr La Rose 2018-08-31 14:51:02 UTC
When a record has a 780 and/or 785 field with both $a and $t, the link should search for the value in $a in the author index and the value in $t in the title index, combined with AND. Right now, it searches for both in the title index.

Steps to reproduce:
1- If its not already in your cataloguing framework, add 780 $a and $t and 785 $a and $t (check the "Editor" box)
2- Search for a record and edit it
3- Add an author name in 780 $a and 785 $a
4- Add a title in 780 $t and 785 $t
5- Make sure both indicators for both fields are 0, so it should look like 

780 00 $aAuthor1 $tTitle1
785 00 $aAuthor2 $tTitle2

6- Save the record and view it in "normal" view
7- Click the link created for Author1 Title 1 -> the search is ti,phr:Author1 Title1, but it should be au,phr:Author1 and ti,phr:Title1
8- Repeat step 7 with Author2 Title2, same result

If possible, it would be great if all values were searched in their rightful index with "and" in between to narrow the search.

76X - 78X
$a = author (same as 1XX or 7XX)
$d = publisher, publication date or place (same as 260 $a, $b, $c or 264 $a, $b, $c)
$e = language (same as 008/35-37)
$f = publication place (same as 008/15-17)
$k = series (same as 4XX or 8XX)
$o = identifier number (same as 0XX)
$p = title (same as 210)
$s = uniform title (same as 240 or 243)
$t = title (same as 245 or 130)
$u = report number (same as 027)
$x = issn (same as 022)
$y = coden (same as 030)
$z = isbn (same as 020)
Comment 1 Heather 2022-09-08 16:26:09 UTC
I disagree--the linking entry fields, https://www.loc.gov/marc/bibliographic/bd760787.html are common in serial records where the $a and $t are often very common terms (e.g., made up example, $a Maritime History Society. $t Newsletter) and so this is why the $w contains _exact_ record numbers--the primary key for the record to be searched.  In OCLC libraries, it is common to place the OCLC number in the 001 as the primary key, and the $w will carry the OCLC record number of the linking record as well as the $w of the Library of Congress record, etc.  Also, if the linking record has a uniform title, it is mandatory that this be in the $s, and this can be very generic for legal materials.  Large library systems (even WorldCat.org) use the $w record numbers as the search term for record linking in these fields, and this is going to be more common as RDA encourages more linking entry fields.

If this is pursued, I would strongly encourage it to be configurable by the library, so the library has the choice of whether their Koha catalog will operate as other systems using the $w as the search term in the search executed by selecting a field in a 78X linking entry field, or via the $a & $t.

Our Koha is configured to use the $w not only because it is the standard and offers the same functionality to our users as, e.g., WorldCat.org, but also because only a tiny minority of linking entry fields have distinguishing $a fields in them, and a search on the $t in these fields would retrieve so much as to be useless.  (E.g., $t Newsletter, $t Proceedings, $t Annual report, etc.)
Comment 2 Caroline Cyr La Rose 2022-09-08 17:02:20 UTC
Hi Heather,

I should maybe have specified that the situation I was describing did *not* use UseControlNumber. If UseControlNumber is activated, the exact control number in $w is searched in the control-number index, as you described in your use case.

When that syspref is deactivated, and you have values in 780/785 $a and/or $t the values are searched in the title index (or they were in 2018 when I wrote this bug report).

In the same link you provided https://www.loc.gov/marc/bibliographic/bd760787.html under subfield $a it says it's the main entry ("Main entry heading data (without the content designators) from field 100 (Main Entry-Personal Name), 110 (Main Entry-Corporate Name), or 111 (Main Entry-Meeting Name) in the related record.") meaning it should contain the author's name. 

My proposal was to search for the value in $a in the author index rather than the title index.

This bug is four years old, the code may have changed since.
Comment 3 Heather 2022-09-08 18:31:02 UTC
Hi, Caroline!

Thank you for clarifying!  Yes, then, you are correct!  It should definitely not be searching a 7XX $a in a title index, and should search for $a and $t in the correct indexes if UseControlNumber is not activated.

I think correct behavior of searches from linking entry fields is still very much in progress.  I hope some library staff who have UseControlNumber not activated can comment on this bug!

Best,
h2
Comment 4 Caroline Cyr La Rose 2022-09-08 19:02:27 UTC
I just tried it again in master with elasticsearch, and the problem is still there.

*UseControlNumber is off*

My record is
100 1# $aRowling, J.K.

245 10 $aHarry Potter and the Chamber of Secrets /
       $cby J.K. Rowling ; illustrations by Mary GrandPré.

780 00 $aRowling, J.K.
       $tHarry Potter and the philosopher's stone

785 00 $aRowling, J.K.
       $tHarry Potter and the prisoner of Azkaban

When I click on the link in the staff interface or the OPAC, the search is

'"ti,phr:Rowling, J.K. Harry Potter and the philosopher's stone"'