While in UNC-CH for JCDL I've had occasion to rant with/at some people about the state of the integrated library system marketplace — including, of course, how we got into the spot we're in and how we might get out of it (and those people were kind enough to engage in the rant). Along comes a series of posts from Casey Bisson and Nicole Engard ultimately pointing back to John Blyberg's "ILS Customer Bill-of-Rights" that is singing the same tune. There still seems to be a desire for a solution from an existing vendor, and in fact that was part of counter-points brought up by some on the receiving end of the ILS-must-go rant. (Paraphrased: 'No one can satisfy the need of a library like a library automation vendor' and 'As libraries we're not strong enough to take on the task of building the next ILS ourselves.') Yet there does seem to be this mounting pressure to get control again over our data and how we present it to patrons.
What's In A Name?
"What is the OPAC?" is a question that has been bothering me for quite some time and the reasons why got crystalized earlier this month on the Code4Lib mailing list with Eric Morgan from Notre Dame proposing the creation of a mailing list to talk about "The Next Generation OPAC." I couldn't help but fire back with "Perhaps I'm too much of a radical, but for me even leaving 'OPAC' in the
mailing list name would be to already admit defeat."
That started a great discussion. There was this comment from Peter Schlumpf:
The catalog is going to be with us in one form or another. One thing that never ceases to amaze me is how the library field is sooo quick to throw overboard useful tools just for the sake of something different. The ILS in its present form has LOTS of room for improvement but it doesn't mean we have to hide it behind other labels or have to turn it into some nebulous concept that doesn't mean anything....The catalog is one of the the main interfaces to the library that all patrons use. How can we make that experience most productive? We need to pay lot of attention to that.
I would challenge the notion that the OPAC is a "useful tool" — if it was, our patrons would still be using it. As it is, anecdotal evidence suggest that the OPAC is the last thing they would choose to use. And this reply by Alexander Johannesen:
I don't think the OPAC will go away, nor that it absolutely must, but the very idea of an OPAC is based on knowing what our patrons want; books that we've cataloged. But all too often we have no idea what they want; all we've got are assumptions. I think we've come a long way, but the time to look anew to what purpose the OPAC serves certainly is ripe.
I'll agree with Alexander, and I hope it is for the same reason. If you want to call the ILS/OPAC an inventory of our physical collections, then that's okay. By definition that means that it is not an inventory of our digital holdings. We can have a debate about whether AACR is a good way to describe a physical item. (MARC, on the other hand, as a container of a descriptive record has got to go.) On the other hand, you've got to be prepared to add to that debate what is the proper way to describe other assets -- and it ain't AACR/MARC.
Is it just me, or does anyone else feel that the very idea of having a catalog as an important component of a library smacks of retrograde thinking? To my mind, in a clean-slate NG Library architecture, the library catalog should only exist as a facade that recognizes of the vanity of libraries and the people who fund them.
I can think of no technical justification for library catalogs as we look forward. If not the next generation, then the next-next generation of libraries. The functions that exist today in library catalogs need to be pushed in two directions- toward the user on one hand, and towards global registries on the other.
Along with Teri, I'll disagree with Eric on the extreme perspective of a (presumably single) global registry. One thing that I suspect I've learned with the OhioLINK DRC project is a phrase I can't claim to have coined called "institutional ego." It is important that an institution maintain its identity. But I also disagree with Teri about the solution:
I agree that we need to be thinking about the way libraries will look in the future. But to say that the library catalog is serving only the purposes of the people who fund them and feed on their vanity, is pretty strong and misguided. Maybe you ought to sit with a reference librarian and ask why and how the catalog and OPAC are used.
Listening to ourselves (librarians in general) is what is getting us into this situation in the first place. We keep focusing on increasingly small improvements with a relatively low return on investment while users of a whole new modality of communication (call it "Web 2.0", if you will) look over their shoulder (if we're lucky) and wonder why we're not keeping up.
The Disaggregated Library System
Throughout the discussion there were those that offered points of view of what the ILS/OPAC actually is — or at least what it could be if you were to start from scratch. And because we need to do it inexpensively and have it communicate with a variety of other systems, let's see what kind of off-the-shelf software we might be able to use:
- An inventory control system. We've got to know what we've got and where it is.
- A "point-of-sale" system. Yeah, we're not selling our books -- it's more like a rental. So we're up to an inventory control component plus a rental tracking component.
- An acquisitions/accounts-payable system. We've got to buy stuff. But I think we can buy record numbers -- record numbers that point back into the inventory control system for things that we have, if you will, "backordered."
- A description system. Let's face it -- the obsession with which a library describes an item is second to none. Of all of the pieces that could be found off-the-shelf, this one is the least likely to be found. If after all of the discussion of the pieces we come back to needing a really good description system, then let's focus our energies on that rather than the rest.
With a foundation based on these components — a "Library Service Oriented Architecture" if you will — we'll be in a much better position to meet the needs and desires of the users today and change to meet their new needs and desires in the future. It's not everything we need (I hear there is the rumblings of a debate on the cost effectiveness of serials control systems -- do we have to have one of those), but it is a place to start.