At the risk of interpreting the original question incorrectly, we
have had decent success using the Google Search Appliance to
facilitate search across the enterprise (university):
* Buy the Appliance.
* Feed it one or more URLs.
* Wait for it to crawl.
* Customize the user interface.
* Allow people to use it.
While we haven't done so, it would not be too difficult to implement
a sort of federated search within the Appliance's interface. This
could be done in a number of ways:
1. Acquire bibliographic data and
feed to directly to the Appliance
via the (poorly) documented SQL
interface.
2. Acquire bibliographic data, save
it as HTML files, and allow the
Appliance to crawl the HTML.
3. License access to bibliographic
making sure it is accessible through
some sort of API, and write a Google
OneBox module that queries the data,
and returns results as a part of a
normal Google Appliance search.
The larger Google Appliance costs about $30,000 but you purchase it,
not license it. No annual fees. That will buy you the ability to
index 500,000 documents. When it comes to a bibliographic database
(such as a subject index or a library catalog) that is not really
very much.
We here at Notre Dame did implement Option #3, but it queries the
local LDAP sever to return names and addresses of people, not
bibliographic citations. [1, 2] I did write a OneBox module to query
our catalog, but we haven't implemented it, yet. It will probably
appear as a part of the library's Search This Site functionality.
In short, I think a Google Appliance is an expensive but viable option.
[1] Search for a name (ex: Hesburgh) at http://search.nd.edu/
[2] OneBox source code - http://tinyurl.com/6ktxot
--
Eric Lease Morgan
Hesburgh Libraries, University of Notre Dame
