We would be interested to know your thoughts in regards to the following questions in particular:
1) Do you have any views on what directions the Library should be taking?
2) What are the infrastructural, setup and maintenance considerations?
3) What do you see as the benefits and disadvantages of federated searching? Do you like or dislike the concept?
4) How would users like it? How well would federated searching meet user needs?
5) How does federated searching fit in with information literacy objectives and principles?
6) What other issues would you see in teaching and supporting users with a federated search product? How might you use a federated search product in your teaching?
7) What does the Library want to achieve with federated searching?
8) What else do we need to consider?
A major problem I envisage with federated searching is students getting overwhelmed with far too many inter- disciplinary results. More is not necessarily better – in the academic context, it is often quite the contrary. Quality, from the perspective of the discipline in question, is far more important than quantity.
Philosophy students, for instance, need to find philosophy articles written from within the field of philosophy, just as history and mass communication students do for their own subject areas. There are zillions of articles that can be found on philosophy, history, and communication, but only some of those are the right kinds of articles for their disciplines (speaking generally of the needs of undergraduates).
It is teaching students to use the best databases for their subjects, and to use them in the most effective kinds of ways, including limiting to the right academic journal categories as can be done in JSTOR and Project Muse, that information literacy/fluency is all about.
It concerns me that federated searching is not likely to improve anything in this regard – it is much more likely to dumb everything down. Whenever I hear that phrase "one-stop shop", my skeptical radar beeps.
Why when we pay so much for specialised databases, would we want to overlay them all with a ‘lowest common denominator’ effect like federated searching? We are supposed to be teaching students to be discerning in the discovery and use of information. They use Google and Google Scholar as federated search engines anyway. Here is an interesting article with comparative results which concludes that meta/federated searaching ‘gives them quantity but the quality is lost ‘ http://www.information-onli…
I think a potential advantage of federated searching is that it can encourage students who currently only use Google to use our databases instead. We can choose which databases to bring together for each subject for federated searching so students wouldn’t be searching across all the databases. I suspect for some subjects (e.g. education) federated searching could work quite well (especially for undergraduates) and for other subjects it might not.
I like the idea of Fed searching IF it is capable of adding search options for users rather than removing them.
Isn’t Scopus an e.g. of a Fed. search product that we already use, and often recommend, with its Patent, Web, Journal and Selected Sources data sets, and search result tabs? It will be interesting to see the new Web of Science interface in action with this trend in mind.
If it is not as fast and convenient as Google or (perhaps) Google Scholar people will not use it.
I certainly agree with the comment about speed "If it is not as fast and convenient as Google ..", even if a product didn’t quite match Google for response time I wouldn’t want to see it much slower than other library databases.
This could be a tough problem to crack!
I tend to be in favour of federated searching as it enables users to search across our library collections, such as databases and electronic journals, e-books in one search. I think our e-books, electronic journals eg. Oxford journals online, Blackwell Synergy, Spinger link etc, seemed to be ignored by us. How many of us ever taught students to how to search our e-journal & e-book collections? User education is necessary when using federated searching.
Not many of the databases are as fast as Google, but they contain information valuable for their research, but not available in Google.
Isn’t it great that now you can use ProjectMuse Advanced Search to search Muse and JSTOR collection at one go? This is simple case of federated searching.
The advantage of federated searching over Google Scholar is that in federated searching the students will have access to the full text of most results; in Google Scholar that’s not at all guaranteed. Of course another solution to this would be if Google had a way to limit results to those that have ‘full text @ your library’…
The subject domain issue is important – if engineering students type in "iron" and "fatigue" they’re obviously expecting completely different results that medical students would be expecting. To what extent is it possible to have custom-built interfaces so a psychology student could click a link from their subject portal and automatically be taken to search across PsycInfo and MedLine etc, while electrical engineering students would be taken instead to search across IEEE Xplore and Compendex etc?
These things would need to be clarified/confirmed/checked out in any product trial we might go with, but…
I would expect you should have the option to search by (may be even link to) particular subject(s) or search by selecting particular database(s). Although engineering isn’t set up as an example on the following demo site, in theory you could select "Engineering" as your subject domain, put your search terms in , and the databases searched would be restricted to that subject the Library had set up in its federated search profile.
A basic demo of the Serials Solutions 360 product is available at
http://demo.cs.serialssolut…
username/password is sersol/search