<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: The Iron Fist of Interoperability</title>
	<atom:link href="http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php/feed" rel="self" type="application/rss+xml" />
	<link>http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php</link>
	<description></description>
	<lastBuildDate>Tue, 02 Mar 2010 03:15:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ross Singer</title>
		<link>http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php/comment-page-1#comment-20966</link>
		<dc:creator>Ross Singer</dc:creator>
		<pubDate>Thu, 10 Jul 2008 14:02:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php#comment-20966</guid>
		<description>Jakob, you&#039;re right, of course.  The downside of the ILS-DI recommendation, as it currently exists, is that there is no agreement on what protocol should be used for any given method.

So, take GetAvailability, for instance.  You could use a RESTful interface, NCIP service or an OpenURL resolver.  It could return a result in NCIP, MFHD, ISO 20775 or the &#039;simpleAvailability&#039; schema that they have created.

To follow the API, using the recommendations, you&#039;d have:  OAI-PMH, SRU, and some REST interface (for Harvest, Search and GetAvailability).  Which means you need server interfaces and client support.  This means the local developer also needs to be able to account for each of these protocols and know when it&#039;s appropriate to use which.  &lt;em&gt;And&lt;/em&gt; keep up with the differences in syntax.

Instead, it seems like it would have made more sense to try figure out &lt;strong&gt;one&lt;/strong&gt; technology that could work for everything.  Leaving aside my own self-interest in AtomPub, SRU could have done this.  Rob Sanderson has spoken in the past about having SRU eliminates the need for OAI-PMH (there&#039;s an assumption you already have SRU in that argument, of course), since you could, effectively, &#039;search&#039; for the same results you&#039;d get via OAI-PMH (through dc.date, probably).

The same could hold for GetAvailability.

Where things break down is where you get into &#039;write&#039; methods (self-renewal, etc.), since, obviously SRU has no provision for that.  But, at the core functionality that they are currently asking for, it seems like recommending &lt;em&gt;one&lt;/em&gt; protocol (and then examples of how it would work) will keep us from trotting into an interoperability quagmire.

And, naturally, I think AtomPub offers some way out there...</description>
		<content:encoded><![CDATA[<p>Jakob, you&#8217;re right, of course.  The downside of the ILS-DI recommendation, as it currently exists, is that there is no agreement on what protocol should be used for any given method.</p>
<p>So, take GetAvailability, for instance.  You could use a RESTful interface, NCIP service or an OpenURL resolver.  It could return a result in NCIP, MFHD, ISO 20775 or the &#8217;simpleAvailability&#8217; schema that they have created.</p>
<p>To follow the API, using the recommendations, you&#8217;d have:  OAI-PMH, SRU, and some REST interface (for Harvest, Search and GetAvailability).  Which means you need server interfaces and client support.  This means the local developer also needs to be able to account for each of these protocols and know when it&#8217;s appropriate to use which.  <em>And</em> keep up with the differences in syntax.</p>
<p>Instead, it seems like it would have made more sense to try figure out <strong>one</strong> technology that could work for everything.  Leaving aside my own self-interest in AtomPub, SRU could have done this.  Rob Sanderson has spoken in the past about having SRU eliminates the need for OAI-PMH (there&#8217;s an assumption you already have SRU in that argument, of course), since you could, effectively, &#8217;search&#8217; for the same results you&#8217;d get via OAI-PMH (through dc.date, probably).</p>
<p>The same could hold for GetAvailability.</p>
<p>Where things break down is where you get into &#8216;write&#8217; methods (self-renewal, etc.), since, obviously SRU has no provision for that.  But, at the core functionality that they are currently asking for, it seems like recommending <em>one</em> protocol (and then examples of how it would work) will keep us from trotting into an interoperability quagmire.</p>
<p>And, naturally, I think AtomPub offers some way out there&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jangle-API für Bibliothekssysteme &#171; Jakoblog — Das Weblog von Jakob Voß</title>
		<link>http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php/comment-page-1#comment-20963</link>
		<dc:creator>Jangle-API für Bibliothekssysteme &#171; Jakoblog — Das Weblog von Jakob Voß</dc:creator>
		<pubDate>Thu, 10 Jul 2008 13:00:29 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php#comment-20963</guid>
		<description>[...] anstatt f&#252;r jedes System die Anbindung neu anzupassen. Jangle wird von Ross Singer (Talis) vorangetrieben und steht anscheinend sowohl in Konkurrenz als auch in Kooperation mit der DLF working group on [...]</description>
		<content:encoded><![CDATA[<p>[...] anstatt f&#252;r jedes System die Anbindung neu anzupassen. Jangle wird von Ross Singer (Talis) vorangetrieben und steht anscheinend sowohl in Konkurrenz als auch in Kooperation mit der DLF working group on [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jakob</title>
		<link>http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php/comment-page-1#comment-20960</link>
		<dc:creator>Jakob</dc:creator>
		<pubDate>Thu, 10 Jul 2008 12:41:49 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php#comment-20960</guid>
		<description>There is nothing wrong with having multiple APIs for different purpose. There already are a couple of &lt;a href=&quot;http://jakoblog.de/2007/11/30/relevant-apis-for-digital-libraries/&quot; rel=&quot;nofollow&quot;&gt;relevant APIs for libraries&lt;/a&gt; and for some purposes a simple API is missing. Instead of creating a totally new API for everything I think it is better to fix &quot;good&quot; APIs that exist, burry the &quot;bad&quot; APIs that are crap, and fill the gaps with new ones, that are not designed from a librarians point of view but from the viewpoint of simple usage - but maybe that&#039;s also the idea behind Jangle?</description>
		<content:encoded><![CDATA[<p>There is nothing wrong with having multiple APIs for different purpose. There already are a couple of <a href="http://jakoblog.de/2007/11/30/relevant-apis-for-digital-libraries/" rel="nofollow">relevant APIs for libraries</a> and for some purposes a simple API is missing. Instead of creating a totally new API for everything I think it is better to fix &#8220;good&#8221; APIs that exist, burry the &#8220;bad&#8221; APIs that are crap, and fill the gaps with new ones, that are not designed from a librarians point of view but from the viewpoint of simple usage &#8211; but maybe that&#8217;s also the idea behind Jangle?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Semantic Library » One protocol to rule them all?</title>
		<link>http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php/comment-page-1#comment-12163</link>
		<dc:creator>Semantic Library » One protocol to rule them all?</dc:creator>
		<pubDate>Thu, 15 May 2008 13:04:24 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/panlibus/archives/2008/05/the-iron-fist-of-interoperability.php#comment-12163</guid>
		<description>[...] Singer at Panlibus discusses a draft recommendation from the Digital Library Federation ILS and Discovery System Task Force and notes that while [...]</description>
		<content:encoded><![CDATA[<p>[...] Singer at Panlibus discusses a draft recommendation from the Digital Library Federation ILS and Discovery System Task Force and notes that while [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
