{"id":304,"date":"2009-04-27T21:24:36","date_gmt":"2009-04-28T02:24:36","guid":{"rendered":"http:\/\/dilettantes.code4lib.org\/?p=304"},"modified":"2009-04-27T21:24:36","modified_gmt":"2009-04-28T02:24:36","slug":"commoditizing-the-stack","status":"publish","type":"post","link":"https:\/\/rossfsinger.me\/blog\/2009\/04\/commoditizing-the-stack\/","title":{"rendered":"Commoditizing the Stack"},"content":{"rendered":"

I had the opportunity to attend and present at the excellent ELAG conference<\/a> last week in Bratislava, Slovakia<\/a>.\u00c2\u00a0 The event was advertised as being somewhat of a European Code4Lib<\/a>, but in reality, the format seemed to me to be more in line with Access<\/a>, which in my mind is a plus.<\/p>\n

Being the ugly American that I am, I made a series of provocative statements both in my presentation and in the Twitter “back channel”<\/a> (or whatever they call hash tagging an event) about vendors, library standards, and a seeming disdain for both.\u00c2\u00a0 I feel like I should probably clarify my position here a bit, since Twitter is a terrible medium for in-depth communication and I didn’t go into much detail in my presentation (outside of saying vendor development teams were populated by scalliwags and ne’er-do-wells from previous gigs in finance, communications and publishing).<\/p>\n

Here was my point I was angling towards in my presentation:\u00c2\u00a0 your Z39.50 implementation is never going to get any better than it was in 2001.\u00c2\u00a0 Outside of critical bug fixes, I would wager the Z39.50 implementation has not even been touched<\/em> since it was introduced, never mind improved.\u00c2\u00a0 The reason for this is my above “joke” about the development teams being staffed by people that do not have a library background.\u00c2\u00a0 They are literally just ignoring the Z-server and praying that nothing breaks in unit and regression testing.\u00c2\u00a0 There are only a handful of people that understand how Z39.50 works and they are all employed by IndexData.\u00c2\u00a0 For everybody else, it’s just voodoo that was there when they got here, but is a requirement for each patch and release.<\/p>\n

Thing is, even as hardware gets faster, and ILSes (theoretically) get more sophisticated, the Z-server just gets worse.\u00c2\u00a0 You would think that if this is the most common and consistent mechanism to get data out of ILSes that we would have seen some improvement in implementations as the need for better interoperability increases, but this is just not a reality that I have witnessed.\u00c2\u00a0 With the last two ILSes that I primarily worked with (Voyager and Unicorn) I would routinely<\/strong>, accidentally, completely bring down<\/em> due to trying to use the Z39.50 server as a data source in applications.\u00c2\u00a0 For the Umlaut<\/a>, I had to export the Voyager bib database into an external Zebra<\/a> index to prevent the ILS from crashing multiple times a day<\/em> just to look up incoming OpenURL requests.\u00c2\u00a0 Let me note that a vast<\/em><\/strong> <\/strong><\/em>majority of these lookups were just ISSN or ISBN.\u00c2\u00a0 Unsurprisingly, the Zebra index held up with no problems.\u00c2\u00a0 It’s still working, in fact<\/a>.<\/p>\n

Talis uses Zebra for Alto<\/a>.\u00c2\u00a0 It’s probably the main reason we can check off “SRU Support” in an RFP when practically nobody else can.\u00c2\u00a0 But, again, this means the Z\/SRU-server is sort of “outside” the development plan, delegated to IndexData.\u00c2\u00a0 Our SRU servers technically aren’t even conformant to the spec<\/a>, since we don’t serve explain documents<\/a>.\u00c2\u00a0 I’m not sure anybody at Talis even was aware of this until I pointed it out last year.<\/p>\n

All of this is not<\/em> intended to demonize vendors (really!) or bite the hand that feeds me.\u00c2\u00a0 It’s also not intended to denigrate library standards.\u00c2\u00a0 I’m merely trying to be pragmatic and, more importantly, I’m hoping we can make library development a less frustrating and backwards exercise for all parties (even the cads and scalliwags).<\/p>\n

My point is that initiatives like the DLF ILS-DI<\/a>, on paper, make a lot of sense.\u00c2\u00a0 I completely understand why they chose to implement their model using a handful of library standards (OAI-PMH, SRU).\u00c2\u00a0 The standards are there, why not use them?\u00c2\u00a0 The problem is in the reality of the situation.\u00c2\u00a0 If the specification “requires” SRU for search, how many vendors do you think will just slap Yaz Proxy<\/a> in front of their existing (shaky, flaky) Z39.50 server and call it a day?\u00c2\u00a0 The OAI-PMH provider should be pretty trivial, but I would not expect any company to provide anything innovative with regards to sets or different metadata formats.<\/p>\n

As long as libraries are not going to be writing the software they use themselves, they need to reconcile the fact that suppliers of their software is more than likely not going to be written by librarians or library technologists.\u00c2\u00a0 If this is the case, what’s the better alternative?\u00c2\u00a0 Clinging to half-assed implementations of our incredibly niche standards?\u00c2\u00a0 Or figuring out what technologies are developing outside<\/em> of the library realm that could be used to deliver our data and services?\u00c2\u00a0 Is there really, honestly, no way we could figure out how to use OpenSearch<\/a> to do the things we expect SRU to do?<\/p>\n

I realize I have an axe to grind here, but this isn’t really about Jangle.<\/p>\n

I have seen OpenURL bandied about as a “solution” to problems outside of its current primary use of “retrieving context based services from scholarly citations” (I know this is not what OpenURL’s sole use case is, but it’s all it’s being used for.\u00c2\u00a0 Period).\u00c2\u00a0 The most recent example of this was in a workshop (that I didn’t participate in) at ELAG<\/a> about how libraries could share social data, such as tagging, reviews, etc. in order to create the economies of scale needed to make these concepts work satisfactorily.\u00c2\u00a0 Since they needed a way to “identify” things in their collection (books, journals, articles, maps, etc.) somebody had the (understandable, re: DLF) idea to use OpenURL as the identifier mechanism.<\/p>\n

I realize that I have been accused of being “allergic” to OpenURL, but in general, my advice is that if you have a problem and you think OpenURL is the answer to said problem there’s actually probably a simpler and better answer to this if you approach it from outside of a library POV.<\/p>\n

The drawbacks of Z39.88 for this scenario are numerous, but I didn’t go into details with my criticisms in Twitter.\u00c2\u00a0 Here are a few reasons why I would recommend away from OpenURL for this (and they are not exclusive to this potential application):<\/p>\n

    \n
  1. OpenURL context objects are not<\/em> identifiers.\u00c2\u00a0 They are a means to describe a resource, not identify it.\u00c2\u00a0 A context object may contain<\/em> an identifier in its description.\u00c2\u00a0 Use that, scrap the rest of it.<\/li>\n
  2. Because a context object is a description and not an identifier, it would have to be parsed to try to figure out what exactly it is describing.\u00c2\u00a0 This is incredibly expensive, error prone and more sophisticated than necessary.<\/li>\n
  3. It was not entirely clear how the context objects would be used in this scenario.\u00c2\u00a0 Would they just be embedded in, say, an XML document as a clue as to what is being tagged or reviewed?\u00c2\u00a0 Or would the consuming service actually be an OpenURL resolver that took these context objects and returned some sort of response?\u00c2\u00a0 If it’s the former, what would the base URI be?\u00c2\u00a0 If it’s the latter… well, there’s a lot there, but let’s start simple, what sort of response would it return?<\/li>\n
  4. There is no current infrastructure defined in OpenURL for these sorts of requests.\u00c2\u00a0 While there are metadata formats that could handle journals, articles, books, etc., it seems as though this would just scratch the surface of what would need context objects (music, maps, archival collections, films, etc.).\u00c2\u00a0 There are no ‘service types’ defined for this kind of usage (tags, reviews, etc.). The process for adding metadata formats or community profiles is not nimble, which would make it prohibitively difficult to add new functionality when the need arises.<\/li>\n
  5. Such an initiative would have<\/em> to expect to interoperate with non-library sources.\u00c2\u00a0 Libraries, even banding together, are not going to have the scale or attraction of LibraryThing, Freebase, IMDB, Amazon, etc.\u00c2\u00a0 It is not unreasonable to say that an expectation that any<\/em> of these services would really adopt OpenURL to share data is naive and a waste of time and energy.<\/li>\n
  6. There’s already a way to share this data, called SIOC<\/a>.\u00c2\u00a0 What we should be working towards, rather than pursuing OpenURL, is designing a URI structure for these sorts of resources in a service like this.\u00c2\u00a0 Hell, I could even be talked into info URIs<\/a> over OpenURLs for this.<\/li>\n<\/ol>\n

    We could further isolate ourselves by insisting on using our standards.\u00c2\u00a0 Navel gaze, keep the data consistent and standard.\u00c2\u00a0 To me, however, it makes more sense to figure out how to bridge this gap.\u00c2\u00a0 After all, the real prize here is to be able to augment our highly structured metadata with the messy, unstructured web.\u00c2\u00a0 A web that isn’t going to fiddle around with OpenURL.\u00c2\u00a0 Or Z39.50.\u00c2\u00a0 Or NCIP.\u00c2\u00a0 I have a feeling the same is ultimately true with our vendors.<\/p>\n

    There comes a point that we have to ask if our relentless commitment to library-specific standards (in cases when there are viable alternatives) is actually causing more harm than help.<\/p>\n","protected":false},"excerpt":{"rendered":"

    I had the opportunity to attend and present at the excellent ELAG conference last week in Bratislava, Slovakia.\u00c2\u00a0 The event was advertised as being somewhat of a European Code4Lib, but in reality, the format seemed to me to be more in line with Access, which in my mind is a plus. Being the ugly American […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-304","post","type-post","status-publish","format-standard","hentry","category-philosophizing"],"_links":{"self":[{"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/posts\/304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/comments?post=304"}],"version-history":[{"count":2,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/posts\/304\/revisions"}],"predecessor-version":[{"id":306,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/posts\/304\/revisions\/306"}],"wp:attachment":[{"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/media?parent=304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/categories?post=304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rossfsinger.me\/blog\/wp-json\/wp\/v2\/tags?post=304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}