Re: [IUG] Cataloging for Encore

[John Wenzler <jwenzler at sfsu dot edu>]

This is an interesting observation that I have been thinking about 
lately. If keyword searching with relevance ranking is going to be 
the primary way that people access the catalog, traditional authority 
records that re-direct users from one term to another may be much less useful.

I thought about this recently when I did a subject search in our 
catalog for "consumerism." Because "consumerism" is not a preferred 
term, I got an authority record that suggested that I try 
"<http://opac.sfsu.edu/search/d?Consumer+protection&search_code=a>Consumer 
protection"  or 
"<http://opac.sfsu.edu/search/d?Consumption+%28Economics%29&search_code=a>Consumption 
(Economics)" instead. But this doesn't work when I try a Right 
Results keyword search for "consumerism" because the keyword search 
only looks at the words in the bib record, and "consumerism" wasn't 
in a lot of the bib records that were relevant to me because it is 
not a preferred subject term.

I was looking at this in the context of a little informal study I was 
doing comparing the effectiveness of relevancy ranking that I get 
with RightResults to the relevancy ranking that I get with the 
LibraryThing tags. For me at least (I don't know how I could evaluate 
relevancy objectively), the results that I got with the LibraryThing 
tags often seemed to be more interesting and useful than what I get 
with Right Results. For example, you don't get interesting books like 
Affluenza : the all-consuming epidemic or Why we buy : the science of 
shopping when you do a Right Results search for "consumerism" in our catalog.

John

At 07:35 AM 12/17/2007, you wrote:
> On Dec 17, 2007 9:28 AM, Wynn, Stephen <swynn at truman dot edu> wrote:
>
> > I spoke last week about III's next-generation interface Encore, with an
> > III rep who told me that whenever they do a demo, the catalogers present
> > get very excited about the idea of adding tags in Encore. ..
>
>
>
> > Since "Mountain biking" is a SEE reference in the authority record for
> > "All-terrain cycling," why do you need to add it as an Encore tag?
>
>
> The problem with SEE references in the catalog is that it results in an
> extra step for the user. A subject search on "mountain biking" yields the
> decidedly unfriendly message:
>
> "* Mountain Biking *" is not used in this library's catalog.
> *All terrain cycling *is used instead.
> Try a search for All terrain
> cycling<http://mail.google.com/search/d?All+terrain+cycling>
>  .
>
> "All terrain cycling" is an active link, but the user still has a no-hit
> search in front of him.
>
> There's always the question of how many users throw a subject search at the
> catalog as a first run. A lot of catalogs default to keyword searches, one
> reason being to mitigate the general out-of-stepped-ness (is that a word?)
> of LCSH terms. However a keyword search only pulls up records including the
> search term. In our catalog at Temple, Zinn's cycling primer would not be
> found in a keyword search for "mountain biking" because neither the phrase
> nor the words "mountain" nor "biking" appear anywhere in the record.
>
> One could go further and note that "Mountain biking" is not an
> immediately related subject for "Outdoor recreation" nor for "Sports" (I
> think you can get to them by traversing the hierarchy). Several works in
> Temple's catalog cover mountain biking, but carry one of these subjects
> instead of "All terrain cycling."
>
> So a user using the term "mountain biking" in our catalog would completely
> miss Zinn's cycling primer in a keyword search, and experience "searchus
> interruptus" when doing a subject search (which he may not even do).
> Presumably a tag would mitigate both unsatisfactory experiences for the
> user.
>
> Of course, he could form a nerdy complex search involving parentheses,
> truncations, and OR statements but mountain biking is supposed to be cool.
> :)
>
> Byron
>
> --
> Byron C. Mayes, MLS
> Head, Library Systems & Technology
> Temple University * Philadelphia, PA
> ByronC dot Mayes at temple dot edu
>
>
> --- StripMime Report -- processed MIME parts ---
> multipart/alternative
>   text/plain (text body -- kept)
>   text/html
> ---
> --
> This message was distributed through the Innovative Users Group INNOPAC list
> Public replies:  INNOPAC at innopacusers dot org
> Update your subscription options: 
> http://innopacusers.org/mailman/listinfo/innopac


--- StripMime Report -- processed MIME parts ---
multipart/alternative
 text/plain (text body -- kept)
 text/html
---