> As I recall, one of the issues with metasearch was that the searching itself
> put a great burden on the vendor systems -- since they received hits for
> every search done, even those not terribly relevant to their topic or
> offerings.
There are many issues with metasearch. Ignoring ranking, performance,
and other technical issues, it causes headaches with services that are
licensed by seats or number of connections. If every freshman throwing
a broadcast search for articles on legalizing dope for a rhetoric
paper also hits high priced engineering databases that limit
connections, the engineering faculty and grad students may find
themselves locked out of key resources and the aforementioned freshman
doesn't do any better.
> Moving the search out closer to the user, and having the vendors
> only do delivery, should be appealing to them. What doesn't work, IMO, is to
> replicate this search functionality on hundreds of different systems. We
> need a middle man (or two or three) to provide a robust search function that
> libraries can then hook into. That search system can be optimized for search
> while libraries provide the UI and the A&I vendors do fulfillment.
The issue of sharing metadata is a big one, and some places won't want
to play ball. However, the RFP process, negotiations, and other means
are available to communicate that siloed products have far less value
to a library and its users. Not that they'll give in every time, but
ultimately enough libraries have to be willing to walk if vendors are
going to have enough incentive to cooperate. As soon as we say we have
to have anything and are unwilling to consider alternatives, we
relegate ourselves to the status quo or worse.
kyle
Received on Wed Jun 17 2009 - 12:33:15 EDT