« Contributing your data - but at what cost? | Main | Talis Source goes into a Limited Release! »

Holding data hostage

We held a Research Day a couple of days ago, which many of our fellow vendors in the domain - AdLib, DS Ltd, Ex Libris, Innovative Interfaces, IS Oxford and SirsiDynix - attended.

I'm very grateful that they took the time out of their busy schedules to be involved in what turned out to be a useful day. Certainly the feedback we've received thus far has been positive. Of course, we know that there's a fair amount of healthy cynicism that exists between vendors and rightly so. We reside in a very competitive market. So I appreciate that there were discussions that took place internally before invitations were accepted. Questions like "what's the point?" and "what will we learn?" are obviously asked. And of course, in a domain like ours where collaboration has not been a watchword, I can't criticise that judgement.

Was it a Talis soapbox session? I hope not. We have a particular view of the world, which is open to challenge. So we really did appreciate the opportunity to have these perceptions challenged by other stakeholders in the domain and of course they did.

I was involved in a couple of the presentations, one which was "Broadening Participation". This session was a development of the arguments published in the "Broadening Participation" paper.

I'd like to expand on some of the themes from the Paper in subsequent entries. But suffice to say that in it we consider what the barriers are to libraries' participating in resource discovery and sharing initiatives. And one of those barriers is technical complexity.

Technical complexity, or the individualised requirements that libraries have for data export, is a justification that some vendors use for charging libraries for the export scripts they need. I don't know the rights and wrongs of this. Perhaps there is an amount of bespoke work required by libraries to enable only sub-sections of their catalogue to be exported which, in turn, requires developement from the vendors concerned.

I would welcome some debate on this. In fact, I would ask the question of libraries - do you ask your vendor to do complete catalogue exports? Or, do you ask your vendor to restrict exports to specific subsets of your catalogue? Because there are certain collections that you do not want to be exposed for interloan purposes?

I guess if you are submitting a contribution to a union catalogue primarily used for ILL purposes, then you are going to try and restrict the catalogue to those items that are actually available for interloan. But what if there is another way around this? What if a complete catalogue contribution could be effected, free-of-charge? And if the complexity of what is available for interloan and what is not could be tackled elsewhere?

That's essentially what we propose as the solution in the Talis Platform. We have a Directory which is scalable for the purposes of allowing libraries to register their ILL policies. It could be used to validate which holdings are available for interloan from a library which are not. But more about that in the future.

We believe that libraries should be able to liberate their data free-of-charge for the purposes of participation in whichever initiatives they see as important. On that basis, we've published our own scripts for Talis libraries to export their data, both for Talis Source and for the UnityUK service here.

It was refreshing to hear from other vendors like Ex LIbris and AdLib that they do not charge for exports either and never have done. I hope that libraries will ask why if they are having to pay for exports of their data, as Bert Drenth from AdLib put it, their data is being held hostage?

Technorati Tags: , , , , , , , , , , , <, , , , a


TrackBack

TrackBack URL for this entry:
http://blogs.talis.com/mt/mt-tb.r37.cgi/366

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)