Archive for the ‘federated searching’ category

Library Find

August 29, 2007

Stumbled across LibraryFind the other day and have been playing around trying to get it installed. I’ve not had many good experiences with Ruby based apps, but this looked really promising so I took the plunge. Unfortunately the searching doesn’t work because and just states that there was an error. Looking in the log files, it states that its “missing default helper dispatch_helper” and the record_set_helper. I also ran into a problem in the admin module when I attempted to add a target…just got a recordschema error. I ended up just writing a script to install a couple of EBSCO targets we had, but hopefully once I figure out what’s going on with the helpers, that problem will be resolved too.

Advertisements

SuperConference Day -1: Federated Searching Workshop

February 19, 2007

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.