How OPACs Suck, Part 3: The Big Picture

By Karen G. Schneider | In my two (Part 1 here, Part 2 here) earlier pieces on this topic, I focused very narrowly on some fairly obvious limitations with online catalogs, limiting my discussion to weaknesses in OPAC searching from the user's point of view.

A tag cloud generated by this post. There are other issues with online catalogs much bigger and more problematic than search results—problems that can't be addressed by improving relevance ranking or adding spell-check (however valuable those features are to OPACs).

The fundamental problem with today's library catalog is that it suffers from severe literalism. Even with a few bells and whistles, today's OPAC is a doggedly faithful replica of the card catalog of yore. This isn't a failure of any one vendor; by and large they're delivering what librarians think they want. It's a larger failure of vision.

First Literalism: The OPAC Is a Citation Index
One major problem is that the online catalog is merely a citation index. It doesn't index the book itself—only a mere handful of terms in its metadata. As librarians, we're accustomed to this. But our users aren't. The user of tomorrow grew up in a full-text world. For that user, the limitations of the online catalog make no sense.

In the pre-digital days, it was logical that the catalog was strictly a citation index. But no matter how much some might wish it otherwise, every book published today is born as a digital object. A book moves from creation to publication as a computer file. The final product—a paper-based book—is an elegant but technically unnecessary anachronism.

I'm not debating the future of paper-based books—that's a discussion for another time—but I am saying that the content of many of the books in online catalogs—including, I would have to think, nearly every book published in the last fifteen years—have digital correlatives that should be essential to the foundation for retrieval in a modern library catalog. In other words, make it easy to search "good night mittens" in an OPAC. It's not dumbing it down—it's smartening it up to where users are today.

Second Literalism: A Data Set for Every Library
In the pre-digital era, every library maintained its own card catalog. That was absolutely logical: how else would users find a book in the library? But in the digital era, every library still maintains its own card catalog—at least in the sense of having a unique database with a unique record for each bibliographic entity. Step back and ponder how really odd that it is. It would be as if Amazon created a local data set for each customer, with a separate installation of Amazon as well.

Librarians might rush in to tell you how much value customization has for their local records. First, tell me: just how much do you have to tweak out a record for The Da Vinci Code to meet local needs? Even if you do want to customize a record, wouldn't it make more sense if the record stayed central and the customization stayed local? Think about every other Internet database you interact with—YouTube, MySpace, Bloglines, just about any online bookstore, even ALA's nifty new Booklist Online. Why is the OPAC different?

It's not as if that information isn't available centrally—particularly with OCLC gobbling up, er, I mean, merging with, RLG. Speaking of booksellers, the American Booksellers Association sells software to bookstores that is used to search, view, sell, and manage book inventories. If booksellers can use a central database, why can't we?

Third Literalism: It's Still about Books
Also, the online catalog is still about books or book-like objects such as DVDs—in other words, full-length physical manifestations. Everything else gets thrown on top like pineapple on a pizza. There have been some philosophical strides forward since the days when many librarians refused to catalog "non-print" media (yes, some of your ancestors scorned anything that wasn't a book), but for the most part, the central software used to manage the library's content falls down when the content is electronic and/or far more atomized—such as your typical journal article. It doesn't matter how good your search function is if your content is elsewhere.

Fourth Literalism: The OPAC as Central Library Function
Have you ever owned a tool that did too many things, none of them well? Perhaps the greatest literalism of all, with respect to integrated library systems, is that they are one continuous product to begin with. Lorcan Dempsey, VP of OCLC, has been making the case on his blog that the next-generation integrated library system should be dis-integrated. He points out that the modern ILS weds an inventory system with a discovery system—in the end doing poorly at both.

The online catalog functions reasonably well for locating known book-like items cataloged within the library's collection, which complements the traditional roles of the library. But library usage is changing, with libraries reporting higher foot traffic and more use of meeting rooms and special space, even as book checkouts remain relatively stagnant.

Often librarians find themselves shoehorning user authentication, tools for journal article discovery, network and equipment usage management, and payment tools onto ILS software—as if the ILS were the car driving library services and these other tools its accessories. So much attention is paid to adding yet more features to monolithic software that we forget the software's function in the first place—to help the discovery process.

Not only that, but the online software, freighted as it is with so many duties, cannot be lithe enough to quickly adapt to the revolution in networked software that is changing how people function on the Web and increasingly in their lives.

On such sites as Amazon and Flickr, the user is not simply interacting anonymously for simple transaction functions, but as users rate, tag, collect, review, save, bookmark, e-mail, comment on, subscribe to, and share content, they are creatively engaging with the software and its content—transforming it, adding to it, improving it, participating in it. Some catalog vendors try to keep up, but most additions or changes to catalog software force an expensive and time-consuming "ripple effect" of modifications through the ILS.

Where to?
The catalog of the future wouldn't be a catalog; it would be a series of standards-compliant Web services that could be mixed and matched. A small library could use Library Thing to catalog its inventory, tack on a nice search interface courtesy of some search vendor, and buy acquisition and serial modules from yet another vendor. Vendor modules could mingle with open-source Web services, empowering upstart library programmers to add new services now, not three years from now, while allowing vendors for other modules to focus on their core products.

The local record would be obsolete. Libraries would use global records, locally modified as the spirit and the budget moved them. Discovery would be a rich, satisfying experience that would leverage the potentially powerful combination of library-generated metadata, user tagging and other user interactivity, and full-text Web discovery.

Perhaps the library application would continue to be a visibly separate database; but without the complicating anachronism of local records and a search experience far removed from where our users are—the Web—the online catalog might not only be dis-integrated into separate services, but re-integrated seamlessly into the Web—and among other library services, such as journal databases. Web services such as Open Worldcat technically make library holdings native to the Web; perhaps search-engine widgets could further enhance discovery. A simple button built in to every major search engine could lead users to our services.

This is a good time to atomize the catalog and start over. For years we've been feeling depth charges rumbling throughout this profession: MARC, some say, should die, and traditional cataloging ain't lookin' too good, either. It's time to dis-integrate the catalog, weave it into the Web, and push forward to the future.
Technorati tags: , , , , , , , , , , , , , , ,