--- Old home page ---

URL for presentation/discussion: mmsbreeze.itops.rpi.edu/fedsearch

Exploration of Federated Search

What do we want to know? (from process planning document)

  • Possible questions to explore:
    • Who is using federated search? How do they present it (on website, in instruction)?
    • Issues federated search raises and pros/cons of fed search.
    • Pros/cons of open source vs. commercial products
    • What can federated search do for our users that Google Scholar can't?

  • Possible questions to explore for each product:
    • What can they do? What can't they do?
    • How do they work?
    • Differences between products / comparisons with other products.
    • What libraries are using it? Are any nearby libraries using it?
      • Maybe we should check out our peer institutions as well as local ones.
    • (less concerned about this initially) Cost and staff time - during initial setup and to support it once it's running. Who does this work? How much of their time does it take?
    • Do the products interface with discovery layers? Which ones?

Links to Wiki Pages on Individual Products

Thoughts / Notes / Ideas

  • William had an idea about putting together a federated search using Google's API?
  • In general, the more databases you search, the slower it is.
  • Federated search will not be as full-featured as the native database interfaces - "lowest common denominator" fields.
  • Some databases you won't want to federate - for example, databases where you're charged per-search (do we have any of these?) [currenlty only through FirstSearch and OCLC has announced that most of those databases are being phased out.- PH]
  • How can we gauge users' needs & preferences?
  • Things different federated search products may or may not do:
    • Returning a "quick set" of fast results while the search continues to crank away in the background.
    • Relevance ranking.
    • Deduping of results.
    • Allow librarians to select groupings of resources for different disciplines. Search biology databases, search social sciences databases, etc.
    • Allow patrons to select which databases they want to search
  • How good are the products at showing where the citations come from (what is the original database)? Once you get your results, are you able to easily choose to rerun your search in one of the native database interfaces? This would be a factor in how easy it is to use the federated search to help you find an appropriate database to search in.


  • Federated search - a slippery term. Even people who are really knowledgeable about this field can't agree on what federated search is defined as (CODE4lib discussion). Compare w/ distributed search, broadcast search, etc. Is it sending out your search to multiple databases and combining them into a single result set? What do you call it when the metadata from several databases is combined into one local interface, which you then search? I (KD) think that most wouldn't use federated search to refer to the ability to search multiple databases from a single vendor through the vendor's interface. Probably not worth too much time trying to nail down exact terms, though.
  • Native database (native database interface) - for instance, searching an EBSCO database from the EBSCO site instead of through your federated search tool
  • "In addition to Web 2.0, the concept of metasearch is a term that is often misunderstood or used interchangeably with federated search. For the purpose of this dialogue, federated search will be used to describe a search done over many different resources, where the query runs on numerous remote servers before results are aggregated and returned to the initiator of the search. Metasearch, on the other hand, will be defined as a search that is able to query and aggregate content from local and remote
    "[Good additional definition of terminology continues]

Bibliography / Reading

Federated search
User behavior, etc.