Federated Search: The Good and the Bad

1. Federated Search: The Good and the Bad Abe Lederman, President and CTO Deep Web Technologies, Inc. APLA 2008 - May 9, 2008

2. Who We Are… Founded in 2002 Headquartered in Santa Fe, New Mexico 20 Employees Over $2 million in R&D funding DWT is focused on providing state-of-the-art federated search products and solutions which search, retrieve, aggregate and analyze content from web-based databases.

3. Abe Lederman-Background • Earned B.S. and M.S. Computer Science degrees, MIT • Began work in information retrieval in 1988 • Co-founded Verity • Developed some of the first web-based applications that searched text-based content, 1994 • Pioneered “Deep Web” searching in 1999 • Founded Deep Web Technologies, 2002

4. Some of Deep Web’s Customers Department of Defense DOE Office of Scientific and Technical Information Intel Corporate Library National Agricultural Library Scitopia.org Stanford University

5. What is Federated Search? Federated Search is an application or service that allows a user to submit a search in parallel to multiple, distributed information sources and retrieve aggregated, ranked and de-duped results.

6. In Other Words…One Search, Many Sources Begin Search Subscription Sources News Blogs & Wikis E-Books Library Catalogs Public Web Sources

7. Information Discovery Benefits of Federated Search • One-stop access to multiple information sources • Users don’t need to know where/how to search • Saves researcher time and money • Improves utilization of information sources • Consolidated, ranked and de-duped results • Important results are not missed

8. Employees often asked, “Why can’t the Intel Library site work like Google or Yahoo?” Federated Search at the Intel Library

10. Geothermal Heating

13. Why Aren’t all Federated Search Engines Equal? • Quality of search results • User Interface • Results Delivery • Administrative Console

14. Quality of Search Results • Thorough connector development • Boolean and Fielded Searching • Number of results retrieved from each source • Relevance Ranking of retrieved data

15. User Interface • “Intuitive” navigation • Rich feature set • Display of results incrementally • Integration with library’s website (supports multiple search pages) • Powerful web 2.0 interface

16. Results Delivery • Aggregated, ranked results • Clustering/grouping of results • Analysis tools such as filters and sorts • Results Export to RSS, Email, Citation manager • Alerts

17. Administrative Console • Enable/disable connectors • Create search boxes and search pages easily • Metrics

18. Bottom Line Federated search engines have varying strengths and weaknesses. Select the federated search that is best for your organization.

19. Recommendations for selecting the “best” federated search engine for your library.

20. “Basically, anything that results in a more enjoyable search experience, will lead users to spend more time with a particular federated search product and thus derive value from those highly relevant results, assuming they are easy to find. This is where a pleasant and uncluttered layout, intuitive navigation, and a good amount of Ajax to minimize page refreshes combine with highly relevant search results to create the perfect user experience. From The Federated Search Blog www.federatedsearchblog.com Sponsored by

21. What Is Important(and what’s not) Quality of Results Full-Text Access Intuitive Interface Ranking Alerts Internal Sources User Satisfaction Cost Real-Time Search Elegant Presentation Features Metadata Time-Saving Analysis Clusters – Facets – Visualizations Simplify Access Premium Content Sources Standards Information Discovery Administrative Interface

22. Bringing Federated Search to your Library • Clearly Define Your Organization’s Requirements • Create Evaluation Criteria • Evaluate Vendors • Test-Test-Test

23. Vendors Select Vendors to Evaluate Send Evaluations Demo Products Conduct Pilots Deploy Solution Narrowing Down Your Vendor Choices

24. Clearly Define Your Organization’s Requirements • Compile your list of sources to federate • Determine sources to search from each search page • Licensed Product vs. Managed Solution • Budget • Staff Resources • Timelines • Determine features important to users

25. Create Evaluation Criteria • Compile a list of requirements and features a vendor must provide. • Add additional features you would like to have. • Create a vendor checklist. • Evaluate responses.

26. Sample Vendor Checklist:Company Viability

27. Sample Vendor Checklist:Architecture and Integration

28. Sample Vendor Checklist:Connectors

29. Sample Vendor Checklist:Results Display

30. Vendor Evaluation • Demonstrations and Pilots • Is a pilot necessary? • How long of a pilot? • Should we do multiple pilots? • Conduct focus groups • Fulfillment of requirements and features Remember: Federated Search is a long-term commitment to a vendor.

31. Test-Test-Test • Scripting your tests • Test each engine against the same criteria (same queries, same sources) • Break-dancing • How sturdy is the engine? • Vendor Response • How quickly (or slowly) does the vendor respond to your needs?

32. The Future of Federated Search • Multi-lingual searching • Personal libraries • Automated source selection • Integration with social networking tools

33. Deep Web’s Search Gallery

34. Resources • The Federated Search Blog • www.federatedsearchblog.com • Sample Vendor Checklist • Email me: abe@deepwebtech.com • Federated Search: Solution or Setback for Online Library Services Edited by Christopher Cox

35. Thank You! Abe Lederman abe@deepwebtech.com