<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Ouch! That feedback must hurt!</title>
	<atom:link href="http://federatedsearchblog.com/2010/02/26/ouch-that-feedback-must-hurt/feed/" rel="self" type="application/rss+xml" />
	<link>http://federatedsearchblog.com/2010/02/26/ouch-that-feedback-must-hurt/</link>
	<description>Covers topics related to federated search and the deep web</description>
	<lastBuildDate>Mon, 30 Jan 2012 05:01:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Harold</title>
		<link>http://federatedsearchblog.com/2010/02/26/ouch-that-feedback-must-hurt/comment-page-1/#comment-43237</link>
		<dc:creator>Harold</dc:creator>
		<pubDate>Wed, 03 Mar 2010 12:31:18 +0000</pubDate>
		<guid isPermaLink="false">http://federatedsearchblog.com/?p=1226#comment-43237</guid>
		<description>I can understand the frustrations Concordia had with their product as I recognise many of them in the implementation we have at the university I work for.
Yet as you write the alternative is to go back to searching through dozens of separate sources and, however problematic some steps have been, the end-user is unaware of at least 90% of this.

We have a fairly low-cost product and for all its shortcomings and the problems we&#039;ve had with our vendor (you get what you pay for?) the current situation is a big improvement over seeing a large number of our resources hardly being used.

I never want to go back to a situation where we don&#039;t have a federated search solution.</description>
		<content:encoded><![CDATA[<p>I can understand the frustrations Concordia had with their product as I recognise many of them in the implementation we have at the university I work for.<br />
Yet as you write the alternative is to go back to searching through dozens of separate sources and, however problematic some steps have been, the end-user is unaware of at least 90% of this.</p>
<p>We have a fairly low-cost product and for all its shortcomings and the problems we&#8217;ve had with our vendor (you get what you pay for?) the current situation is a big improvement over seeing a large number of our resources hardly being used.</p>
<p>I never want to go back to a situation where we don&#8217;t have a federated search solution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oleg Kreymer</title>
		<link>http://federatedsearchblog.com/2010/02/26/ouch-that-feedback-must-hurt/comment-page-1/#comment-42880</link>
		<dc:creator>Oleg Kreymer</dc:creator>
		<pubDate>Sat, 27 Feb 2010 00:14:07 +0000</pubDate>
		<guid isPermaLink="false">http://federatedsearchblog.com/?p=1226#comment-42880</guid>
		<description>Welcome to the club, Concordia University Library!
Federated search looks more and more like the MiniDisk technology that never really happened.

&quot;...when the only alternative is to search a few dozen sources one at a time, federated search looks really good.&quot; 
Uh?... No, it doesn&#039;t.</description>
		<content:encoded><![CDATA[<p>Welcome to the club, Concordia University Library!<br />
Federated search looks more and more like the MiniDisk technology that never really happened.</p>
<p>&#8220;&#8230;when the only alternative is to search a few dozen sources one at a time, federated search looks really good.&#8221;<br />
Uh?&#8230; No, it doesn&#8217;t.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

