Sunday, 12 September 2010

Is it too late?

Several comments on the last post referred to the so-called "next generation" Opacs, and they struck a chord with me as I am in the process of implementing one such (which is the reason for my too frequent absences from this blog just lately). I agree that they have an enormous potential for revealing and exploiting the information that we have been putting in bib records for years and which our present Opacs have been unable to make use of - and, hopefully, a better subject search will be one of the benefits.

But I can't help thinking that the timing of these new developments is unfortunate. Yes, a better Opac, a more attractive and engaging and effective Opac, is exactly what we want not just to help our users (which is always the most important thing) but also to show our masters that what we do has a practical value and importance. At last it is obvious why we put all that arcane coding into our records and why we fuss about consistent forms of headings, because at last everyone can see what use it is.

However, at exactly the same time as it suddenly becomes worthwhile to catalogue things "properly", I (and I am sure I am not alone) continue to face a reduction in resources which will mean cutting back even further on full standard cataloguing and the staff who are capable of doing it. For years we have been passing more and more of the bread-and-butter cataloguing to non-professional staff and in the process have necessarily been simplifying what we ask them to do. That means, for example, not bothering overly much about Leader and 008 coding. In the context of our old Opac, which didn't make any use of such things, this made perfect sense - why fuss about something that wasn't being used?

Now I am looking at an Opac which depends on accurate and detailed coding of the fixed length fields in order to express format and form and all sorts of other very useful stuff (all of which I very definitely want my users to see). For a database that contains a fair amount of simplified catalogue records as well as all sorts of gruesome legacy data, that means re-cataloguing stuff. I face a daily struggle to persuade my masters of the case for cataloguing stuff in the first place, never mind re-cataloguing it!

If we had had these wonderful Opacs a few years ago, I could have shown what would happen to the catalogue if we simplified and downgraded our cataloguing. Look, I could have said - if we don't put the detail in, you can't use the catalogue to do this, or this, or that. But what my wonderful new Opac shows is the inadequacy of what we have done and I fear that it is now too late to turn back the clock. I do hope I'm wrong.

2 comments:

  1. Very interesting point about next gen opacs. Legacy data will always haunt us I think. What next gen opac are you implementing (just curious, I work somewhere which is currently implementing Aquabrowser)?

    ReplyDelete
  2. Talis Prism 3 - which, to be fair, is a product still in development.

    Yes, legacy data will always haunt us, you're right. But there's a difference between legacy data which can't be helped, as it were, (genuinely old records, or the conversion of genuinely old records, which in their time were as good as they could be)and legacy data which is the result of recent short-sighted cuts in resources because a good enough case couldn't be made to resist the cuts and preserve the data standards. In that sense, we're still adding legacy data.

    ReplyDelete