I think the idea behind Summon is a step in the right direction in
regards to "next-generation" library catalogs.
Creating an index to all the things a library owns, licenses, or is
apropos to the specific information needs of a library's clientele is
something I've advocated for a while. [1, 2] Besides ordering search
results by date, author, title, or LIFO, our clientele expects these
search results to be ordered by relevance. [3] Calculating an accurate
relevance ranking score is not possible without amassing your data
into a single pile. Let alone the never-ending task of maintaining
changes in screen layouts, inconsistent protocol implementations,
network latency, and mis-matched field mappings, the lack of having
the data is an insurmountable limitation of metasearch.
In a networked environment where there is more information "out there"
as opposed to "right here", the idea of using the traditional library
catalog -- an inventory list of things owned by a library -- as the
primary library finding tool has grown long in the tooth. Yes, there
is still the need for a "catalog", just as there is a need to
accommodate many other technologies and processes, but this need is
not as great as others. For example, how many of y'all still support
CDROM workstations or servers hosting specialized bibliographic
databases?
From where I sit, Summon is an index. The folks of Serials Solutions
have aggregated the metadata (and full text) of many... serials. After
sending them the metadata describing your local content, the serials
metadata and local metadata are indexed together (using an open source
indexer called Lucene). Two interfaces to the index are then provided:
1) a Web-accessible interface through your browser, and 2) a
programmable interface (API) allowing librarians and developers to
create their own browser interface or other some such tools. The
foundation of Summon rests on two things: 1) having the local and
serials metadata, and 2) indexing the combination.
Libraries do not need Summon to provide similar functionality, but
Summon is convenient. Instead, create your own aggregation, and
practice with open access content. Visit the Directory of Open Access
Journals. [4] Use your collection development skills to decide what to
bring into your collection. Combine the skills of systems librarians
and acquisitions librarians to selectively harvest and mirror content.
Index the mirrored content along with the content from your local
"digital library", institutional repository, and book holdings by
combining programing skills with cataloging skills. Provide access to
the index in consultation with reference librarians. Once you get this
whole process under your belt, repeat the process with licensed
bibliographic content. The time and money you redirect into learning
how to creating your own index will come back to you a million fold
through the development of local skills and the satisfaction of "we
did it ourselves."
Finally, after creating the index, either through Summon or something
else, go beyond the service where you limit yourself to search and
find. The next step is to provide services against the returned items.
Figure out ways to make the content more useful. "Save the time of
reader" through compare & contrast, print, save, trace citation, trace
idea, make word cloud, graph, translate, summarize, rate, rank,
review, annotate, etc. [5]
Fun food for fraught on a Friday.
[1] http://www.library.nd.edu/daiad/morgan/musings/ngc/
[2] http://www.library.nd.edu/daiad/morgan/musings/ngc-in-15-minutes/
[3] http://infomotions.com/blog/2009/04/tfidf-in-libraries-part-i-for-librarians/
[4] http://www.doaj.org/
[5] http://pln.palinet.org/wiki/index.php/Future_catalogs:_food_for_thought
--
Eric Lease Morgan
University of Notre Dame
Received on Fri Jun 19 2009 - 10:44:00 EDT