In tight budgetary times, this approach might seem questionable. Right now, we’re putting up a new repository structure (in addition to our existing ones) to keep our various digitized special collections and make them available for discovery and use. We hope this will make our digital special collections more uniformly manageable, and less costly to maintain.
At the same time, we’re continuing to maintain an institutional repository of our scholars’ work on a completely different platform, one for which we pay a subscription fee annually. I’ve heard more than one person ask “Well, once our new repository is up, can’t we just move the existing institutional repository content into it, and drop our subscription?”
To which I generally answer: “We might do that at some point, but right now it’s worth maintaining the subscription past the opening date of our new repository.” The basic reason is that the two repositories not only have different purposes, but also, at least in their current uses, support very different kinds of interactions, with different kinds of audiences.
The interactions we need initially for the repository we’re building for our special collections are essentially internal ones. Special collections librarians create (or at least digitize) a thematic set of items, give them detailed cataloging, and deposit them en masse into the collection. The items are then exposed via machine interfaces to our discovery applications, that then let users find and interact with the contents in ways that our librarians think will best show them off.
The repository itself, then, can work much like a self-storage unit. Every now and then we move in a bunch of stuff, and then later we bring it out into a nicer setting when people want to look at it. Access, discovery, and delivery are built on top of the repository, in separate applications that emphasize things like faceted browsing, image panning and zooming, and rare book page display and page turning.
Our institutional repository interacts with our community quite differently. Here, the content is created by various scholars who are largely outside the library, who may deposit items bit by bit whenever they get around to it (or when library staff can find the time to bring in their content). They want to see their work widely read, cited, and appreciated. They don’t want to spend more time than they have to putting stuff in– they’ve got work to do– and they want their work quickly and easily accessible. And they’d like to know when their work is being viewed. In short, they need a gallery, not just a self-storage unit. They want something that lets them show off and distribute their work in elegant ways.
Our institutional repository applications, bundled with the repository, thus emphasize things like full text search and search-engine openness, instant downloads of content, and notification of colleagues uploading and downloading papers.
We could in theory build similar applications ourselves, and layer them on top of the same “self-storage” repository structure we use for special collections. (Museums likewise often have their exhibit galleries literally on top of the bulk of their collection kept in their basements, or other compact storage areas.) But it would take us a while to build the applications we need, so for now we see it as a better use of our resources to rely on the applications bundled with our institutional repository service.
(An alternative, of course, would be to see if an existing open source application would serve our needs. I hope to talk more about open source repository software in a future post, but we haven’t to date decided to run our institutional repository that way.)
I hope I’ve at least made it clear that for a viable institutional repository, you need quite a bit more than just “a place to put stuff”: you need a suite of services that support its purposes. In Part 2, I’ll enumerate some of the specific services that we need or find useful in our institutional scholarship repository.