Saturday 8 January 2011

RDA and OPACs

Following on from my previous post, about the gap between the standards we apply when creating data and the ways in which we want to use it, I would like to give some thought to what lies in the middle - our OPACs.

We are all data creators - we all create data and edit data and hold it in databases - and we all follow some sort of rules (AACR, RDA, ONIX, DC or whatever) to structure that data.

Equally, we all have views on how we want to make the data usable, the ways in which we want to make it available, the things we want people to be able to do with it.

We don't necessarily agree about either the kind of data we want, or what we want to do with it. But the fact is that in the middle, for most of us, sits our OPAC - which dictates both the structure we use and what we can do with it.

I often curse our LMS supplier into heaps - why can't our OPAC do this, or that? Why does it take so long to persuade them that this (or that) really is important and something our users are waiting for?

Sometimes I feel sorry for our LMS suppliers - if we can't, as a cataloguing community, agree about our data and its purpose, how can they possibly develop the means to satisfy us?

But for most of the time we are all making our decisions - about what our data should be like and what it can do - on the basis of the product in front of us at that time. Should we ensure that our data is to the tippest of top standards because one day an OPAC will come which can actually use all that data to its fullest potential? Should we tailor our data to what our OPAC can actually do at the moment and tweak and twiddle and bodge the standards to get the result we want now, never mind what happens five years down the line? Or do we make our data according to what we think we and our users will want in the future, even if we don't, and can't, actually know what we or they will want then?

You see, I think that is what RDA is trying to do. I think RDA is looking into the future and predicting what we will all want and trying to make provisions for it. We (some of us, including me) criticise RDA because it neither sticks with the standards we've already got, nor offers anything our present OPACs can make use of in any kind of a helpful way. And prediction is a sticky business - look at the predictions made 20 years ago about how we'd all be living now and they are mostly wrong.

What do we want, really really want - something that used to work, something that works now or something that might work in the future?

2 comments:

  1. "You see, I think that is what RDA is trying to do. I think RDA is looking into the future and predicting what we will all want and trying to make provisions for it."

    Yes. I see this as a problem, and yet many RDA supporters seem to see this as one of the pluses of RDA. I'm not really sure why it's considered a plus - who do they think is going to provide us with the systems that will make use of this data? Our ILS vendor can't/won't even help us fully and correctly utilize the data we have - how am I supposed to trust that they will build a system sometime in the near future that will make RDA records more useful than our current ones?

    I'm still confused about why there's all this work done on RDA, when the general consensus seems to be that the real problem is actually either ILSs or MARC, or both.

    ReplyDelete
  2. Thanks for this, Melissa. I don't have a problem with RDA trying to look into the future, just that looking into the future is a difficult thing to do and I'm not confident that RDA is necessarily going to get it right. But, like you, I can see problems with the ILS vendors, eevn when they are doing their best to please us both now and in the anticipated future. I think that RDA supporters see library data in the future as being independent of ILS's - that RDA wil liberate library data into the wider world where it can be adapted and used outside libraries. But you and me, we're stuck within libraries and with our ILSs! And that is going to be a problem for us.

    ReplyDelete