Acronyms – fragile and high

For quite awhile Lorcan has commented on the relatively heavy weight of library data and exchange standards. In general our community has opted for high value and low participation choices in this arena. This has diminished the library’s impact in the web world. The barrier of our own high acronymic density has made it more difficult for others (who are operating the platforms where people actually work) to incorporate useful library services and information.

What’s more the infrastructure built on these standards has a very fragile foundation. They are understood fully by few, supported and enhanced by an even smaller group of enthusiasts, and remain invisible to the wider community of web practitioners. Some years ago, I joined with Lorcan to highlight this issue of support, fragility, take-up and sustainability.

In the last month or two there were a few events that I thought might cause these circumstances once again to be debated in a useful way. Google’s cessation of support for OAI-PMH in sitemaps was one. The second was the launch of the OpenLibrary API which eschewed SRU and OAI-PMH. In a Code4Lib posting Eric Lease Morgan characterized the latter decision saying “In reality I think two things worked against the adoption of SRU and OAI. First my description of their functionality was not as eloquent as it could have been, and second, the Open Library personnel had never heard of nor knew anything about either protocol. This is another example of library standards being too library-centric. Think Z39.50.”
These two events stirred up discussion that disappeared surprisingly quickly. There seemed to be a kind of library-centric satisfaction that allowed people to dismiss the Google decision along the lines of ‘This wasn’t really for them – it’s for us” while the OpenLibrary decision got covered over in rhetoric about OpenLibrary re-inventing the idea of a catalog and needing to do it without regard to prior work.

This arena continues to worry me. We have such a small cadre of skilled systems engineers and designers in the library world. Dispersing their energies in multiple directions that are domain-focused not only lessens their impact but that of the library community.

I am not a systems engineer and these are not matters of technical theology for me. They should, however, be matters of genuine management concern. These choices and investments represent crucial scaffolding and infrastructure decisions that will decide the ultimate shape of the future library. Libraries are challenged to recreate their value in a web world by delivering new services around the workflow of their constituents. Management needs to understand how their own system development investments are constraining those ambitions and working against their realization.

Of course, most library managers don’t have the technical understanding to interrogate this level of system design. But they do have a responsibility to insert themselves into the decision process. They shouldn’t be intimidated by prospective embarrassment. They should be asking the same kinds of questions they ask about other service investments. A white board and three ‘Why?’ questions in a row would be a good starting place for a motivated manager.