Link Resolvers and the Serials Supply Chain...

Or Why We Still Don't Get It.

I finally had a chance to read the Final Report from the UKSG on link resolvers. As suspected my read was a frustrating one - not because the report itself is frustrating, but because the industry continues to fail in rallying around a very simple and cost-effective way to deal with the issue of resolver knowledgebases. The report does a good job of explaining why (essentially vendors (publishers and resolver software vendors) with a vested interest in maintaining the status quo and lousy data from publishers). I've written on this one before and my sense of frustration remains the same as it was years ago: why do we continue to pay vendors for inaccurate KB information and then each spend scads of time fixing it? My frustration is even greater today with the knowledge that someone outside, or peripheral to, the Library community will realize what a vapid bunch we are and do this for us. That will have the same effect on the resolver vendors in terms of lost revenue as if we did it ourselves, but it will have the added disadvantage in that we will have lost control over a simple collection of data that is well within our grasp now. I would hazard a guess that collectively libraries have spent tens of millions of $$ licensing resolver software and knowledgbases and tens of millions of $$ in staff time making the lousy data cleaner. Are we any better off in the long run? No. And we won't be until we get off our proprietary knowledgebase bandwagon and build a single, open, standards-based repository that we can all report to and use. Those link resolver software vendors that have good products will find a way to distinguish themselves and the others will disappear. The advantage to all of us, libraries and vendors, will be greater efficiency in a time when increased efficiency and cost-effectiveness counts for a lot.

Section 7.1 of the report does provide a comprehensive series of recommendations that would go a long way to making the development of a more efficient system feasible. The authors propose a "COUNTER" type effort that would see some variation on a standard like ONIX SOH together with a SUSHI-like web services layer for reporting/updating. I suspect we could start with something a little simpler (like the file format for one of the existing knowledgebases, such as CUFTS) and grow from there. The authors also discuss a centralized knowledgebase model, but unfortunately they failed to even mention the open source CUFTS product and the potential for the larger community to rally around that option as the beginnings of just such a resource. It's staring us in the face - can we stop and think about it long enough to see the opportunity before someone else washes our laundry?

Comments

[Charlie Rapple]

Hi Mark,

I just wanted to let you know about KBART, a working group set up by UKSG following publication of its link resolver report, and which is now co-chaired by NISO. The group's purpose is to improve the interaction (and supply of data, etc.) between content publishers/providers and knowledge base vendors. Whilst we don't expect to solve all the problems to which you refer immediately, yours are very much the sort of issues we are contending with as we seek to provide guidance and education to all parties in the information supply chain.

The group is being officially launched at the ALA Midwinter meeting later this week, so for now there is minimal information in the public domain - but for some more detail see http://www.uksg.org/kbart/.

Once we make our public announcement I will post it on the UKSG's LiveSerials blog http://liveserials.blogspot.com/, and we would very much welcome your comments.

All best wishes,

Charlie
on behalf of KBART and UKSG.

[Jonathan Blackburn]

Hi Charlie,

I think this is a great idea and is actually the subject of a presentation that a colleague and I are doing at the upcoming ER&L conference in Atlanta.

We will be discussing some of the current projects involved in serving as open source repositories of E-Resource metadata (thanks for the additional links above), along with some of the options made available by new "semantic web" trends and technologies.

I am thinking here of things like freebase and twine - or any software that allows for a given community to manage a complex set of interrelated data. We also plan to discuss the "open data" movement, which also I think may play a unique role in this whole debate.

I really appreciate your post, though, and hope you might be able to e-mail me (or reply to this comment) with any further thoughts.

I am definitely interested in hearing other's thoughts before we give our presentation.

-Jon

[Jonathan Blackburn]

Oops, sorry, I meant "Hi Mark" - I just happened to be looking at the "Posted by Charlie Rapple" link at the time I was composing my message.

Although, Charlie, please feel free to contact or reply as well - I am eager to learn as much as I can regarding this issue.

[Tom Pasley]

Hi Mark,

Yes, I came to a similar conclusion around the same time, and built a d-i-y resolver and knowledge-base, unfortunately, we still rely on vendors/publishers in the end, and often there's differences in what we think we should have access to, and what is reported... a standard reporting format for holdings/access by publishers would be a good start (think COUNTER but more detail!).

On a related topic, we have "rules" to create links, and I've found this wiki handy:
http://urlclearinghouse.wikidot.com/home

[Tom Pasley]

oops - just read [some of] the report recommendations! ;-}