So, whose catalogue is it anyway?

So, whose catalogue is it anyway?

Contributed by: Heather

Back in the day, before all this high-falutin’ technology came along and spoiled everything, catalogues and cataloguers knew their place. They were solid and reliable and the question of design didn’t really arise with either of them. The catalogue was a sizeable piece of furniture, unchanging down the years, demanding no maintenance beyond the occasional tightening of a rod, the waxing of a drawer to make it run smoothly or a little light dusting. Maybe we got the polish out at Christmas, I don’t remember. Cataloguers were the people who created the cards that went into it, and their guiding principles, whether writing or typing, were legibility and neatness.  Happy the typist who could produce stencils for a spirit duplicator with a lightness of touch that did not result in the centre of letters like o and g falling out and resulting in an unsightly blot!

Microfiche catalogues followed the same principles of clear layout with no fuss or frills. They were plain, simple and serviceable. Legibility became even more important as we were all convinced that poring over microfiche all day long would end in us going blind. Little did we know what the future held for us in the way of computer screens and blinking cursors (and you may read “blinking” in either its literal or colloquial meaning).  Early online catalogues followed suit, looking pretty much like the fiche catalogues they replaced.

Nowadays it seems that design is king. We want to apply design both to the way the catalogue looks, and what it does, and sometimes we blur the distinction between the two.  We want pop-ups and rollovers, pictures and links – speaking for myself I’d cheerfully commit murder to get a virtual shelf browse. We want the catalogue to look attractive, to be engaging and to offer every kind of trick and treat; we want all the sweets in the sweetshop, all at once.

But here’s the problem – most cataloguers (there are honourable exceptions) do not have the necessary IT skills to design a catalogue from the ground up or even to tinker with an existing product in order to enhance and alter it. As we become more and more demanding, we have to hand over catalogue design to experts from other areas who may know little or nothing about libraries, catalogues or users.  Cataloguers are still the people who create or derive the data, but we have little or no say over how it appears on the screen or what can be done with it. We stoke the furnace but we don’t drive the train, and that’s one reason why cataloguers are increasingly divorced from the front-line service. Our public-facing colleagues, and our users, want the bells and whistles just as much as we do but they know that we aren’t the ones who can provide them. 

 And it seems to me that this gap is in danger of widening still further.  What we lack at the moment is mostly skill (we don’t lack enthusiasm or imagination), and skill can be learned.  Even the dustiest and crustiest of us can engage with HTML and CSS and goodness knows what all, if we really want to and are prepared to find the time (usually our own time, be it said).  Lots of us still have catalogues that can be modified locally, if we just know how and are prepared to roll up our sleeves and get stuck in.

 What gives me the shivers even more than the thought of learning HTML and CSS and all the rest, is that increasingly our catalogues are remotely-hosted. That seems to mean that all the development takes place on a misty mountain-top far away and is then “rolled-out” to us, like fog. It just – well, it just arrives. One morning it is there, when it wasn’t there the night before. And as cataloguers we are even more disengaged from the catalogue than before.  We are scarcely even aware that we create or derive the data that the magicians work such wonders with. We are dazzled by the glittering surface. Pretty, pretty things!

I don’t know the answer. I don’t know what we have to do to get the catalogue back where it belongs, in our own hands. Maybe between the increasing sophistication of technical knowledge that is required to drive this machina ex deo, and the lack of resources, time and energy that restricts us nowadays, we have no choice but to relinquish the design to the experts.  But I’d like to be sure that everyone remembers there is still a link between gleaming bodywork and what’s under the bonnet, and that without the engine the machine just won’t go anywhere.


8 thoughts on “So, whose catalogue is it anyway?

  1. Check this out for a virtual shelf browser:

    This is a neat argument in many ways. I’d personally argue that a lack of understanding of how systems have developed on the part of cataloguers has partly lead to the gap between Marc21 and modern data container formats and syntaxes utilised in web based environment, hence its long overdue overhaul. Not the fault of cataloguers, but an observation none the less.

    No real answers either, but I’d at least question the premise that a catalogue belongs in the hands of those ‘who drive it’. That may be true if they are best placed to understand the needs of those who use it, but that may be a better function of front of house staff. At the very least, cataloguing practice should be dictated by this understanding, so hopefully that knowledge is already in place. Frankly, the whole front / back of house debate is not a helpful viewpoint anyway.

    I’ve seen web based IT projects totally derailed by so called experts of human interaction failing to understand underlying data models and complexity. I’ve also seen dreadful interfaces but together by those with a deep personal understanding of the underlying data and little else.

    There must be a happy medium.

    • We’re pretty much agreed about most of this – a successful catalogue needs a mix of technical IT knowledge; understanding of the data and its architecture; and sympathy with the user community. That’s a big ask! Ideally yes, people with different skills would work together, but I don’t see this happening in real life where we are constrained by lack of resource and lack of time, as well as by mistrust between the people with those different specialisations; however I still feel that it is the cataloguer who should take the lead and be responsible for the catalogue, even if we need to reconsider and redefine the skillset that a cataloguer needs to be able to do it.
      Whether there is one single answer – a one-size-fits-all solution – that, if we could only find it, would suit all users is another question. And another blog post, probably!

  2. Interesting and thought provoking but you are very lucky to still have a Bibliographic/Resource Services Department. Ours went in about 1995. One thing I do agree with you on though is your “I’d cheerfully commit murder to get a virtual shelf browse” comment.

    I semi-jokingly referred to such a beast about 15 years ago whilst describing my invention of what I termed an “Argos Library”. This didn’t let users near the actual books for browsing but provided an arm-chair comfortable zone where users browsed the stock virtually, selected their items, clicked send to Checkout and then went to a point to collect them. No huge spaces for space, just warehouse type shelving, every book “in its place” and no-one stealing books, etc.
    Do I like the idea? Mmm, maybe not totally, but it does have it’s merits and I’ve subsequently heard someone else describing something very similar.

    But you are correct about the cataloguers that are left having to learn different skills if they want to retain some control over their efforts. However, with centralised cataloguing services I think everything will seem to “just arrive” and the creators of the OPAC or whatever you may call it will hold sway.

    • I think that your “Argos Library” would be step too far for me – I’d still want to be able to choose my reading matter by actually handling the book first – but a remote browse would at least give me somewhere to start looking. Of course, enable a remote browse like this on the Kindle (or similar) and we could do away with libraries as physical spaces with real books as well as the bib services departments…

  3. This concern regarding remote services can be partially mitigated by maintaining a local discovery layer over an index. Look at Royal Holloways’ Summon / VuFind implementation. Specialized collections or archival or rare material may also benefit from customized local indexes.

    All of this adds additional cost and complexity to a solution which needs to be assessed against value.

  4. I think there is a lot of stuff going on here, and I agree with the basics of what you’ve said, but I think there’s more to be said for a bigger picture.

    _Some_ software engineers involved in creating interfaces for cataloging data (“catalogs”) DO know quite a bit about cataloging — from some combination of library school, self study, talking to lots of catalogers, etc. Even some at vendors.

    But they STILL have trouble creating interfaces that everyone likes. Because it’s HARD. Part of it being hard is that, well, we can’t do everything, it would be too expensive (meaning we’d need a lot more staff) we don’t have, we have to make priorities — and not all library professionals even agree on the priorities.

    Part of it being hard is because our actual metadata (cataloging records, bib and authority and others) are just _not good enough_. And part of that is because creating and maintaining good metadata here is HARD too. And changing the giant moving freight train of our cooperative cataloging practices and standards is REALLY HARD.

    But part of it is because not enough of the people involved in the creation of cooperative cataloging practices and standards understand what “good” metadata for software uses LOOKS LIKE.

    So I’m not sure that catalogers need to know HTML and CSS. I’m not sure those are the right technologies at the right level. I’m not sure catalogers need to know any _specific_ technologies. What catalogers need to know is ‘computational thinking’, a basic understanding of how computers operate through algorithms, what sort of things are easy for computers and what sorts of things are hard, what to _ask_ software engineers for, and how to understand their answers as to the problems for what’s being asked for, how to create metadata records that will serve the desired software purposes. Now, how do you learn those general things? You might learn them by starting with learning specific technologies — but I don’t think HTML and CSS are those technologies. Basic programming and/or SQL would get you closer. Fortunately, most catalogers are very methodical rule-oriented people, so this kind of thinking and understanding ought to be accessible to them.

    I agree with your concern about the ‘outsourcing’ of our core services to vendors, and the lack of control that entails — the lack of outlet for professional expertise. It’s not just software this applies to — especially in the world of cataloging. Entirely different models are being used for metadata acquisition for electronic documents — and they are outsourced ones. MUCH of our users interaction with ‘the library’ is something we have little control over now.

    • I am a bit sorry that everyone agrees (more or less) with me – I’d rather you had all managed to prove that I’m wrong!

      I didn’t mean to suggest that all systems people were clueless about libraries, any more than that all cataloguers are clueless about programming. It’s just that there don’t seem to be many good souls who combine a passion for both. Hopefully there will be more in the future.

      Someone else commented (on Twitter) that what’s needed is a re-think when it comes to LIS education. Is that right? Not so many places teach cataloguing anymore, never mind the relationship between data and software, records and their use. Where is the best place to get some cross-pollination between these different specialisms?

  5. Just today I was speaking to a colleague about LIS education. I spoke with some people at the city in Germany where I live, who studied kind of LIS. They are not teached in programming, they don’t know of Linked Open Data, they even barely know HTML. I mean, they are in their mid 20ies , they may work for the next 40 years in libraries. I really don’t know what to say.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s