Our ERM system has a short list of article databases mapped to each of these subjects, so it possible to return a target list of eight databases based on a user query. I would just need to combine and de-dupe the databases associated with our library subjects. Jonathan, the only reason our current implementation doesn’t just send the user’s query into a targeted metasearch environment, or a specific database, is because our production metasearch application can’t handle targeting of this sort. When I have some time I would like to continue with this experiment to create a explicit database recommendation service. This would ask the user to describe the topic they are interested in a few words and it would output a listing of suggested databases to send their search to.

That said, David’s comment is spot on. If the user types in terms that are subject specific such as “toxicity”, we can make some inferences on this. If the user enters something vaguer than auto-selection of database targets results in false positives. Taking David’s query example of ‘california indians’, my system recommends a variety of subjects including Education, Psychology and History. This false positive problem could be addressed algorithmically by dropping recommendations that are too dissimilar from each other. In other words only providing recommendations when there is a clear topical signal. Again, this is something I would like to experiment with in the future. It’s unclear that this approach will solve the problems John W. describes with metasearch, but we ought to experiment just in case.

OCUL, a Canadian consortium of university libraries from Ontario, negotiated with the major publishers (Elsevier, Springer and the other usual suspects) and loaded them onto a single server called Scholars Portal (http://www.scholarsportal.info/).

Not only does this make the librarians involved feel better about the future preservation of this content, it gives the opportunity for developing search beyond the constraints of metasearch.

Scholars Portal will be moving to a new server and a colleague and I have written about the possibilities of its development in a white paper called Scholr 2.0 :
http://www.scholarsportal.info/commentpress/

To me it’s not so much a crazy idea as it is a very expensive idea.

It’s the the kind of project that could be taken up by a consortium of research libraries. That approach would spread out the cost of supporting a ‘metabase’ and pull together a larger set of staff to cooperate in the development.

Because, of course, after you get all the databases together you still have to develop algorithms that work across disparate types of data and on mechanisms for helping searchers move beyond the first set of results. Searching is, after all, only the first step.

Of course, I’m not sure my metalib instance could handle that level of traffic. When I think about doing this, I think about automatically querrying in like 25% of searches or something, to see what happens without killing my metalib server. Metalib is a resource hog.

http://www.libraryjournal.com/article/CA6413442.html