[Bug 21302] New: Link in 780/785 should search for $t in title and $a in author
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Bug ID: 21302 Summary: Link in 780/785 should search for $t in title and $a in author Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs@lists.koha-community.org Reporter: caroline.cyr-la-rose@inlibro.com QA Contact: testopia@bugs.koha-community.org 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) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Carl <ctodd@hcc.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ctodd@hcc.edu -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Carl <ctodd@hcc.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|ctodd@hcc.edu | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Heather <heather_hernandez@nps.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |heather_hernandez@nps.gov --- Comment #1 from Heather <heather_hernandez@nps.gov> --- 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.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 --- Comment #2 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 --- Comment #3 from Heather <heather_hernandez@nps.gov> --- 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 --- Comment #4 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- 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"' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Lauren Denny <lauren_denny@sil.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauren_denny@sil.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |34482 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34482 [Bug 34482] Improve MARC21 7xx linking fields in bibliographic records [Omnibus] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.blouin@inlibro.com -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org