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?