[Koha-bugs] [Bug 33277] Correctly handle linking subfields with no defined thesaurus
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Fri Mar 24 00:30:22 CET 2023
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33277
--- Comment #31 from Janusz Kaczmarek <januszop at gmail.com> ---
(In reply to Nick Clemens from comment #26)
> (In reply to Janusz Kaczmarek from comment #25)
> > Nick, I have looked into the corrected version. I see one problem: with
> > Zebra, for:
> >
> > 655 7 $a Literatura angielska $2 DBN
> >
> > you search first for: "Literatura angielska + DBN" and, since there is no
> > 040 $f, there is the second query for: "Literatura angielska + undefined'
>
> The second query passes "notdefined" - not undef
[...]
Nick, thank you very much for you comment. My eyes misses the difference
between 'notdefined' for 'z' without 040 $f and 'notspecified' for '|'. I am
sorry for unnecessarily bothering you.
I understand your explanation about hardcoding Subject-heading-thesaurus but,
to be sincere, I do not share this argument. Firstly, in Zebra also we have
the definitions in the configuration file--if somebody changes there something
he/she shouldn't, its his/her fault. And secondly, which is IMHO more
important, shall we than, in the next step, hardcode also
Heading-use-main-or-added-entry for 008/14, Heading-use-series-added-entry for
008/16, Heading-use-subject-added-entry for 008/15 when we will be wanting to
narrow the search for linking even more specifically (which should definitely
be done at some point)? So, I am still not convinced if it is the right
idea...
--
You are receiving this mail because:
You are watching all bug changes.
More information about the Koha-bugs
mailing list