SuperConference Day -1: Federated Searching Workshop

Conference blogging isn’t easy, I’m discovering, and I now have a great appreciation for those who do it regularly. I’m looking at my notes and wondering “what did I mean by that?” What I’m going to do is provide bullet points of items that lodged in my memory.

  • Federated search engines send a search to multiple sources, merge the results, and present in a uniform format.
    • Give a Google-like one step search
    • Provide a starting point for unknown research sources
    • Avoids the problem of multiple interfaces
    • Increase awareness of available resources
    • Send users to resources you want them exposed to
    • Very useful for subject guides
  • SirsiDynix works with three vendors to provide federated searching
    • SerialsSolutions – CentralSearch
    • Muse Global – SingleSearch
    • Webfeat – WebFeat
    • WebFeat and Central Search are only hosted while SingleSearch can be installed locally.
    • All three have an API layer but capabilities vary.
  • Four access models for implementing federated searching
    • stand-alone
    • along side the PA, e.g. Continue Search in…
    • Embedded in PAC – no sense that federated searching is a separate product
      • Alert. Seamless searching across sources sounds great but what will it do to response time?
    • Other – like desk top apps?
  • Challenges
    • Reliability – what happens to connector in db vendor changes some aspect on which the connector depends. some connectors use screen scrapers. If the vendor changes a label or moves some element, the connector is broken.
    • Never expect perfection.
  • Implementation
    • In most cases, a site should be able to go live in 6 – 8. 8 – 12 weeks tops.
      • If federated search engine and other products such as OpenURL products use the same knowledge base then go-live will probably be shorter. We have ArticleLinker and CentralSearch will use the same knowledge base.
    • Go live with the most heavily used connectors. Take care of the lesser used ones later.
    • Each connector will have to be touched during the setup
  • Issues with federated searching
    • Federated searching isn’t a replacement for native user interfaces
      • special search features are not available
      • vocabulary for searching differs across databases
      • not all federated search engines support Boolean searches in the same way
    • Federated searching cannot add functionality if the target of the search has a brain dead search engine.
    • The response time for returning results will vary greatly.
      • Problem not with federated search vendor, but the target.
      • Configuring for display of fastest response first will give user something to look at while the rest of searches complete
    • Some connectors will fail, sometime.

If any of my classmates stumble across this blog, please fill in anything I missed and correct that which I may have gotten wrong.

Explore posts in the same categories: federated searching

2 Comments on “SuperConference Day -1: Federated Searching Workshop”

  1. Kim Larsen Says:

    Has there been any mention at any of the meetings as to why Pat Summers stepped down? It seemed sudden and I have heard rumors that it was because they want to move the company to Utah yet eventually move everyone to Unicorn. That did not make sense. Does anyone know what is going on with the company?

  2. Mack Lundy Says:

    There is lots of speculation fueled by fear, uncertainity, and doubt. The SirsiDynix staff I know appear, sincerely, not to know any more than the customers. It would be difficult not to associate his departure with the Vista purchase but beyond that there is no indication if the company’s course is about to change or the nature the change is likely to take. So, in answer to your last question, No.

Comments are closed.

%d bloggers like this: