Monday morning I had the opportunity to stand up with two other colleagues and present our findings on the future of the catalog to an audience of 60 or 70 directors from the Oberlin Group of libraries. One colleague gave an overview of the ILS plans at each of the 5 Minnesota Oberlin libraries. Then I presented on our multi-school taskforce’s discussion and recommendations. And finally another colleague explained what would be happening next, and left the directors with some food for thought: what would it take for this group of libraries to significantly contribute to the development of an Open Source ILS (Integrated Library System, for my non-librarian readers)? All of this led up to Josh Ferraro from Liblime and his presentation on Open Source ILSs and the kinds of support available.
Here’s the basic content of my ten minute part of this presentation, fleshed out slightly from my speaking outline:
Introduction
Our task force on the future of the catalog grew out of a series of conversations our libraries had been having over the course of last year about our catalogs. After one particularly interesting meeting at which 5 groups proposed their idea of a next-generation catalog, our directors commissioned us to formulate a plan that would propose solutions for the current problems with the catalog, and would suggest how we might enact those solutions.
It’s important to note that we only discussed the front end (the user interface). We deliberately chose to ignore the “back room” functions in the hopes that a narrower focus would give us a useful entry into the broader set of ILS issues and a sturdier framework for further discussion.
The Problems
The problems we identified can be loosely grouped around the three purposes of library catalogs, as described by Charles Cutter back in 1876. Remember that catalogs exist to locate, collocate, and advise (to find things, find things like a given thing, and help researchers determine the usefulness of things). So, how do our catalogs measure up?
- Locate: Our systems do a decent job at this if and only if our researchers find their way into our catalogs.
- Collocate: Our systems work decently well as gathering toolsas long as researchers want to gather things according to author or subject heading, and as long as the available subject headings resonate with the researcher’s information need. But with the rise of interdisciplinarity and with increasing amounts of information available on the free web, these institutionalized gathering systems are becoming less and less comprehensive.
- Advise: Our catalogs do not do a good job of providing flexible and robust ways of assessing an item’s value and recommending further action. It seems like only yesterday that tables of contents were a luxury, and even now they are unevenly applied. Modern systems, though, are capable of much more robust description (to the point of showing the thing itself, the full text), and they are capable of learning from user behavior and from other supplemental data to recommend action.
In addition to these rather fundamental problems, our researchers are becoming used to working with systems that leverage massive amounts of data (data drawn from all that information we’ve been adding to records for years but never using… data drawn from user behavior… data drawn from all sorts of new places) in order to create rich and personalized experiences online. They are also increasingly expecting to be able to search at the collection level, the item level, and even within items. And they need access to these collections from sources that help them make wise and informed decisions about which collections, items, and parts of items will fill their information needs.
Our Conclusions?
Unsurprisingly, our taskforce concluded that our catalogs are not flexible enough to meet these goals. What’s worse, we learned that the underlying structure of our systems is restricting enough that simply adding little widgets will not fix the fundamental, silo-ish tenancies of our catalogs.
So we set out to describe solutions to these problems, but decided to back up and envision these solutions from the ground up: from the philosophies and architectures that make up our “Catalog Credo,” the three fundamental principles on which we believe future systems should be built and against which any system we adopt should be measured. You have the report that we drafted, so I’ll skip the details and just hit the highlights.
Principle 1: Flexible data feeding flexible tools
Freeing data is, perhaps, the most important of our three principles. Basically, this means that we want to become a useful part of the Internet rather than re-invent the Internet. We want to feed our data out to other systems rather than incorporate “all useful information” into our system. This way, we can maintain the powerful and important coherence of our selected material without developing barriers between this material and the free web or other information tools our researchers use.
According to this principle, we advocate that libraries provide “an” access and discovery system rather than “the” access and discovery system. This system is essentially an interface capable of interpreting a wide variety of standards-based data that can be drawn from many sources, including our inventory. We of all people recognize that metadata is fundamentally communicative, so we should allow it to communicate.
This principle also assumes that our inventory could be fed to other systems. This way researchers can mash our content up with other content that they find indispensable, or with programs that fit their workflow.
Principle 2: Intellectual connectivity between resources
This principle relates directly to the “Advise” purpose that Cutter identified. It means that our new catalogs should guide researchers through the system and through the web of related resources. Things like FRBR, faceting, citation linking, and recommender systems (based on user-generated content, user behavior, and who knows what else) could help our catalogs fulfill this principle.
Principle 3: Interactivity
Our system should be able to interact with other systems and with our researchers. Researchers should be able to add content to the system (tagging, rating, etc.) and suck content out of the system (saving, sending, bookmarking, etc.). In this way, researchers can help us build the intellectual connections between items that we mentioned in Principle 2.
(At this point, I turned it over to my colleague who explained our timeline for change and what our next steps would be.)
I just have to say that after all of this I had my first opportunity to hear Josh Ferraro speak about Liblime, Open Source ILSs, and Koha, and may I say? Impressed. The rate of development, the flexibility, the “of course, you always have access to your SQL database,” the flexibility… and did I mention the flexibility? The rate of development? Yeah… Impressed.
Comments closed