A few days ago, while catching up with list traffic on RDA-L, I stumbled on a conversation between two librarians that got me thinking. They were talking about the myriad of changes in their ILS’s designed to make MARC usable with RDA. It’s a topic I still see a lot of on the lists, and it always makes me grind my teeth.
One reason for the dental destruction is that invariably the changes are small and niggly ones, the sort that make life annoying for those catalogers trying to apply RDA in a world still defined by MARC-based systems. It’s hardly news that those systems are often inflexible, but that’s primarily because they were built to supply services in an environment where data sharing was very centralized, change happened no more frequently than every six months, and everyone was prepared and in sync by the time records started flowing containing updated structure. This world is either gone or on its last legs, depending on your perspective.
What I saw underlying that conversation was the assumption that the only way change could happen was if the ILS’s themselves changed; in other words if the ILS vendors decided to lead rather than follow. The situation now is that system vendors say they’ll build RDA compliant systems when their customers ask for them, and libraries say that they’ll use ‘real’ RDA when there are systems that can support it. This is a dance of death, and nobody wins.
For years I’ve been telling librarians that they need to bug their vendors about this state of affairs, but I’m not sure there’s much of a future in that strategy, given that most of the librarians are not yet able to tell the vendors what they want in any detail, and the vendors have been unwilling to build their expertise or invest in any substantive way until they think they have customers ready to buy. This strategy of ‘wait and see’ undoubtedly has its attractions–given that it’s cheap–and the vendors don’t yet see that their current customer base has any alternatives.
But there are alternatives, albeit ones that require some initiative and investment by either libraries or vendors willing to step forward and perhaps gain a competitive advantage. In essence this strategy is based on the notion that if vendors won’t smarten up their systems, a solution that treats the vendor systems like ‘dumb consumers’ might be the best bet for moving forward. If indeed the tight coordination necessary in the past to share data and manage change is no longer optimal, distributed data need not use an ILS as its primary ‘node’ for storage and management of data. It could just sit there, waiting for some other machine that wished to share data (in or out), and still run its functions for the OPAC and pass data to OCLC.
But I suggest it’s no longer necessary for that ILS to be the center of our concern and attention, particularly if we see value in participating in the linked data world. The functions of creating and maintaining data could be accomplished elsewhere, preferably in a ‘system’ (maybe just a cache with services) designed to ingest, manage, and expose statement-based data in a variety of formats–including MARC, for as long as we want. Thus, the export of library data and the serving of it to users via an OPAC could be accomplished without giving up the MARC-based ILS, cutting the cord to OCLC, or upsetting current partners and collaborators.
Yes, we’d still have some work to do, but not nearly as much as we think. We have long understood that the old ideal of a fully ‘integrated’ system is unnecessarily cumbersome and limits our ability to improve our services. Some libraries have bolted discovery platforms on their OPAC that meet their needs better than their ILS does. Others use ERM systems to manage electronic subscriptions. Maybe it’s time to do the same with some of the other backend services that have passed their sell-by date.
Let the dis-integration begin!
Leave a Reply