[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