[Koha-bugs] [Bug 10078] show location facet for all

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10078

--- Comment #9 from David Cook <dcook at prosentient.com.au> ---
(In reply to Katrin Fischer from comment #8)
> Hm maybe for others reading this we should clarify:
> 
> > 1) If you limit on Branch A and location D, you should get no results in
> > your scenario. 
> 
> That would be how we want it, but it's not going to happen as for the facets
> always everything that appears in the record is taken into account. So all
> item information is mixed together - if you have a branch and a location
> appearing in your record, the facets will show up, even if the information
> belongs to different items.
> 
> > 2) In what scenario would you be able to use both those facets? (Using the
> > Advanced Search, you could, but that's unrelated to the facets.) 
> 
> Yes, advanced search can give confusing results too - but I think it's a lot
> less obvious and users are not so likely to try.
> 
> > If you choose Branch A from the Libraries facet, you would only be presented
> > with location C as a Locations facet. If you choose location D, you would
> > only be presented with Branch B as a Libraries facet.
> 
> Unfortunately that's not the case - see explanation above.
> 
> > I don't think it's an indexing issue though. From what I've seen so far, it
> > seems to me that DOM and GRS-1 fill the same indexes, they just do it in
> > different ways. 
> 
> With DOM indexing, I think, the issue could be solved, but not with GRS -
> and it's currently not implemented.
> 
> Just trying to explain why I think this change is likely to cause some
> confusion.

Mmm, I think I understand what you're saying now.

Basically, 1 bibliographic record can contain multiple items from multiple
different branches, multiple different locations, etc. 

As a result, the facets always include information from ALL the items attached
to a bib record. 

So even if you "narrow" your search results using one facet, you'll still have
facets and facet values showing up for other branches, locations, etc...if a
bib record in the results ALSO contains items that have other branches,
locations, etc. 

That certainly is a problem.

It seems to be a problem with every item-level facet though. Branches and
itemtypes being perhaps the most obvious, although location would certainly
fall into that as well. 

--

As for a solution...

I still don't think that DOM indexing would fix this. Admittedly, I am not very
experienced with it, but from what I can tell, DOM indexing seems to use XPATH
to select particular MARCXML nodes and then puts them into defined indexes
(probably defined in bib1.att). The end result is the same as GRS-1, but I
think it's much simpler and perhaps more robust than GRS-1. 

I think a solution would need to take into account item-level limits after the
MARC search results are returned from Zebra. As far as I know, Zebra thinks
only in terms of bibs and whether a bib is tied to a certain index. I imagine
that we would have to do a certain amount of post-processing to weed out any
inapplicable items...and then suppress that bib record, if there are no items
that match our item-level limits.

I imagine that would get fairly messy though, and run into the same problems
that we're already encountering with post-processed suppressed bib records :/
(such as the number of results not equalling the number at the top of the page
and the number of records appearing per page being unequal).

I'm not sure that there's a way to query Zebra and check that all the 952s have
a certain item-level limit. 

Again, I'm no indexing expert, but with indexing...I assume that each index is
filled with words or phrases and each of these words or phrases is then linked
to an entire record. 

I might be wrong (and am almost certainly missing some of the finer points and
technical details), but that's how I understand the Zebra indexing to work
whether DOM or GRS-1.

-- 
You are receiving this mail because:
You are watching all bug changes.