Known-item vs. unknown-item searching

A series of project assignments and offhand conversations recently have me thinking about how well (or how poorly) our current library-ish systems support users diving in and simply exploring what the system has to offer. On the whole, most of our discovery systems focus on known-item searching, where a user comes to the system with something specific in mind that they want to find: books by a certain author, a movie with a specific title, recordings by a particular artist. These information needs are of course common, and they are in fact the focus of Cutter's first objective of the catalog.

But look more closely at c) in that first objective - we should provide access to an item when the subject of it is known. So what exactly does that mean? Most current systems in a library environment fulfil that by making text in a subject-ish field keyword searchable. When I do a subject search in a system of that sort, I get back records that have subjects containing the word I typed in. But how do users know what the words in those subjects are? Some (certainly not all!) systems provide the user a way to look at a list of subjects used in that system. The user then is expected to locate all subjects of interest in that list, then construct a properly-formulated Boolean query OR-ing those subjects together. I'll be perfectly frank and state that I believe strongly that this is silly to expect of any user in this day and age, even an "expert" user such as a reference librarian. Let's use the computing power we have!

And what about these of Cutter's objectives?

2. To show what the library has

e. On a given and related subjects

f. In a given kind of literature

Mechanisms to achieve these goals, in support of unknown-item searching, fall far short of the sophistication we provide for known-item searching. We don't provide our users with ways to look around, to explore, to just see what we've got. If I read a book that inspires me to read some more on the topic, I go to my public library's catalog, find the book I liked, and click on a subject heading (from a maximum of three!) that seems like it might be promising. And what I find a huge majority of the time is a browse screen of LCSH headings, each with three or fewer hits. The topic of interest to me tends to be the first part, but the browse index is a seemingly endless list of geographic subdivisions of the topic, interspersed with other subdivisions such as "juvenile," and, in particularly poor systems, interspersed with other headings starting with the same word as the term before the first subdivision.

What we need are systems that do an exponentially better job of starting out from an interesting thing and finding more things like it. I personally think postcoordinated subject headings would be a major advance in this area, but they're certainly not enough. Systems that map lead-in terms to authorized terms, and expand search results to include narrower terms than a matched broader term are also necessary. One can also imagine other mechanisms to build that "like" relationship, based on information retrieval research, folksonomies, and transaction logs.

I suppose my point in the end is that it's simple to build a system that searches the text of pre-created metadata fields for an entered query string. It's much more difficult to build systems that allow users to truly explore. We often forget how important that exploration function is. We look at our search logs, and see mostly known-item searches, so we think that's what we need to focus on. Of course we see that - it's what our systems are designed around! But what would happen if we started to provide relevant results to subject and other unknown-item searches? I'd bet a whole lot of money that we'd see a huge increase in unknown-item searching. Sure, for some types of materials, known-item searching may very well be the primary means of access users need. But let's at least look at the alternative, and work with actual users to see how we can provide them with exploratory functions we don't currently supply.