discovery layers: a primer


suppertime2 by haydnseek, via flickr

For the past few months, the bulk of my working hours have been focused on learning about discovery layers. At my institution, we are in the early stages of selecting, testing and implementing a discovery layer & I am currently chairing a 9-person team (eep).

It’s really an enormous project with implications across the library. I thought it might be helpful to have a brief primer on discovery layers with some links for further reading.

What is a discovery layer?

In my local context, when we say discovery layer, we really mean web-scale discovery. A nice (and only slightly technical) definition of web-scale discovery is,

A preharvested central index coupled with a richly featured discovery layer providing a single search across a library’s local, open access, and subscription collections (Hoeppner 2012).

So, technically the discovery layer is really just the user interface for searching (almost) all of our stuff at once: books, articles, and whatever else we decide to put in there. The ‘central index’ refers to that stuff.

If you really want to have a grasp on the vocabulary and current players, Athena Hoeppner’s recent article The Ins and Outs of Evaluating Web-Scale Discovery Services, referenced above, gets pretty technical but provides a strong state of the field.

Why a discovery layer?

We are attempting to do away with the silos of information (poor silos, they really get a bad rap these days). Whereas previously a user would have to search for books in the catalog and perform a separate search for articles in various databases, we are pulling our local content together with a significant portion of subscription databases to enable a single-search experience.

I know what you’re thinking: “So, we’re trying to compete with Google? Sounds like a losing battle.” Yes and no.

Yes, a discovery layer should provide speedy natural language searching. We know from studying our catalogue search history that our users come to our systems with assumptions about search functionality & are frequently frustrated and confused by the emphasis on controlled vocabulary.

And no, “selling” a discovery layer as Google-like will not hold water. Pete Coco said it well in a January 2012 blog post for ACRLog, Convenience and its Discontents: Teaching Web-Scale Discovery in the Context of Google:

First and foremost, what web-scale discovery borrows from Google does not make it Google. Searching Summon [a Serial Solutions product] for scholarly articles will never be like searching Google — not because Summon cannot approximate Google’s user experience, but because scholarly communications will never be like the things students use Google to find.

Pete’s article is worth a read: he addresses some benefits and limitations of a discovery layer, including a warning against an emphasis on convenience.

So, the discovery layer will cover everything?

As it stands, the central index will not (/never?) include absolutely everything.

In some cases, this involves a conscious decision not to include particular content that we determine to be inappropriate in this ‘search everything’ environment. For example, highly subject-specific/ niche databases might be a poor fit for a discovery layer & only serve to confuse your users. Tough call.

In other cases, it is because certain vendor platforms will not play nicely with databases from their competitors. I don’t want to gloss over the ‘vendor agnosticism’ concern here. It is an issue. And just like how we can’t access Google’s algorithm for determining relevancy of search results, the same is true for proprietary discovery platforms. I’m still thinking through the implications of this. Mita Williams, always eloquent, touches on this problem in a November 2011 blog post, Practice makes the profession.

Um, this was confusing. I thought it was supposed to be a ‘primer’?

Yeah. Sorry. Turns out that discovery layers are just really complicated. To be honest, it’s been a pretty overwhelming project.

But, I’ve found some sanity by adopting the user experience design approach as described by JJ Garrett in Elements of User Experience book. More on that in another post — I’ve become a real convert to this UX stuff.


Hey, what happened to the scoop?

So, I decided to scrap the scoop. I will still share monthly (or more frequent?) posts on e-learning, teaching, communication, and recent publications, but now that this has moved to my blog it no longer made sense to maintain the guise of a publication with issues etc. Same content = no more silly name.


Got Something To Say:

Your email address will not be published. Required fields are marked *


This is excellent! I spend so much of my day looking through the library catalogue, connecting to the databases and wondering why everything has to be so separate. Sometimes I’m not sure what I’m looking for and that’s why I’m searching!
Thanks for sharing a bit of this process, the background thinking and so many great links!

Thanks for reading, Giulia :)

Do web-scale discovery layers sometimes come with an integrated cataloging interface that can be used by library catalogers to upload/edit records directly online?

Eugene: My understanding is that the ILS remains as the cataloging interface & the web-scale discovery system sits on top of that, pulling the data in & displaying it.
Sorry, I’m no pro when it comes to back-end interfaces for cataloging.
If anyone else has a better answer, please post it here!

[...] few weeks ago, I wrote about the web-scale discovery implementation project that has taken over my (work) [...]

[...] with my recent (and ongoing) involvement with the implementation of a web-scale discovery service (I blogged about it here). I found the UX design process an ideal way to focus our work on user needs, and the approach has [...]

Copyright © 2017. Powered by WordPress & Romangie Theme.