https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37168 --- Comment #1 from Phil Ringnalda <phil@chetcolibrary.org> --- Well, depends on your search target and how they've implemented what "Dewey" does, I guess. For OCLC, it's an any-call-number search, for LC it seems to be, rather comically, a not-dewey-call-number search. If your search is an LC call number, "Dewey" will return records where 050 matches it. If your search is a Dewey number, it will maybe return things with 641-5 in an LC call number for a search of 641.5, but not things where 082$a is exactly that. -- 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=37168 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Academy Patch complexity|--- |String patch CC| |david@davidnind.com See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37167 Assignee|koha-bugs@lists.koha-commun |david@davidnind.com |ity.org | -- 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=37168 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|david@davidnind.com |koha-bugs@lists.koha-commun | |ity.org --- Comment #3 from David Nind <david@davidnind.com> --- Unassigning myself, as I don't understand all the nuances here - including what the labels mean and purpose of the fields. I think it may be a bit more complicated than just changing one form, as there are others that are similar and use the same labels: - Acquisitions: adding to a basket from an external source - SRU Search fields mapping: Administration > Additional parameters > Z39.50/SRU servers > edit LIBRARY OF CONGRESS SRU > Modify (for SRU Search fields mapping). -- 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=37168 --- Comment #4 from Phil Ringnalda <phil@chetcolibrary.org> --- The advantage of SRU is that you can see what your searches are mapped to and change it. The disadvantage is that you can see.... The LC's SRU explain record at http://lx2.loc.gov:210/LCDB tells you what you can search by, not including any sort of call number search, so it's not mapped to anything, it's just a keyword search, and you get the same results whether you use either call number field in the search form or you use the keyword field. The LC's Z39.50 explain record at https://www.loc.gov/z3950/xml/lcdbz3950.xml tells you that you can search for Dewey call number and LC call number and in each case as a keyword or with right truncation or exact match or left-anchored with right truncation (which I think is a fancy way of saying starts with), and somewhere deep in the bowels of Koha we either choose one of those for the "LC call number" and "Dewey" fields for a Z39.50 search, or maybe we don't. Or maybe we choose one of the LC call number fields for both: today's 'test what you are actually getting' call number search for me is Perl, and if I do that as an LC call number search at LC Z39.50 I get no results, but if I do that as a "Dewey" search at LC Z39.50 I get two records, both of which have an 050 LC call number field which includes the string Perl. Do we actually do left-anchored with right truncation LC call number searches for the "LC call number" field, and keyword LC call number searches for the "Dewey" field? It would fit with the results I get. Or, do we specify the Dewey call number index and it is misconfigured in the LC server as LC call number? The results I get from the separately-implemented Z39.50 search in the advanced editor make me think this other one is doing something wrong, since in the advanced editor both the LC call number and the Dewey number searches give reasonable looking results from both OCLC and LC, finding whatever you search for in 050+09x local call number fields or 082+09x and not finding it in random spots or in the spot for the other flavor of call number. Personally, I'm looking for an exit strategy to get away from touching the Replace via Z39.50 search as quickly as I can while walking away backward so it doesn't sneak up and bite me on the back. -- 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=37168 --- Comment #6 from Phil Ringnalda <phil@chetcolibrary.org> --- Also fun, for SRU the thing with the label "Dewey" could be absolutely anything. Since in what we ship it's a fifth keyword search (Keyword (any), LC call number, Control number, Dewey, and the Publication year that for some reason you can't remap are all just keyword (any) searches) there's no reason why someone cunning wouldn't have mapped it to bath.lccn so they have a standard number search for the best way to find things published prior to the widespread use of ISBN. Be nice if SRU remapping also allowed label remapping. -- 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=37168 --- Comment #7 from Phil Ringnalda <phil@chetcolibrary.org> --- Okay, I see the path out of here. Even though a feature that's been broken for 14 years without anyone filing a bug about it seems like a sign to just remove it, we should probably leave it in and fix it, so the hypothetical sales manager doesn't have to face the question from a public library about why we only have an LC call number search and no Dewey search in the Z39.50 form, with no idea what the answer is and an actual answer that wouldn't be understood by anyone but a cataloger. C'est la vie, it's well below the fold where you have to scroll down in the popup to ever see it, having it won't hurt anyone. So, search the catalog -> Z39.50 should map callnum to keyword, because no Z39.50 attribute exists to say "search this as an LC call number, a Dewey classification number, a NLM call number, a NAL call number, and a UDC classification number." It's a shame that bug 37167 exists and one term can clobber another when they are mapped to the same field, but not blocking because that already exists for title, author, and subject. And the Dewey search should search Dewey, not LC, for the first time in its life. -- 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=37168 --- Comment #8 from Phil Ringnalda <phil@chetcolibrary.org> --- (In reply to Phil Ringnalda from comment #7)

It's a shame that bug 37167 exists and one term can clobber another when they are mapped to the same field, but not blocking because that already exists for title, author, and subject.

It's a shame my clipboard failed me, that should have said bug 37224 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37168 --- Comment #10 from Phil Ringnalda <phil@chetcolibrary.org> --- Sigh. Let Dewey be Dewey depends on mapping callnum to Keyword, which depends on teaching z3950_search_args that someone might want to use Keyword, because currently catalogue/search.pl, the only thing that might, instead maps an explict search of "Keyword" to Title rather than Keyword (any). -- You are receiving this mail because: You are watching all bug changes.