<?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"
	>
<channel>
	<title>Comments on: Google gives up on supporting OAI-PMH for Sitemaps</title>
	<atom:link href="http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/</link>
	<description></description>
	<pubDate>Sun, 12 Oct 2008 20:31:43 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: da blog (ulcc digital archives blog) &#187; Blog Archive &#187; OAI-PMH: decline or fall?</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-965</link>
		<dc:creator>da blog (ulcc digital archives blog) &#187; Blog Archive &#187; OAI-PMH: decline or fall?</dc:creator>
		<pubDate>Wed, 07 May 2008 14:29:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-965</guid>
		<description>[...] have gleefully rejoiced in the possible demise of the standard. However the discussion on Paul Walk&#8217;s blog is more balanced, lucid and informative, and covers well the many areas where OAI-PMH is more [...]</description>
		<content:encoded><![CDATA[<p>[...] have gleefully rejoiced in the possible demise of the standard. However the discussion on Paul Walk&#8217;s blog is more balanced, lucid and informative, and covers well the many areas where OAI-PMH is more [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen Stephens</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-943</link>
		<dc:creator>Owen Stephens</dc:creator>
		<pubDate>Fri, 02 May 2008 14:28:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-943</guid>
		<description>@Wobbler - it depends what 'interoperability' you are looking for. Unless we define how we want repositories to inter-operate, then we can't assess the best tools for the job.

OAI-PMH is about 'metadata harvesting' - and in theory provides a lightweight way of an automated agent finding out what is in a repository. However, in reality this has only seen take up within the small world of repositories. Google, Yahoo etc. simply crawl the web following links - they don't see the need to implement a new protocol to deal with a tiny (in web terms) amount of content.

Given this, I would argue we should concentrate on how to integrate the material that is stored in repositories into the 'web' environment. Now, this means making the content crawlable and linkable. As the Semantic Web is now getting broader takeup (with the key players such as Yahoo and Google now taking an interest), I would guess that embedding microformats and looking at other semantic web technologies could be a fruitful approach.</description>
		<content:encoded><![CDATA[<p>@Wobbler - it depends what &#8216;interoperability&#8217; you are looking for. Unless we define how we want repositories to inter-operate, then we can&#8217;t assess the best tools for the job.</p>
<p>OAI-PMH is about &#8216;metadata harvesting&#8217; - and in theory provides a lightweight way of an automated agent finding out what is in a repository. However, in reality this has only seen take up within the small world of repositories. Google, Yahoo etc. simply crawl the web following links - they don&#8217;t see the need to implement a new protocol to deal with a tiny (in web terms) amount of content.</p>
<p>Given this, I would argue we should concentrate on how to integrate the material that is stored in repositories into the &#8216;web&#8217; environment. Now, this means making the content crawlable and linkable. As the Semantic Web is now getting broader takeup (with the key players such as Yahoo and Google now taking an interest), I would guess that embedding microformats and looking at other semantic web technologies could be a fruitful approach.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Google dice addio a Oai-Pmh per Sitemaps &#171; The Geek Librarian</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-941</link>
		<dc:creator>Google dice addio a Oai-Pmh per Sitemaps &#171; The Geek Librarian</dc:creator>
		<pubDate>Tue, 29 Apr 2008 19:58:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-941</guid>
		<description>[...] alla notizia - i pochi apparsi sul blog di Google Webmaster, e soprattutto quelli apparsi sul blog di Paul Walks. Che ne [...]</description>
		<content:encoded><![CDATA[<p>[...] alla notizia - i pochi apparsi sul blog di Google Webmaster, e soprattutto quelli apparsi sul blog di Paul Walks. Che ne [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wobbler</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-940</link>
		<dc:creator>Wobbler</dc:creator>
		<pubDate>Tue, 29 Apr 2008 19:11:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-940</guid>
		<description>I have read that blog post earlier (thanks to your blog). I think it is an interesting post, but unless with "alternative", he means: ditch the concept of institutional repositories altogether and go central repositories (which I do not think is realistic), it does not actually give any alternative approaches to handle this.

And assuming "the web", e.g. Google Scholar?, can do it just as good without protocols such as OAI-PMH, why have that protocol in the first place? I am going to assume that it was necessary to optimize interoperability between institutional repositories?</description>
		<content:encoded><![CDATA[<p>I have read that blog post earlier (thanks to your blog). I think it is an interesting post, but unless with &#8220;alternative&#8221;, he means: ditch the concept of institutional repositories altogether and go central repositories (which I do not think is realistic), it does not actually give any alternative approaches to handle this.</p>
<p>And assuming &#8220;the web&#8221;, e.g. Google Scholar?, can do it just as good without protocols such as OAI-PMH, why have that protocol in the first place? I am going to assume that it was necessary to optimize interoperability between institutional repositories?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: paul</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-939</link>
		<dc:creator>paul</dc:creator>
		<pubDate>Tue, 29 Apr 2008 15:24:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-939</guid>
		<description>Wobbler,
I guess the short answer to your question would be 'The Web'. The case has been made for this more strongly elsewhere - I suggest that you have a look at &lt;a href="http://efoundations.typepad.com/efoundations/2008/02/repositories-th.html" rel="nofollow"&gt;http://efoundations.typepad.com/efoundations/2008/02/repositories-th.html&lt;/a&gt; for one argument along these lines.</description>
		<content:encoded><![CDATA[<p>Wobbler,<br />
I guess the short answer to your question would be &#8216;The Web&#8217;. The case has been made for this more strongly elsewhere - I suggest that you have a look at <a href="http://efoundations.typepad.com/efoundations/2008/02/repositories-th.html" rel="nofollow">http://efoundations.typepad.com/efoundations/2008/02/repositories-th.html</a> for one argument along these lines.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wobbler</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-938</link>
		<dc:creator>Wobbler</dc:creator>
		<pubDate>Mon, 28 Apr 2008 23:43:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-938</guid>
		<description>First I would like to say that since I have found your blog, I have been finding a lot more interesting blogs on scholarly communication/ OA/ repositories. So thanks.

Anyway, maybe I have been following the Stevan Harnad/ Alma Swan crowd too much, but I was under the impression that OAI-PMH, in the context of institutional repositories, was currently the best approach to achieve a high level of accessibility of eprints? And also that it is flexible enough to be extended with other metadata (such as comments)?

If not, can someone tell me about (better) alternatives for accessibility/ interoperability between institutional repositories? What other protocols are there like OAI-PMH (but better and more flexible)?</description>
		<content:encoded><![CDATA[<p>First I would like to say that since I have found your blog, I have been finding a lot more interesting blogs on scholarly communication/ OA/ repositories. So thanks.</p>
<p>Anyway, maybe I have been following the Stevan Harnad/ Alma Swan crowd too much, but I was under the impression that OAI-PMH, in the context of institutional repositories, was currently the best approach to achieve a high level of accessibility of eprints? And also that it is flexible enough to be extended with other metadata (such as comments)?</p>
<p>If not, can someone tell me about (better) alternatives for accessibility/ interoperability between institutional repositories? What other protocols are there like OAI-PMH (but better and more flexible)?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Czerniak</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-930</link>
		<dc:creator>Brad Czerniak</dc:creator>
		<pubDate>Thu, 24 Apr 2008 23:01:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-930</guid>
		<description>I'm not so sure that sitemaps are going to grow in importance. Their principal importance in the past was due to inadequete spidering. Nowadays, Google's spidering with additional HTTP requests (unfriendly URLs). The only good thing about being Google sitemaps-compliant is the ability to have the most important links exposed in results lists, but some sites get that without being particularly SEO.

Also, harvesting over sitemap would be a difficult proposition for large collections, as the heft of the XML layer would be more pronounced than a single-object query via a web services protocol.

There's nothing wrong with OAI-PMH necessarily -- there just isn't any "killer app" to really entice people. I guess this might be an instance where "If you can't beat 'em, join 'em" would be sound advice.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not so sure that sitemaps are going to grow in importance. Their principal importance in the past was due to inadequete spidering. Nowadays, Google&#8217;s spidering with additional HTTP requests (unfriendly URLs). The only good thing about being Google sitemaps-compliant is the ability to have the most important links exposed in results lists, but some sites get that without being particularly SEO.</p>
<p>Also, harvesting over sitemap would be a difficult proposition for large collections, as the heft of the XML layer would be more pronounced than a single-object query via a web services protocol.</p>
<p>There&#8217;s nothing wrong with OAI-PMH necessarily &#8212; there just isn&#8217;t any &#8220;killer app&#8221; to really entice people. I guess this might be an instance where &#8220;If you can&#8217;t beat &#8216;em, join &#8216;em&#8221; would be sound advice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-929</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Thu, 24 Apr 2008 11:32:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-929</guid>
		<description>The lesson presumably isn't "Google don't do it therefore we shouldn't" but "the fact that only 200 sites signed up say something about the technology which we should listen to"?

I keep coming back to the same old cracked record mantra: if a technology doesn't have a wide and fairly rapid uptake, if it isn't easy, if it can't demonstrate benefits to ALL (not just the geek community) within a reasonable time span, then it simply isn't a technology worth pursuing. Knowing not much about OAI

The latest Ofcom report seems to back this up. http://tinyurl.com/4vrkcz</description>
		<content:encoded><![CDATA[<p>The lesson presumably isn&#8217;t &#8220;Google don&#8217;t do it therefore we shouldn&#8217;t&#8221; but &#8220;the fact that only 200 sites signed up say something about the technology which we should listen to&#8221;?</p>
<p>I keep coming back to the same old cracked record mantra: if a technology doesn&#8217;t have a wide and fairly rapid uptake, if it isn&#8217;t easy, if it can&#8217;t demonstrate benefits to ALL (not just the geek community) within a reasonable time span, then it simply isn&#8217;t a technology worth pursuing. Knowing not much about OAI</p>
<p>The latest Ofcom report seems to back this up. <a href="http://tinyurl.com/4vrkcz" rel="nofollow">http://tinyurl.com/4vrkcz</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen Stephens</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-928</link>
		<dc:creator>Owen Stephens</dc:creator>
		<pubDate>Thu, 24 Apr 2008 11:28:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-928</guid>
		<description>@pete cliff - but this is a good point, z39.50 has never been widely adopted outside the library sector, and now looks like an increasing barrier to access rather than enabler.

I think there is a risk that OAI-PMH is in a similar situation - a sector specific solution, that is seen by many as too complicated and is never going to get widespread acceptance by the wider community.

We've got to ask, what does OAI-PMH add - is it achieving it's goal of being "is a low-barrier mechanism for repository interoperability" (from http://www.openarchives.org/pmh/)? To understand this, we have to start dragging the definition of 'repository' apart, but if we (for example) say Flickr is a repository of pictures, you could argue that OAI-PMH does nothing for interoperability between an e-prints repository and Flickr. What OAI-PMH does is enable interoperability between two systems supporting OAI-PMH - and as support for this drops, the likelihood of OAI-PMH being successful also drops.

We need to look really hard at this - I'm not convinced that OAI-PMH is 'the future' for repositories, and if not, we need to look at where the future is, and start heading in that direction.</description>
		<content:encoded><![CDATA[<p>@pete cliff - but this is a good point, z39.50 has never been widely adopted outside the library sector, and now looks like an increasing barrier to access rather than enabler.</p>
<p>I think there is a risk that OAI-PMH is in a similar situation - a sector specific solution, that is seen by many as too complicated and is never going to get widespread acceptance by the wider community.</p>
<p>We&#8217;ve got to ask, what does OAI-PMH add - is it achieving it&#8217;s goal of being &#8220;is a low-barrier mechanism for repository interoperability&#8221; (from <a href="http://www.openarchives.org/pmh/" rel="nofollow">http://www.openarchives.org/pmh/</a>)? To understand this, we have to start dragging the definition of &#8216;repository&#8217; apart, but if we (for example) say Flickr is a repository of pictures, you could argue that OAI-PMH does nothing for interoperability between an e-prints repository and Flickr. What OAI-PMH does is enable interoperability between two systems supporting OAI-PMH - and as support for this drops, the likelihood of OAI-PMH being successful also drops.</p>
<p>We need to look really hard at this - I&#8217;m not convinced that OAI-PMH is &#8216;the future&#8217; for repositories, and if not, we need to look at where the future is, and start heading in that direction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stuart Lewis</title>
		<link>http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-926</link>
		<dc:creator>Stuart Lewis</dc:creator>
		<pubDate>Thu, 24 Apr 2008 08:34:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulwalk.net/2008/04/23/google-gives-up-on-supporting-oai-pmh-for-sitemaps/#comment-926</guid>
		<description>The webmaster tools can be pretty useful for developers checking everything is OK (see: http://blogs.openaccesscentral.com/blogs/orblog/entry/how_many_how_fast for an example). 

Over time I suspect sitemaps are going to grow in importance. Ignoring repositories for a moment, most standard webmasters aren't really aware of them, and the benefits they can bring, for example being able to mark certain pages as having a higher priority than others.

No doubt once sitemaps become part of your average webmaster's daily toolkit, their importance will grow, and repository people will catch on. Most repository managers have a set of tick boxes they like to check, one of them being inclusion in G and GS. If they know sitemaps will help them tick these boxes, I'm sure they'll be all for them.

And from a development perspective, sitemaps are very easy to create (100x easier than writing an OAI-PMH interface) so there is no reason really for repository platforms not to support them out-of-the-box.</description>
		<content:encoded><![CDATA[<p>The webmaster tools can be pretty useful for developers checking everything is OK (see: <a href="http://blogs.openaccesscentral.com/blogs/orblog/entry/how_many_how_fast" rel="nofollow">http://blogs.openaccesscentral.com/blogs/orblog/entry/how_many_how_fast</a> for an example). </p>
<p>Over time I suspect sitemaps are going to grow in importance. Ignoring repositories for a moment, most standard webmasters aren&#8217;t really aware of them, and the benefits they can bring, for example being able to mark certain pages as having a higher priority than others.</p>
<p>No doubt once sitemaps become part of your average webmaster&#8217;s daily toolkit, their importance will grow, and repository people will catch on. Most repository managers have a set of tick boxes they like to check, one of them being inclusion in G and GS. If they know sitemaps will help them tick these boxes, I&#8217;m sure they&#8217;ll be all for them.</p>
<p>And from a development perspective, sitemaps are very easy to create (100x easier than writing an OAI-PMH interface) so there is no reason really for repository platforms not to support them out-of-the-box.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
