Bug 8589 - Advanced Search for itemtype and location produces some results that are not useful
Summary: Advanced Search for itemtype and location produces some results that are not ...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-07 18:38 UTC by Melia Meggs
Modified: 2023-05-02 10:44 UTC (History)
4 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 Melia Meggs 2012-08-07 18:38:59 UTC
When searching for a list of circulating books in New York, I can run a search
specifying an item type of "circulating item" and a location of "New York" from Advanced Search.  The search returns some results that look like this:

Item type            Location  	        Call Number	         Status
Book                 New York           500 GRA (Browse Shelf)	 Not for loan		
Book	             San Francisco	500 GRA (Browse Shelf)	 Not for loan
Circulating item     Atlanta		500 GRA (Browse Shelf)	 Not for loan
Circulating item     Cleveland          500 GRA (Browse Shelf)	 Available
		
The last two items are circulating items, and the first item has a location of New York, but there aren't any items that are BOTH circulating AND in New York, so this is not a useful result.
Comment 1 Jared Camins-Esakov 2012-08-07 19:02:57 UTC
In order to fix this you are going to need composed indexes on the item field and a search structure capable of handling a query of this complexity. I proposed the latter in my search rewrite, but I think there is really no point to the former until there is a query parser capable of using a composed index.
Comment 2 Owen Leonard 2012-08-07 19:06:05 UTC
I can confirm this in our catalog:

http://search.myacpl.org/cgi-bin/koha/opac-search.pl?idx=kw&q=chilton&idx=kw&idx=kw&limit=mc-itype%2Cphr%3ACIRC&limit=branch%3ACOV&sort_by=relevance&do=Search

This search for keyword "Chilton," item type "Circulating," and library "Coolville" returns results at that library which are *not* of type "Circulating" (reference copies).
Comment 3 David Cook 2022-08-22 01:37:22 UTC
Is this still an issue?
Comment 4 Katrin Fischer 2022-08-22 06:22:46 UTC
(In reply to David Cook from comment #3)
> Is this still an issue?

Yes, because items are not treated individually in search.
Comment 5 David Cook 2022-08-22 06:44:31 UTC
(In reply to Katrin Fischer from comment #4)
> (In reply to David Cook from comment #3)
> > Is this still an issue?
> 
> Yes, because items are not treated individually in search.

What I should've said is that I don't understand the problem. 

Although as I write that out... I think that I understand now. The problem is that one item fulfils one criterium of the search query and a different item fulfils another criterium of the search query, so overall the search query gets the hit, but the hit doesn't include an item that fulfils all the criteria. 

Yeah that's interesting.
Comment 6 Katrin Fischer 2022-08-22 07:43:40 UTC
(In reply to David Cook from comment #5)
> (In reply to Katrin Fischer from comment #4)
> > (In reply to David Cook from comment #3)
> > > Is this still an issue?
> > 
> > Yes, because items are not treated individually in search.
> 
> What I should've said is that I don't understand the problem. 
> 
> Although as I write that out... I think that I understand now. The problem
> is that one item fulfils one criterium of the search query and a different
> item fulfils another criterium of the search query, so overall the search
> query gets the hit, but the hit doesn't include an item that fulfils all the
> criteria. 
> 
> Yeah that's interesting.

Yep, that's it :) I've often struggled to explain why that is to users as well. The item search is exact, but for the catalog search (doesn't matter if Zebra or Elastic) this is an unresolved issue.
Comment 7 David Cook 2022-08-23 00:25:35 UTC
(In reply to Katrin Fischer from comment #6)
> Yep, that's it :) I've often struggled to explain why that is to users as
> well. The item search is exact, but for the catalog search (doesn't matter
> if Zebra or Elastic) this is an unresolved issue.

I'm not familiar with Koha's integration with Elastic, but I think it is solvable with Elastic, since it allows different data types and nested data structures. We use Elastic for other projects, and we've got it so that you can do an "AND" across different values in that deeper nested structure. 

We're going to be looking more at Koha's Elastic integration at some stage, so probably will be commenting more in the future...
Comment 8 Ray Delahunty 2023-05-02 10:44:07 UTC
Is there any way this problem can be fixed? It causes us lots of problems as we are a quite complex multi-site setup with collections at various college libraries, with some cataloguing policy variances across colleges that makes the 'not useful' results count sometime horridly high. We really need searches across the three ‘tiles’ of the Advanced Search  (keyword area at the top, the tabs area in the middle, and the limits across the bottom) to work ‘correctly’.  If you look at our OAPC https://libsearch.arts.ac.uk/cgi-bin/koha/opac-search.pl you can see we are having to add multiple ‘special collection’ searches (at CSM and LCF colleges for now, more wanted) but even that isn’t perfect. We should be able to have Special Collections in the tab area and the library limit at the bottom working together and not giving results that are not useful, as many currently are. Even searching on all special collections and then limiting by facets (homebranch) doesn’t work properly either as ‘not useful’ results are included that way too.