The future of libraries won’t be created by libraries. That’s a good thing. That future is too big and too integral to the infrastructure of knowledge for any one group to invent it. Still, that doesn’t mean that libraries can wait passively for this new future. Rather, we must create the conditions by which libraries will be pulled out of themselves and into everything else.
The future used to be simple enough that simple coping strategies sufficed. For example, we might foresee that in the future we would make good use of a stool, so we built one in the present. In the Information Age, we built massive accounting systems and missile controls, but the strategy remained constant: project a need, create a tool, use that tool until it breaks or is no longer needed.
That strategy still works well, of course. It’s why we continue to build stools and accounting systems and it’s why libraries build portals. Portals address the known needs of users, which is no small thing.
Yet that’s no longer enough. Portals can even inadvertently contribute to the perception that libraries are becoming obsolete: the content of most of the physical books in the library are not available through the portal, and the nonlibrary sites that give access to books often are more usable and, well, cooler.
Far more worrisome is that libraries are barely visible on the web. Yes, many of the portals have useful interactive services. But if someone wants to link to a book, or explore a book, or learn more about a book, that person is probably going to go first to Amazon, Wikipedia, Google Books, or just plain Google. These sites are playing the role within the web knowledge ecosystem that libraries would play better because libraries have hundreds of years of experience and expertise and because libraries’ interests are near perfectly aligned with their users’ interests.
The library tragedy
That’s why it’s a tragedy that libraries are barely visible in the new knowledge infrastructure. What libraries and librarians know about books and so much more is too important a cultural resource to lose.
That’s also why we need libraries to be out where ideas and knowledge are being raised, discussed, contested, and absorbed. Everywhere there’s a discussion on the web, everything that libraries know ought to be immediately at hand. Yet this hope for libraries is unlikely to be realized primarily by libraries, for two reasons.
First, if we want what libraries know to be infused everywhere, then we’re going to have to go everywhere. Sadly, libraries can’t unilaterally make that happen. It requires people at all those other places to see the possibilities and do the work: pull is far more effective than push. We want Wikipedia to know—or at least have available—what the world’s great libraries know. We want Google Books to be that smart. We want Amazon to be that expert. We want books to be as easy to find and reference as a Wikipedia page, a Google map, or an IMDB cast list. We want everyone to know how to link to all the different types of items in libraries so that all those references and conversations can be found, learned from, and elaborated on going forward.
Most of all, we want a 14-year-old—the next Aaron Swartz (1986–2013), if we should ever again be so blessed—to be able to build an app for libraries that we did not imagine. We want the entire world to build the future that no one group, no matter how expert, could anticipate.
Our job, then, is not to invent the future of libraries, it is to enable others to do so.
Making access easy
The best way to enable the world’s innovators to inculcate library knowledge in every niche of the ecosystem is to provide them with access to everything that libraries know (short of violating privacy rules or norms, of course). To do so, we must make it easy for developers to write applications that put library knowledge to use and easy for sites to integrate library knowledge into their own offerings.
In short, we need to make libraries interoperable with the web. There are at least three ways of heading in this direction.
- APIs First, we can build platforms that make library knowledge openly available to computer applications that want to do something interesting with it. Typically this means building application programming interfaces (APIs) that let external programs access that data as if it was local. The Digital Public Library of America has made all of its metadata available this way, and the Library Innovation Lab that I codirected (with Kim Dulin) until recently is doing the same for at least a good chunk of Harvard Library’s metadata. We are far from the only ones.
Platforms break the old stool-building paradigm for coping with the future. Rather than the owners of the data being the only ones deciding what services to build, a platform lets anyone with enough coding skill do so. This opens up the floodgates of innovation and enables people to customize existing services to their own needs. For example, if the recommendation engine their library is providing doesn’t work so well for their personal or scholarly needs, they can create their own. As more tools are developed, more people—from kids to content experts—can create their own apps and services. This lets us get more value from what libraries know.
APIs also provide a stable way for other sites to integrate library information into their own services. Now what libraries know can begin to show up in everything from a learning management system and an online encyclopedia to a travel site that wants to recommend books by local authors.
Also, one of the great promises of library platforms is that they can learn from how their information is used. At one time, library users developed their ideas in private. Now the ferment of knowledge development is online. Libraries can be in the mix throughout the process and can feed the products of those processes back into the platform (when the participants agree, of course). For example, simply seeing which titles users think should go together can be tremendously useful metadata. - Linked Data Second, Linked Data can help us open up the future of libraries. By making clouds of linked data available, people can pull together data from across domains, a task that in the Age of Information would have required extensive engineering of schemas, etc. (Schemas are one of the great examples of inadvertently limiting the future by having to anticipate it.) Adding library data to the mix makes it easier—though not yet easy—for that data to be absorbed throughout the web. For example, the Linked Data for Libraries project, funded by the Andrew W. Mellon Foundation, is building a set of linked data repositories with a wide range of library information across three universities: Cornell, Stanford, and Harvard.
- The Library Graph Third, there’s an ambitious project libraries could choose to undertake as a group that would jump-start the web presence of what libraries know: a library graph. A graph, such as Facebook’s Social Graph and Google’s Knowledge Graph, associates entities (“nodes”) with other entities; the relationships are called “edges”: two things that touch share an edge. In Google’s Knowledge Graph, Igor Stravinsky shares an edge with “The Ebony Concerto” as its composer, and Benny Goodman and Woody Herman share edges with the concerto as its performers. Thus, the Google Knowledge Graph can begin to suspect that Stravinsky, Goodman, and Herman might share some musical tastes and influences. That’s the benefit of a graph: it can be queried (presumably through an API) for what it knows and then can deliver rich and unexpected connections.
Imagine what we could do by collaboratively giving the web a library graph. What a resource that would be, for everyone from a child looking for the next Dr. Seuss–like book to a researcher exploring Virginia Woolf’s social circle. This would be, of course, a big project. But it has the advantage of being useful from the very beginning and only becoming more useful as more relationships are fed into it—including through library platforms.
Whether a library graph is a bad idea in any of the ways ideas can be bad, its aim is overall correct: to make what libraries know available at every junction of the Internet and to do so in ways that continually enrich what libraries know. Platforms, linked data, and a library graph all move libraries in the direction of becoming an essential part of the new networked infrastructure of knowledge and ideas, not by insisting on being a center of the universe but by becoming a part of its fabric.
For this, libraries do not have to invent their own future. But we do have to create an environment in which the rest of the world can make everything out of libraries that can be imagined.
That thought makes me hopeful.
Now in its fifth year, The Digital Shift: Libraries @ the Center virtual conference will focus the attention of library professionals on libraries’ central role in the transformation of our culture from analog experiences to digital ones. Free registration for this October 1 event is available at www.thedigitalshift.com/tds/libraries-at-the-center
Good article! Thank you for again pointing that libraries has to turn “inside-out” (Lorcan Dempsey) to become a useful resource of / part of the web. I only wonder if way 2 (“Linked Data”) is essentially a necessary (or at least very good) precondition to way 3 (“The Library Graph”).
To be more clear, a “library graph” sounds like a great concept. But from my point of view, it’s exactly the concept of linked data opens the possibility to include informations from various sources into that graph – especially informations that are already there, e.g. objects from Wikipedia and Wikisource, metadata about places (e.g. where are libraries located, where do authors come from?) from Geonames etc.
I think if I were a librarian reading this, I might feel a little depressed that so much of it is focused on putting APIs and algorithms in place that largely leave out the genius/genie of libraries: librarians. The other genius of libraries was simply serendipity: the chance encounter with an unexpected book simply by having your fingers stumble while flipping through the car catalog or making a wrong turn while in the stacks. Can the catalog and the stacks be imagined as really large networks? Sure. Unfortunately, we largely don’t navigate virtual networks in the same way we navigate physical structures.
As a humanities scholar, I liked much of what I read here, but I would like to note that we continue to face a rather large data hole when it comes to scholarship: what the APIs described above make available is meta-data. And much of the linked data is, from what I can tell, something more like what one pulls from the Twitter fire hose or perhaps it will done day be the stuff of NSF and NIH grants. But what humanists need, and here’s where libraries could really intervene effectively, is access to the data of the books themselves. When libraries figure out how they can hold those materials in trust for authors and publishers in such a way that the texts are available for computational analysis by scholars … why, that would be an amazing thing.
Lambert, thanks. And, yes, a LibraryGraph of the sort I’m suggesting would be an elaboration of the Linked Data from libraries that’s already becoming available. As I understand it, it becomes a graph as the data is intentionally linked in richer ways, and linked with other sources, so that we end up with a service that can be queried in rich and unexpected ways.
John, thank you for the rich and complex comment. You’re right that the ideas I’m addressing here do not put librarians directly on the Web as a resource. Librarians are an irreplaceable “resource”, but they don’t scale, at least not directly. But I’m not suggesting that any of these three projects should or could replace libraries or librarians.
I’ve assumed the presence of librarians (and we know what they say about assumptions) in the projects I’m discussing. They are present in the way their work enables meaningful digital exposure of library metadata, in their direct participation in thinking through these projects, and by making their direct contributions (e.g., lib guides) globally accessible.
The Linked Data I’m referring to is not the Twitter-ish firehouse. It starts with the data and metadata libraries have carefully and lovingly assembled. It includes other sorts of data if the librarians who are overseeing any of these three projects think that data will make the platform more useful. I suppose that might include some Twitter feeds, but more likely it will be catalog data, some anonymized usage data, pointers into authority files, links out to sites users might find useful, user reviews and ratings, etc. — just the sort of data some libraries are currently opening up as Linked Data.
And I completely agree that for the great blossoming of culture to happen, we need to get the actual material onto the Web, in as accessible a form as possible. Libraries have a hugely important role to play in this, IMO. Who else is going to do it, and do it in a way that puts the public’s interest first?