LCSH search results that redirect users from synonyms to the headings used can be very useful. For example, since I catalog a lot of agricultural reports, irrigation is a topic I frequently encounter. Authors use various terms such as drip irrigation, microirrigation, trickle irrigation for essentially the same process. A browse subject search for drip irrigation displays:
Drip irrigation
See: Microirrigation.
Users can click on Microirrigation and retrieve the various titles we have in our library about this process, including those where the author called it trickle irrigation. It might be difficult for users to think of all the synonyms for terms in order to retrieve comprehensively using keyword searches, especially if there are foreign language sources that might be of value. A casual user might easily be satisfied with a few titles on the subject, but one who requires more complete results might have to work a lot harder or possibly produce inferior scholarship due to unrealized poor retrieval.
The world war topic is admittedly very unwieldy, but that is hardly a representative example, is it? To me LCSH browse results seem more effective when there are fewer subheadings, as is very often the case. A savvy user might choose to use phrase keyword when browse subject searches are unhelpful and vice versa all on his own with the reference staff none the wiser. Thanks,
Jimmie
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Rinne, Nathan (ESC)
Sent: Thursday, March 12, 2009 11:56 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] Browse functionality (was Whose elephant is it, anyway? (the OLE project))
Qwen said:
"Specifically subject browsing is different - or perhaps subject
browsing LCSH is different. From what James says presenting LCSH as an
alphabetical index doesn't actually make sense - it simply overwhelms
the user with redundant information (I think I agree, and I think this
explains the findings in the user testing I describe above)"
Owen, LCSH as an alphabetical index doesn't make sense *to most* as it
is now, *but perhaps it could* if you had lists that contained
expandable terms like the "World War, 1939-1945 +" idea Jim offered.
That way, World War, 1939-1945 would not take up 25 screens, for
example, in the index browse of your catalog [25 screens will only get
you up through " World War, 1939-1945--Campaigns--Russia
(Federation)--Murmansk." In the LC catalog :)]), but would just be
reduced to one [expandable] term in such a list (initially at least).
~Nathan
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Stephens, Owen
Sent: Thursday, March 12, 2009 10:29 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: [NGC4LIB] Browse functionality (was Whose elephant is it,
anyway? (the OLE project))
I'm intrigued by the aspects of index browsing. I did some user testing
(with a very small group) during an OPAC redesign some years ago, and
concluded that index browse functionality was a great way of providing
access to authors/editors (and actors/directors for films,
composers/performers for music), journal titles and classmarks, but that
most other browse functionality was not useful in the context we were
working.
I can see an argument for subject browsing, but the testing showed that
the users either didn't use it, or didn't understand it when they did
use it.
From the discussion so far, and also a recent statement by Bernhard in
the 'What do users understand' thread when he says "LCSH makes sense
only when presented as an alphabetical list for browsing."- it seems to
me that browse is not necessarily a single function across all different
types of index.
Specifically subject browsing is different - or perhaps subject browsing
LCSH is different. From what James says presenting LCSH as an
alphabetical index doesn't actually make sense - it simply overwhelms
the user with redundant information (I think I agree, and I think this
explains the findings in the user testing I describe above)
I wonder - can anyone point me at (a) studies of user index browsing
behaviour in the context of web based searching, (b) methods of helping
users navigate a structured taxonomy or thesaurus?
Thanks,
Owen
Owen Stephens
Assistant Director: eStrategy and Information Resources
Central Library
Imperial College London
South Kensington Campus
London
SW7 2AZ
t: +44 (0)20 7594 8829
e: o.stephens_at_imperial.ac.uk
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Bernhard Eversberg
> Sent: 12 March 2009 14:45
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] Whose elephant is it, anyway? (the OLE project)
>
> Stephens, Owen schrieb:
> >
> > Just to understand what you are looking for in terms of Browse. The
> NLA implementation of VuFind has what I would regard as a Browse
> function - you can Browse the following:
> >
> > Names at http://catalogue.nla.gov.au/Browse/Names?browse=names&from=
> > Subjects at
> http://catalogue.nla.gov.au/Browse/Subjects?browse=subjects&from=
> > Callnumbers at
> http://catalogue.nla.gov.au/Browse/Subjects?browse=subjects&from=
> > Series at
> http://catalogue.nla.gov.au/Browse/Series?browse=series&from=
> >
> > Is this browsing as you mean it? If not, what would you require
> additionally?
> >
> Yes indeed! I'd say make the space narrower between the lines so you
> see
> more of it at once, but the way it works is just what I mean.
>
> > (also you question the scalability - what scale are you thinking of?
> How it is affected by the physical growth of the data. Does it get
> slower with every million data, and how much?
> How long is it to create the index? Is real-time updating possible?
> Or overnight only? How many hours per million records for a complete
> re-index? Does this time grow linearly or exponentially?
>
>
> This discussion has showed again that the term "browsing" is not
> well enough understood or defined. Therefore, I said "index browsing"
> all the time and "browsable index", to distinguish it from browsing
> a list of records. The latter is always a subset and it is always
> the result of a guess really. Or two: the user first guesses what
> terms might be the best to use, then the machine makes some sort of a
> "guess", but in a much different way, what records might match the
> query. The machine's guess is opaque, but the user takes it at face
> value and then browses this list, not seeing anything that has
narrowly
> escaped the machine's guess, and the larger the set is, the less
likely
> will they make another attempt or think about the appropriateness of
> their initial guess. This whole business is, I think, not well enough
> understood. Who, if not our profession, should understand it in a
> thorough way, and wouldn't that require a clear agreement about the
> terms we use?
>
>
> B.Eversberg
Received on Thu Mar 12 2009 - 15:58:17 EDT