Excluding fields from the OPAC search
Hi In our library we use Koha 18.11.01 with Debian GNU/Linux 9. Is it possible to switch off fields in the OPAC for the keyword search or for the search in general so that they cannot be searched? (e. g. MARC 952$e the source of acquisition, or MARC 952$x the non-public note) How do other libraries deal with the fact that, for example, the source of acquisition unnecessarily inflates the search result? Best wishes: Michael Kuhn -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik@adminkuhn.ch · W www.adminkuhn.ch
(e. g. MARC 952$e the source of acquisition, or MARC 952$x the non-public note)
If these are indexed by default I think that should be considered a bug. -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org
Hi, unfortunately the problem is a bit more complicated. :( I think since our switch from grs-1 to dom indexing, the kw index includes the whole record, where before that switch it was 'everything that is indexed'. So changing the configuration of individual fields/indexes won't make a difference. See: *Bug 15050* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050> - Nonpublic note searchable from OPAC I am not sure if this is solved already with Elasticsearch. Some things you could do to avoid issues is linking 952$e to a vendor record using the id. I've been thinking it would be nice if we had a value builder to do this for a while. If you add items from acquisition it will also fill source of acquisition with the id, so that would make things more consistent. For internal notes I think a good rule of thumb would be to avoid using personal names whenever possible. For some use cases internally agreed on codes or the cardnumber might work. Having a separate feature for adding notes that don't end up in the MARC records (and possible exports, OAI etc.) might be a good idea anyway. Hope this helps Katrin On 06.10.21 13:04, Owen Leonard wrote:
(e. g. MARC 952$e the source of acquisition, or MARC 952$x the non-public note) If these are indexed by default I think that should be considered a bug.
-- Owen
Sometimes you really do need human readable non-public information. Especially if you have a collection like ours, with a lot of unique material, stashed all over the building. We have information the staff needs that we don't necessarily want publicly available. For instance, locations of rare and valuable material. Though our OPAC says 'storage' for these, if you know what to search for they will come up in a keyword search. Non public notes and the ability to really obscure certain things in the OPAC are in MARC for a reason, it can be a security issue. I would be interested to know if this is also happening with elasticsearch. We haven't made the switch, but if elasticsearch does the right thing in this respect, it would be worth it to change over. Elaine VWML <https://vwml.org> On Wed, Oct 6, 2021 at 4:18 AM Katrin Fischer <katrin.fischer.83@web.de> wrote:
Hi,
unfortunately the problem is a bit more complicated. :(
I think since our switch from grs-1 to dom indexing, the kw index includes the whole record, where before that switch it was 'everything that is indexed'. So changing the configuration of individual fields/indexes won't make a difference. See:
*Bug 15050* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050> - Nonpublic note searchable from OPAC
I am not sure if this is solved already with Elasticsearch.
Some things you could do to avoid issues is linking 952$e to a vendor record using the id. I've been thinking it would be nice if we had a value builder to do this for a while. If you add items from acquisition it will also fill source of acquisition with the id, so that would make things more consistent.
For internal notes I think a good rule of thumb would be to avoid using personal names whenever possible. For some use cases internally agreed on codes or the cardnumber might work. Having a separate feature for adding notes that don't end up in the MARC records (and possible exports, OAI etc.) might be a good idea anyway.
Hope this helps
Katrin
On 06.10.21 13:04, Owen Leonard wrote:
(e. g. MARC 952$e the source of acquisition, or MARC 952$x the non-public note) If these are indexed by default I think that should be considered a bug.
-- Owen
_______________________________________________
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Hi Katrin On 6 October you wrote:
unfortunately the problem is a bit more complicated. :(
I think since our switch from grs-1 to dom indexing, the kw index includes the whole record, where before that switch it was 'everything that is indexed'. So changing the configuration of individual fields/indexes won't make a difference. See:
*Bug 15050* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050> - Nonpublic note searchable from OPAC
I am not sure if this is solved already with Elasticsearch.
Some things you could do to avoid issues is linking 952$e to a vendor record using the id. I've been thinking it would be nice if we had a value builder to do this for a while. If you add items from acquisition it will also fill source of acquisition with the id, so that would make things more consistent.
In our case we are not using the Koha acquisition, so the vendor name is not automatically filled, but manually. If the vendor name is Smith a keyword search for "Smith" will not only find authors, subjects etc with the string "Smith" but also vendors - this is not desired since it often tampers the search result considerably. To avoid this as a workaround we have now (via SQL) added the leading string "xx" for every vendor name (e. g. "xxSmith") and have reindexed the Koha instance. Now a search for just "Smith" will no more find the vendor names. If we want to search for a certain vendor name we will just search for e. g. "xxSmith".
For internal notes I think a good rule of thumb would be to avoid using personal names whenever possible. For some use cases internally agreed on codes or the cardnumber might work. Having a separate feature for adding notes that don't end up in the MARC records (and possible exports, OAI etc.) might be a good idea anyway.
This is good advice! And yes, we would also like a separate feature for adding notes that don't end up in the MARC records. Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik@adminkuhn.ch · W www.adminkuhn.ch
participants (4)
-
Elaine Bradtke -
Katrin Fischer -
Michael Kuhn -
Owen Leonard