ProgrammableWeb pointed out an InformationWeek story that claimed 28% of Amazon’s sales in early 2005 were attributable to Amazon affiliates. And C|net claims Amazon now has 180,000 AWS developers (up from the 140,000 Amazon was claiming about a year ago).

(Note: not every Amazon affiliate/associate is an Amazon Web Services (AWS) developer, but Amazon hasn’t shared more specific numbers.)

These slides, from Amazon’s AWS developer relations team explain a lot about what AWS is.

API, amazon web services, AWS, Amazon API, developers, earnings, Amazon.com, mashups

I prefaced my point about how the standards we choose in libraries isolate us from the larger stream of progress driving development outside libraries with the note that I was sure to get hanged for it.

It’s true.

I commented that there were over 140,00 registered Amazon API developers and 365 public OpenSearch targets (hey look, there’s another one already), but that SRW/SRU would always play to a smaller audience. Basing arguments on the popularity of the subjects is dangerous, especially so within the library community, and touching on such inflammatory arguments during a 20 minute presentation is certain to leave people feisty.

It’s also especially dangerous to use an apparently sacred cow as the object of what I wanted to be a general example. My overall argument was (and remains) that we should look for opportunities to break down the barriers that isolate our work and find means to expand our community. Still, I believe a specific argument about SRW/SRU has merit, and I’m willing to carry the flag on this side.

So let’s start with what I believe we can agree on: SRW/SRU, OpenSearch, and Amazon Web Services all serve substantially similar interests: the ability to issue a query, get a list of results, get a detailed record for each result (not possible with OpenSearch). From here, many people seem to argue that XSLT can be used to mutate the results of one schema to the other, or directly to browser-displayable content with ease. On the face of it, this seems to solve many of the incompatibilities while preserving the unique features of each.

Sadly, those XSLT arguments ignore one problem while creating another.

XSLT (and similar techniques) can change the representation of the data in a record, but they can’t change the type or nature of the data and such techniques certainly can’t address differences in the way applications interact with the API. As an example, consider that an XSLT could likely be written to translate Flickr’s schema for a single image into something that looks like Amazon’s schema for a single title, but no XSLT can make an application that interacts with one API properly interact with the other.

The problem that XSLT solutions ignore is that if all these schemas can be translated between eachother (either cleanly or not), and if catalogers working with one metadata standard must be aware of the limitations of other standards to which their work might get XSLT’d to, then what’s the value of their differences? Why invest the duplicated time and effort in each?

The rest of this argument assumes that XSLT solves neither the needs of the programmer who must still learn to navigate different APIs nor the cataloger who must either use lowest-common-denominator cataloging standards or write metadata that can’t be cleanly translated to other schemas.

With XSLT out of the picture, it becomes clear that SRU/SRW is indeed among the wall of standards that make it impossible for us within the library to share executable code with anybody outside our community. And because of our low numbers and natural variations in chosen environments (preferred language & database among them), we often find it difficult to share executable code among others within our community.

It’s also worth considering the differences in features between SRW/SRU, OpenSearch, and Amazon Web Services: Both OpenSearch and AWS offer ways to include suggested alternate searches within the search response set (OpenSearch does this especially well). Nothing I’ve seen in SRW/SRU does this (please correct me if I’m wrong), yet considering how much interest there is in developing more human search interfaces and those that allow faceted searching, these are clearly essential components of any useful standard.

Further, AWS supports all aspects of the usage of materials, not just the search and retrieval of them. Are AWS’s shopping cart and checkout features not similar to our circ checkout procedures? Could AWS’s list management features not be used to show patrons what they have checked out now or throughout their history (if we or they wanted that), as well as allowing them to maintain the reading wishlists or personal bibliographies?

And AWS’s support for returning related and recommended items for each record, as well as comments and reviews is outside the scope of SRW/SRU, but required for many of the features we want to add to our applications.

The point here is that while there are substantial differences in the details between SRW/SRU and OpenSearch or AWS, it is not easy to conclude that SRW/SRU is substantially better for the applications we seem to most want to build.

And this is when we have to take note of the recent University of California libraries report and the quote that puts us all in our places: “for the past ten years online searching has become simpler and more effective everywhere, except in library catalogs” (and the same could be said of our online databases).

The problem isn’t that we’ve been bad coders, and we certainly haven’t intentionally built systems that were difficult to use. The problem is that our community has been isolated and unable to leverage advances made elsewhere. Again, my argument is that we need to change this, that we need to find more ways to collaborate not only with those within our community, but with those outside our community.

There’s much we might be able to offer coders outside libraries, but the arguments defending SRW/SRU seem to ignore the lessons we might learn from them.

Final example: it’s pretty obvious to all of us now that chat reference should be done using common and freely available IM tools, but that didn’t stop us from investing huge sums of money in building and buying custom, library specific chat reference tools. Where else will history show we’ve made similar mistakes?

a9, amazon api, amazon web services, argument, AWS, cage match, code4lib, code4lib 2006, future libraries, information retrieval, lib20, libraries, library, library 2.0, library standards, opensearch, search, search and retrieval, search retrieval, sru/srw, srw/sru, web services

No, I’m not talking about the interface our users see in the web browser — there’s enough argument about that — I’m talking about web services, the technologies that form much of the infrastructure for Web 2.0.

Once upon a time, the technology that displayed a set of data, let’s say catalog records, was inextricably linked to the technology that stored that set of data. As we started to fill our data repositories, we found it usefull to import (and export) the data so that we could benefit from the work others had done and share our contributions with others. These processes were manual, or at least actively managed, and they depended on the notion that we had to have that information in our servers to be used by and displayed for our users.

Then technology evolved. Many applications now separate the components that store and manage the information from the components that display and manipulate it, and a few applications open up their data stores to the public via web services-based APIs. This is the concept that makes HousingMaps, ChicagoCrime, and Flickr Colr Pickr, among so many others, work.

Think about this for a moment: Our ILSs are inventory management systems, but our OPACs are (supposed to be) search and retrieval systems. The difference is obvious from here, but our vendors continue to operate as though you can’t have one without the other.

It might be easier to illustrate this point with an example or two.

Amazon Light is one of hundreds of applications based on Amazon’s web services. It connects Amazon’s inventory system with a custom built search and retrieval system, and it works. The Amazon Lite developers at Kokogiak didn’t need to build the inventory system, they only needed to think about ways to make the Amazon inventory more useful to you. Try it out, you might like the ability to search your local library (via some real hacks) or bookmark things via del.icio.us.

Or, you might not. Because Amazon allows anybody to access their catalog data, everybody has the opportunity to build a better, more usable catalog — or any other application that can benefit from the bibliographic details in it.

Take LibraryThing for example. It’s hard to explain what it is about people who read books that makes them want to list the books they own or have read or are interested in reading, but LibraryThing doesn’t worry about the why. It just answers the need. And because listing books, at least making a detailed list of books, can be time consuming, LibraryThing makes it easier by fetching the full details and book jacket from Amazon’s catalog. LibraryThing doesn’t need to “own” that info, it just needs access to it.

And what’s interesting is that LibraryThing is only one of a number of similar applications. Take a look at AllConsuming, Technorati’s popular books, and listal. These services connect Amazon’s catalog data with other data gathered from users or from web crawls, then they share the results. Here’s Ryan Eby’s lists of owned and wanted books, and here they are in RSS. Why RSS? Take a look at how he’s using the listal feed for his current reading list in his blog (lower-right column).

These are not technology demos. These are real applications. They are examples of how the world changes when you open up access to your catalog data. It’s what happens when we realize that the tools that store and manage our information are separate from the tools that display and manipulate that information.

Obviously, I’m about to make the (now-old) argument that we need to open our OPACs like this, but we also need take the lesson that easy and loose is winning over detailed and difficult — even in XML representations of our catalog data. And after looking at all that’s been done so far, I want to ask: why not adopt Amazon’s web services XML schema?

Is it so bad that it was invented elsewhere? Is it a bad thing that there are perhaps hundreds of applications that are already using data in that format?

Maybe the answer to those questions is yes, but here’s where technology can serve us again: we don’t have to choose. We don’t need to bet on one technology while we watch others progress faster. Our systems can output the same catalog data in any number of different ways. RSS, OpenSearch, MARC-XML, ATOM, EAD, or DC are all possible, easy in fact — if the inventory server architecture is open enough to allow it.

What do I really mean when I say library web services should be like Amazon web services? I mean they should be that accessible, that usable, that hackable. I mean libraries will benefit when people we’ve never met are spending their evenings building new applications to use our data. People are wondering how to get more programmers in libraries (example one, two), but I’m wondering how to make library systems more programmer friendly.

Fired up? Read more with my library catalogs should be like WordPress post, John Blyberg’s ILS customer bill of rights, and Ryan Eby’s open vs. turnkey discussion.

tags: amazon, amazon api, amazon web services, api, dublin core, ead, libraries, library, library catalog, marc, marc-xml, opac data, opensearch, web 2.0, web service, web services, web20, webservice, webservices, xml, xml server