Everybody’s Libraries

(Note: This is the second of an ongoing series of posts on repositories. The first post is here.)

The JISC Repositories Support Project defines a digital repository as “a mechanism for managing and storing digital content.” I find this a useful definition, both for what it says and what it doesn’t say. It notes that repositories, as such, focus on content and its management. It doesn’t say anything about the kind of digital content managed by the repository, or about the use this content is put to.

A repository’s focus is related to, but distinct from, the focus of a library or an application. Repositories focus on particular information content. Applications (like Zotero, FeedReader, or Google Docs) focus on particular information tasks, like tracking citations, getting news, or authoring documents. Libraries focus on the information needs of particular communities (which might be towns, schools, peer researchers, or Internet users with particular interests). Applications and libraries may use repositories to support their tasks or communities, and some may be primarily built around one specific repository (as most libraries in the pre-computer age were built around what was in their physical stacks). But they are not identical to their repositories, and it’s often useful to distinguish the functions of a library and the functions of the repositories that it uses.

At the same time, though, you can’t plan the development of a library without thinking about its repositories. Repositories really are essential infrastructure for libraries, but not simply as a place to “capture and preserve the intellectual output of university communities” (as a 2002 SPARC white paper put it), or, more pessimistically, as “a place where you dump stuff and then nothing happens to it” (as a 2005 JISC workshop annex put it). The Penn Libraries today rely on hundreds of digital repositories, mostly run by various publishers. We also manage a few important ones ourselves. Here are a few that we manage, or are considering managing:

• A repository providing open access to the scholarly output of our researchers (what is often thought of as the traditional “institutional repository”). For this repository, we manage the content, and contract with an outside company to manage the servers and develop the software. While many faculty cooperate in populating this repository, and some faculty deposit their own work themselves, librarians do much of the work to populate it.
• A repository preserving content from some of our electronic subscription resources. This repository is normally only seen by library staff, but it’s an important part of our preservation strategy, and will be exposed selectively when subscription resources it preserves are no longer available from the publisher. We run this repository on a local server, using open source software developed elsewhere, and its content is selected by us and ingested and preserved largely automatically, in cooperation with other users of the same repository software. (We also subscribe to another preservation initiative, involving a centralized preservation repository system that we don’t manage.)
• The repository used to store content in our main courseware management system. The server is managed by us, using proprietary software, and is populated by instructors from all over the university. It is largely torn down and built anew every semester (sometimes carrying over material from previous semester’s incarnations). While this isn’t a permanent repository, it has very strong and definite persistence requirements that we have to take pains to support. And if some of our users just think of this as a place to do their teaching, and the “repository” aspects just come along for the ride, that’s a feature, not a bug.
• Repositories for various digital image collections and digitized special collections. Historically these collections have been a mishmash of systems developed ad-hoc, involving filesystems, metadata in a database, custom-built websites, backup procedures, and sometimes little else. We’re currently locally developing a digital library architecture that will unify discovery and usage of many of these collections, and we hope to similarly unify repository management for many of these collections as well. Traditionally, the content is selected by bibliographers and the repositories and collection sites created by techies; we hope that the new architecture will let the bibliographers do more repository management and site design, and let the techies do less site-by-site management and more unified service management.
• We have also tested repositories for managing numeric data, which are increasingly important shared research resources in many fields. We do not currently have a repository in production for this, but the repositories developed by projects like this one have important features for data-centric research that are not supported to the same extent by “traditional” repository systems.

As you can see from these examples, libraries like ours have all kinds of different uses for repositories, and various ways we can develop and manage them. We’re not starting repositories because they’re what all the cool Research I libraries are doing this year. We’re managing them because they help us provide what we see as important services to our communities. We recognize that different repositories have different uses, and that it often makes more sense to integrate multiple repositories into a single library than to build One Repository to Rule Them All. Once we have a clear understanding of why we would benefit from a particular repository, and what it would manage, we can consider various options for who would run it, where, and how. (And of course, what its costs would be, and how we can realistically expect those costs to be covered. But that’s a topic for another post.)

The library where I work has decided to think long and hard about its digital repository strategy. Your library may be doing this too, or may have recently done so and is now working on carrying out that strategy. If it’s not, it probably should be.

Libraries have for a long time hosted repositories of content in paper form; indeed, such repositories account for a large portion of both the budget and the floor space of many libraries. But many of them have been slow to take on responsibility for digital repositories, or have only done so in a very limited way, compared to their physical repository investments.

But while established libraries have often hesitated in taking up digital repositories, the rest of the world has not. As folks in research libraries have known for a while, a lot of the money we now spend on content pays for electronic resources held in publisher repositories. In typical arrangements, libraries no longer own this content (as they owned the print content the electronic versions supplant) but lease it. And even if a library has a “perpetual access” contract that lets it download publisher content after ending a subscription, for practical purposes many libraries are not ready to host it or make it available as readily and seamlessly as their patrons have grown to expect.

However, even if publisher repositories, or scholar-run discipline repositories like the social scientists’ SSRN, aren’t directly run by traditional libraries, those libraries are among their primary customers. Therefore, the folks who run those repositories have incentives to provide the kinds of services that those libraries need to carry our their missions (at least, if the libraries know to ask for them).

Increasingly, though, people are using new kinds of repositories that have little or no connection to traditional libraries. Some of these repositories are on their users’ own computers– their digital music collection and photo library, managed by programs like ITunes, IPhoto, and Picasa. Some of these repositories are on Internet sites like YouTube, Flickr, Google Docs and Google Base, and the various WikiMedia sites. We often don’t think of all of these as “repositories”, but that’s how people are using them: to manage and provide access to information in a stable way, potentially over a long period of time.

I’m not using “repository” here to mean just “glorified filesystem or website”. The everyday repositories I mention above typically put substantial effort into managing metadata, supporting discovery, providing for access control (and often backup and version control), and supporting long-term access and use of the content. They tend to do all these things much more quietly and unobtrusively than the repositories typically designed for and marketed to libraries, but that’s a feature, not a bug. We who work in research libraries need to consider these “repositories for everybody” very carefully. A lot of the digital content that libraries will want to include in our own collections will come out of those repositories. And those repositories can potentially teach us a lot about how to design and run our own.

That’s one big reason why I want to discuss my library’s strategic thinking about repositories in open forums like this one. True, the Penn Libraries don’t have exactly the same uses and needs for repositories as other people and groups. But I think there are a lot of repository issues where we and many others share common interests, or have common questions we all need to answer. Over a series of posts, I hope to discuss repository purposes, infrastructure, technologies, ingest, workflow, labor allocation, lifecycles, legal concerns, integration, policy, and community, all of which are relevant to our repository plans. The strategies and issues most salient for Penn may or may not be the same as yours. But if repositories matter to you, I hope that discussing our issues in a broader context will give you useful things to think about for your own situation. And I hope that we will learn from you as well.

Lots of other people have already written thoughtfully on repositories. I hope to stealreuse and build on their ideas wherever I can. A good introduction to many of the issues can be found at JISC’s Repository Support Project, a website to help institutions planning repositories, starting from “What is a repository, anyway?” and working from there. (It’s not a given, by the way, that libraries should always run their own repositories for their digital content– but more on that later.)

Repository planners should be familiar with both the theory and practice of repositories. You don’t have to know all the details of the OAIS reference model, for instance, but it’s helpful to know the general principles it sets out, both for issues to think about in running a repository over a long term, and for a conceptual vocabulary for understanding and interacting with other repository initiatives. Likewise it helps to at least be conversant with standard metadata schemas, protocols, recommended procedures, and the like. But you also very much need to know how repositories are working, or not working, in practice. The JISC site I mentioned earlier has an interesting case studies section, where folks who have run repositories describe their experiences, and how they may have differed from expectations. Some repository managers also run blogs where they talk about their day-to-day experiences with repositories, good and bad. Les Carr’s RepositoryMan and Dorothea Salo’s Caveat Lector are two blogs that I find must-reads, for keeping track of new developments repository maintainers can use and practical problems that repository planners can’t afford to ignore.

Future installments in this series will be posted under the “repositories” category. In the meantime, if you’re interested in these issues, I recommend you check out the resources above. And I’d be very interested in hearing about particular issues that should be discussed here.