The knowledge platform

Platforms are all the rage. In fact, they're so much the rage that they're probably now entering the post-rage phase of disappointment, to be followed by widespread ridicule. Nevertheless, no matter how trendy or not, platforms are a useful way to think about how to use knowledge to the advantage of your organization.

The term "platform" has become vague, as happens to terms that succeed. But there are some fairly consistent ideas packed into the word. A platform first of all focuses attention on the value of what runs on top of it. In that sense, it's infrastructure. But, a platform is infrastructure that does not have a particular use in mind. Rather, it is infrastructure for innovation. Further, it provides a layer by which data and services can interoperate. And that means that the value that gets built on top of the platform gets multiplied: Applications that use the platform have easy access to the same data that is powering other applications, can presumably integrate different types of data, and can feed back into the platform the data and services that it generates. Platforms thus accrete value. That is one sweet virtuous circle.

Tim O'Reilly has famously suggested that the government ought to be a platform: It provides the data resources and infrastructure that enable agencies and citizens to build services. I think the case is even clearer that businesses ought to be building platforms for knowledge. That's because knowledge is itself a sort of platform. It has no value by itself. It has tremendous value when put to use. Knowledge is a platform for decisions, for innovation and for community.

Libraries are platforms

Libraries here can serve as a useful example. The idea of libraries as platforms has been kicking around for a little while now, although it looks a bit different in each formulation. Here's how I would put it:

When we entered the Age of the Network, portals were much in favor, and it seemed to make sense for an institution as rich in resources as a library. Some of these portals were very well designed, but portals are not platforms. Portals focus on providing specified access to resources. Platforms don't assume the sorts of access users will want, and focus on the activities and relationships that such access can inspire and fuel. So, while a library platform will provide portal-like access—it'd be suicidal and, frankly, crazy for a library not to let people search for and access the materials—but a library platform will do much more:

First, it will provide access to a much broader range of data and metadata. In addition to the metadata for the items in its collection, a library platform will make available metadata about the various ways those items are used. That can give a sense of the work's relevance to the community.

Second, it will gather up information about what's created using the items in its collection. This includes not only posts that link to the items, but also any tagging and annotation that are made available by its users.

Third, it will enable developers to pull this information into their applications. Very likely this will be done through an API (application programming interface). It will also make this information available for batch download and possibly as a data cloud via the Linked Data format. (All of this is, of course, subject to copyright and privacy considerations.)

Fourth, it will provide tools, services and documentation to make it more enticing for developers to create new apps using this data. Obvious services include the ability to do queries across data types. For a library, that means returning books, DVDs and even Web links in response to a query for resources on some topic or by some author.

Fifth, it will enable and encourage the rise of a sense of community among developers. This could be as simple as creating a technical mailing list or maintaining a technical wiki. A repository for open source software at GitHub can also help.

Sixth, it will provide useful services for users, including portal access, of course. But exactly what services users need, and need from the library as opposed to from, say, Facebook or LibraryThing.com is not at all obvious and will vary from locality to locality. There's lots of room for experimentation and iteration here.

Seventh, it will endeavor to lower the bar to developing new apps so that even users without technical skills can participate. Some libraries are installing Maker labs where users can create physical and digital objects that use the library's resources, including the skillsets of librarians.

Eighth, it will encourage the reuse of any added value that emerges from this platform. For example, if an online book club is carrying on an exchange about a novel, that exchange should (with permission!) be available to anyone who wants to explore that novel. That way the platform continually gains new value.

The aim of all this is not to have a spiffy platform, but to enable users to connect with one another, to inhabit and make sense of the library's resources, and to gain yet more public value from that sense-making. The focus of the library shifts from the provisioning of resources to the discovery and amplification of the value of those resources.

The question is how much of this platform approach can be applied to corporate libraries and knowledge management systems. I'm guessing just about all of it.