Comments on: The High Cost Of Metasearch For Libraries http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/ A bunch of stuff I would have emailed you about. Thu, 20 Nov 2008 17:54:22 +0000 http://wordpress.org/?v=2.6 By: christian ledermann http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-197412 christian ledermann Wed, 16 Jul 2008 12:32:56 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-197412 FYI: http://libraryfind.org/ LibraryFind is... an open source metasearch application developed by librarians for libraries, built with Ruby on Rails. Some Current Features: Built-in OpenURL resolver 2-click find workflow Ability to locally index collections Web-based administration 3-tiered caching system (to improve speed of searches) Customizable user interface LibraryFind® is software developed by the Oregon State University Libraries, funded in part by a grant from the State Library. FYI:

http://libraryfind.org/

LibraryFind is…

an open source metasearch application developed by librarians for libraries, built with Ruby on Rails.

Some Current Features:

Built-in OpenURL resolver
2-click find workflow
Ability to locally index collections
Web-based administration
3-tiered caching system (to improve speed of searches)
Customizable user interface

LibraryFind® is software developed by the Oregon State University Libraries, funded in part by a grant from the State Library.

]]> By: OpenSearch In A Nutshell « MaisonBisson.com http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-57240 OpenSearch In A Nutshell « MaisonBisson.com Thu, 20 Jul 2006 01:59:41 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-57240 [...] Now, the question for libraries is when are we going to demand OpenSearch interfaces from our information providers? The inclusion of OpenSearch in IE7 more than gives it critical mass, but so far it seems to be just something a few progressive library-types are experimenting with. In the short term, imagine how improved our metasearch tools would be if based on fully-implemented OpenSearch feeds (with the facets and suggestions). In the long term, I can’t imagine any aspect of a library’s online services not touched by this technology. [...] [...] Now, the question for libraries is when are we going to demand OpenSearch interfaces from our information providers? The inclusion of OpenSearch in IE7 more than gives it critical mass, but so far it seems to be just something a few progressive library-types are experimenting with. In the short term, imagine how improved our metasearch tools would be if based on fully-implemented OpenSearch feeds (with the facets and suggestions). In the long term, I can’t imagine any aspect of a library’s online services not touched by this technology. [...]

]]> By: Alejandro Garza http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-41629 Alejandro Garza Wed, 24 May 2006 17:34:08 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-41629 Our library system is using a mix of tools: MetaFind from Innovative Interfaces as the "connector", but running our own front-end (in PHP) that queries other databases thru MetaFind. Our relevance rank tweaked Metafind's "relevance ranking" (which was, "10 results from whatever database answered first, 10 results from the second, etc) to ignoring the response time of each database (but preserving each database´s original "relevance" rank. However, it turns out that most users didn´t like the relevance algorithm for each individual database... it didn't seem google-like enough. Brittanica ignores phrase matching as "higher relevance", ProQuest seems to put articles higher based solely on term occurence... so taking whatever (limited) results came back from each metasearch, we now implemented an algorightm with high scent (pushing results up based on term occurence, phrase occurence, and newer publication date) which seems to be working better (I guess we need more studies to find the right scoring weights). I know the vendors won't get to this soon enough, so why not tweak our metasearch engines like this in the meantime? BTW, if you want to look at this algorithm tweak, look <a HREF="http://biblioteca.itesm.mx/wiki/doku.php?id=cbd:site:relevanciaplus" rel="nofollow">at our results (sorry, it's in spanish!)</a>.... <a HREF="http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=es_en&url=http%3A%2F%2Fbiblioteca.itesm.mx%2Fwiki%2Fdoku.php%3Fid%3Dcbd%3Asite%3Arelevanciaplus" rel="nofollow">Link to bad automatic translation</a>. =) [tags]metasearch, relevance[/tags] Our library system is using a mix of tools: MetaFind from Innovative Interfaces as the “connector”, but running our own front-end (in PHP) that queries other databases thru MetaFind. Our relevance rank tweaked Metafind’s “relevance ranking” (which was, “10 results from whatever database answered first, 10 results from the second, etc) to ignoring the response time of each database (but preserving each database´s original “relevance” rank. However, it turns out that most users didn´t like the relevance algorithm for each individual database… it didn’t seem google-like enough. Brittanica ignores phrase matching as “higher relevance”, ProQuest seems to put articles higher based solely on term occurence… so taking whatever (limited) results came back from each metasearch, we now implemented an algorightm with high scent (pushing results up based on term occurence, phrase occurence, and newer publication date) which seems to be working better (I guess we need more studies to find the right scoring weights). I know the vendors won’t get to this soon enough, so why not tweak our metasearch engines like this in the meantime? BTW, if you want to look at this algorithm tweak, look at our results (sorry, it’s in spanish!)…. Link to bad automatic translation. =)

[tags]metasearch, relevance[/tags]

]]> By: WPopac: An OPAC 2.0 Testbed « MaisonBisson.com http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-31687 WPopac: An OPAC 2.0 Testbed « MaisonBisson.com Fri, 10 Feb 2006 05:06:28 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-31687 [...] What about RSS, XML, OpenSearch? WordPress solves the RSS feed for us (look at this URL to see). A feature-complete XML API, is a bit further off, but maybe somebody wants to pitch in to help solve that one? And full OpenSearch support, taking advantage of the suggested and alternate search features, is my next big project (here’s where I’m going with that). [...] [...] What about RSS, XML, OpenSearch? WordPress solves the RSS feed for us (look at this URL to see). A feature-complete XML API, is a bit further off, but maybe somebody wants to pitch in to help solve that one? And full OpenSearch support, taking advantage of the suggested and alternate search features, is my next big project (here’s where I’m going with that). [...]

]]> By: MaisonBisson.com » Blog Archive » Now Search Lamson Library at A9.com http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-9424 MaisonBisson.com » Blog Archive » Now Search Lamson Library at A9.com Fri, 21 Oct 2005 12:57:19 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-9424 [...] A9, the search engine from Amazon.com, does some pretty interesting things that libraries should be aware of. First, any library considering a metasearch product should look at what can be done for free, and second, libraries should take a look at the OpenSearch technology that drives it. [...] [...] A9, the search engine from Amazon.com, does some pretty interesting things that libraries should be aware of. First, any library considering a metasearch product should look at what can be done for free, and second, libraries should take a look at the OpenSearch technology that drives it. [...]

]]> By: Ron Force http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-616 Ron Force Mon, 25 Jul 2005 21:13:12 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-616 Unfortunately, vendors don't sell to patrons, but to librarians. They have to add the full Boolean bells and whistles to get past the all-librarian screening committee. Most are senior staff, raised on Dialog. Unfortunately, vendors don’t sell to patrons, but to librarians. They have to add the full Boolean bells and whistles to get past the all-librarian screening committee. Most are senior staff, raised on Dialog.

]]> By: ken http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-478 ken Wed, 13 Jul 2005 22:05:11 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-478 What do you think of this article? http://www.adtmag.com/article.asp?id=11385 What do you think of this article?

http://www.adtmag.com/article.asp?id=11385

]]> By: NoSheep! » Library Metasearching and Digital Collections http://maisonbisson.com/blog/post/10665/the-high-cost-of-metasearch-for-libraries/#comment-474 NoSheep! » Library Metasearching and Digital Collections Wed, 13 Jul 2005 19:28:27 +0000 http://www.maisonbisson.com/blog/?p=10665#comment-474 [...] MetaLib (with SFX) is where the bells and whistles are really obvious. There are varying degrees of increased complexity in the interface depending on how deep you go. This is great for the librarians, but unlikely that students would use it. In fact Casey at MaisonBisson, also in attendance with me, states that “only 0.0067% (YES, less than a hundredth of a percent!) of the searches on our OPAC get “limited” to specific languages, locations, dates, or material types” in his article The High Cost Of Metasearch For Libraries. The interface seems to be minimally customizable, limited to headers, footers, and CSSS. However, there are “real” APIs for MetaLib, a separate product they call XServer. It is well documented and seems to be just the right amount of useful, but more cumbersome than a mere REST-like interface. [...] [...] MetaLib (with SFX) is where the bells and whistles are really obvious. There are varying degrees of increased complexity in the interface depending on how deep you go. This is great for the librarians, but unlikely that students would use it. In fact Casey at MaisonBisson, also in attendance with me, states that “only 0.0067% (YES, less than a hundredth of a percent!) of the searches on our OPAC get “limited” to specific languages, locations, dates, or material types” in his article The High Cost Of Metasearch For Libraries. The interface seems to be minimally customizable, limited to headers, footers, and CSSS. However, there are “real” APIs for MetaLib, a separate product they call XServer. It is well documented and seems to be just the right amount of useful, but more cumbersome than a mere REST-like interface. [...]

]]>