[Koha-bugs] [Bug 14567] Browse interface for OPAC

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

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

--- Comment #9 from Heather <heather_hernandez at nps.gov> ---
(In reply to Robin Sheat from comment #8)
> (In reply to Heather from comment #7)
> > I tried it out here: http://browse.koha.catalystdemo.net.nz
> > It seems nice, but it doesn't seem like a true browse to me--what I look for
> > in a browse is to enter a search term, and have the results returned to be
> > what is exactly before my searched term in the given index, then where the
> > searched term is/would be, then what is exactly after the searched term in
> > the index.  So there would be no need for "exact, fuzzy, really fuzzy,"
> > because when I browse an index, I want the results to be what is before and
> > after that term in the given index.
> 
> There are technical reasons why this is particularly hard, essentially that
> pulling the index terms out in order is not something that can readily be
> done without patching Elasticsearch itself, which I'm considering out of
> scope of this project :)
> 
> However, when I thought about it with that in mind, I got to wondering what
> the point of a complete alphabetical index really is to a library user.
> There's no semantic relationship between a word that starts with R and a
> word that starts with S, why would it be meaningful to put one beside the
> other. A subject of "Symbols" is not closely related to a subject of
> "Tarantulas", just because they're alphabetically close. However, an author
> name of "Stephen" is (sorta) semantically related to an author name of
> "Steven", if the user hasn't quite remembered the whole name or the spelling.
> 
> > That said, when I searched "exact" for "Author": Rowling
> > I get:
> > Rowling, J. K.
> > Rowling, J.K.
> 
> This is a GIGO situation with the data that is the result of it not being
> terribly cleanly catalogued in the first place. I tend to prefer working
> with data like this as it is better at highlighting odd edge cases.
> 
> I've been thinking about ways to correct for cases like this (where it's
> just a punctuation or whitespace difference), but it presents some issues
> relating to how it'd be done reliably with no false positives. So I've
> postponed further thinking about it for now. In an ideal world, everyone
> will be using authorities anyway, and this won't happen :)
> 
> > This is nice, but, again, it doesn't seem like a "browse" to me--these are
> > just search results.  When I click the names, I get the exact same search
> > results as I do via Advanced Search, Author Phrase:
> 
> It is doing pretty much the same thing as a search, yes. Essentially, it's
> goal is to be an easier way to look for some specific things, possibly when
> you're a bit unsure about the details. I think that subjects will benefit
> from this the most actually, as scrolling through
> "Birds -- Kakapo", "Birds -- Kea", "Birds -- Kiwi" is something that has
> real use. Additionally, a search for "Kiwi" will also find "Birds -- Kiwi"
> (though this behaviour isn't visible in the data that's currently on the
> test site due to the way it's catalogued.)
> 
> > If I Browse via "Fuzzy" with: Rowling
> > I get these results:
> > Rollins, Henry,
> > Rowland, Sarah-Jane.
> > Rowlands, David.
> > Rowlands, Gena.
> > Rowling, J. K.
> > Rowling, J.K.
> > 
> > Which does show me some results which should be in the author index above
> > Rowling, but I get no results that should be in the author index after
> > Rowling.  "Really fuzzy" is the same.
> 
> I'll double check this, but it's most likely that in this database, there's
> just nothing further that matches. Actually, in this case, fuzzy and extra
> fuzzy will be doing the same thing as there's a max edit distance limit for
> the fuzziness, and I think it will have been hit. I'm probably going to
> remove the "extra fuzzy" option anyway, it risks being more confusing than
> anything.
> 
> > I would like to see the searched for term in the middle of hits that occur
> > before and after it in the index, e.g. something like this (an author
> > "Browse" result, with made up examples below Rowling, J.K.):
> 
> But why? What does an alphabetically adjacent author tell you about that set
> of authors, and what does it provide that a library user would find useful?
> (Technical reasons for why this is hard aside.)
> 
> > I hope this is helpful!  --h2
> 
> Thanks for checking it out!

Hi, Robin!

One of the main purposes of a complete alphabetical browse for the library user
is exactly what you mentioned: when the user is unsure of the spelling, but has
most of it, e.g., "Stephens" or "Stevens," or something like "Ralphs," or
"Rolphs."  And, with subjects, the user will receive a list with all
subdivisions listed & will see those, rather than just search results that
don't show the subject terms.

Yes--GIGO is an issue in the above browse, and ideally all access points are
under authority control, but the browse is useful for libraries that have order
records that are not yet cataloged, and who only do their authority
control/cataloging upon receipt of the item.  The above issue in the spacing of
"Rowling, J. K." could occur with order records vs. fully cataloged & received
items.

The alphabetic browse is also invaluable for the catalogers on the staff side
doing authority control--it's the easiest way to spot heading variations.

In the Koha public opac, a basic search always gives you a list of search
results that never shows subject terms--the facets on the left show *some*
subject terms but, e.g., if you do a basic keyword search in your demo catalog
for "Birds," the subject facets on the left have subdivisions broken out & not
associated with the main heading:
    Animals (2)
    Birds (6)
    Maoritanga. (1)
    Mystery and suspense stories. (1)
    Mythology, Maori. (1)
    Natural history (2)
    New Zealand (3)
    New Zealand. (3)
    Penguins. (1)
    Pictorial works. (1)
    Show more
(It's the same in our catalog, i.e. this search only gives you facets on the
left that are main headings, not headings *with* their subdivisions:
http://keys.bywatersolutions.com/cgi-bin/koha/opac-search.pl?q=ships)

So an alphabetical browse that does return subject terms with their
subdivision, like in your example, would be useful to a user, e.g.:
Birds--Kakapo.
Birds--Kea.
Birds--Kuwait.
Birds--Pictorial works.
Birds--Qatar.

(BTW, the Authority Search in the demo catalog has a problem--do an authority
search with default options & the term "Birds" & you get:
Software error:
Can't call method "each" on unblessed reference at
/opt/kohaclones/browse/Koha/SearchEngine/Elasticsearch/Search.pm line 265.
For help, please send mail to the webmaster ([no address given]), giving this
error message and the time and date of the error.")

Do a similar authority search in our catalog for ships:
http://keys.bywatersolutions.com/cgi-bin/koha/opac-authorities-home.pl?op=do_search&type=opac&operator=contains&value=ships&marclist=any&and_or=and&orderby=HeadingAsc

And you get close to a subject heading browse result--the only problem is that
it returns only main headings, not an alphabetic list of the terms *with
subdivisions* as used in the records, which would be very useful to the user. 
I bring this up because, IMO, as it is, authority control/authority search is
not an alternative to a true alphabetical catalog browse for the public opac
user, of subject terms with subdivisions as used in the catalog.

I hope this is helpful!  Best,
--h2

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