[Sigia-l] integrated catalogues?

Tito Sierra tito_sierra at ncsu.edu
Fri Oct 21 11:09:49 EDT 2005


Dedicated search interfaces for specific collections enable more  
specialized search options because you can make assumptions about the  
items in the collection and tailor your search interface around these  
assumptions.  For example some collections have reliable "Published  
date" metadata for all items in the collection allowing users to  
search by date range, or sort by date, which may be very useful in  
some contexts.  Some collections have "richer" metadata than others.

The drawback of having many different dedicated search interfaces is  
that the user now must navigate to the right tool to get their  
information.  Depending on your information architecture, this may be  
more or less difficult.  Since you mentioned the British Library, I  
think they actually do a good job distinguishing their various  
collections through the use of simple titles, icons and short  
descriptions:

http://www.bl.uk/catalogues/listings.html

I don't think this is the case for many library websites where  
collections are distinguished from one another by title only.

As Steve Toub mentioned, federated search tools (aka metasearch) try  
to address the inconvenience issue by allowing the user to search  
multiple collections all at once.  Putting aside the latency issue of  
running a search on 'n' systems all at once... an assumption here is  
that all items in the collection superset have a common set of  
metadata that can be indexed and displayed in a similar way.  So one  
drawback is you may lose some of the specialized search options in  
the process.  Depending on you users and the collection type this may  
be either acceptable or disastrous.

But how do you display results from multiple collections?  Do you  
show the top results in each collection with links to see more?  Or  
do you try to de-dupe and merge results?  If de-dupe and merge, how  
do you provide a useful relevancy rank for combined results from  
different systems (each using its own relevancy ranking algorithm)?

Google and A9 offer some creative approaches the distributed search  
problem:

Google:
http://www.google.com/search?q=the+tipping+point

On my web browser, about 50% of the time, this search will show as  
the first results a bookstack icon with a link to see "Book results  
for the tipping point".  Google thinks I might be looking for a book  
(which is true in this case) and directs me to their Google Print  
search.  They do similar things for image searches, article searches,  
addresses searches etc.  In this example we have a dedicated search  
tool ("Google Web") that suggested another dedicated search tool  
("Google Print") based on the user's search term.  The Google model  
(if one can call it that) optimizes for the case where users just  
want a single box where they type in a few words and get some results  
quick.

A9:
http://a9.com/

A9 on the other hand allows the user to predefine a personal  
collection of dedicated search tools.  For example I have can search  
Wikipedia, NYTimes.com and the Seattle Public Library all at once.   
Results are displayed in separate multiple columns on the same page.   
The A9 model optimizes for users that have some familiarity with  
existing dedicated search tools and want the convenience of being  
able to search them using one interface.

I think we will see many interesting innovations in this area in the  
next few years.

Tito

----

Tito Sierra
Digital Library Initiatives
North Carolina State University


On Oct 20, 2005, at 10:46 PM, Steve Toub wrote:

> My sense is that this is largely a technical limitation (and a lack  
> of imagination?) of having separate silo systems powering different  
> databases.
>
> There is a category of software in the library world called  
> federated searching metasearching (current thread on this on  
> WEB4LIB-L) but to execute the parallel queries on silo systems,  
> merge and de-dupe takes far longer than what users have come to  
> expect on something like Google Scholar.
>
> NSCU Libraries are doing interesting work along the lines of what  
> you're thinking. See their presentation on "In Search of the Single  
> Search Box: Building a "First-step" Library Search Tool"
> http://www.diglib.org/forums/spring2005/presentations/morris0504.htm
> http://www.lib.ncsu.edu/dli/staff/tsierra/dlf-ncsu-qs-demo.wmv
>
>     --SET
>
> Steve Toub
> California Digital Library
>
>
>
>
>
> Patrick Kennedy wrote:
>
>> Anyone care to discuss the relative pros and cons of integrating a  
>> bunch of databases/catalogues under one search interface, versus  
>> separate interfaces?
>> For example, anyone here work on the British Library website? They  
>> have quite a few catalogues, with separate search interfaces for  
>> (and different ways of presenting results, different sets of  
>> advanced options etc etc etc)
>> Is this a technical limitation? Like, each is in a different  
>> database and so they haven't got around to integrating them....or  
>> is there a user experience benefit in doing it this way?
>> Obviously if you're looking for a particular type of content  
>> (manuscript as opposed to photo) you might expect to use a  
>> different search interface, but couldn't a drop-down list with  
>> several options handle this? Or even simply formatting each result  
>> record based on the type of material it represents?
>> Any thoughts?
>> And yes I am thinking specifically within the context of a library  
>> website.
>> cheers
>> Pat
>>
> ------------
> When replying, please *trim your post* as much as possible.
> *Plain text, please; NO Attachments
>
> Searchable Archive at http://www.info-arch.org/lists/sigia-l/
>
> IA 06 Summit.  Mark your calendar.  March 23-27, Vancouver, BC
>
>
> ________________________________________
> Sigia-l mailing list -- post to: Sigia-l at asis.org
> Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
>




More information about the Sigia-l mailing list