The Hourglass of a National E-Book Program

This weekend I was at the second "DPLAfest" for the Digital Public Library of America. For a while I was in the national e-book program track. Participants from public and academic libraries, from consortia, from publishers, and from authors discussed what a national ebok program for libraries would look like. There were discussions of the multiple paths through which content could get into libraries: front-list titles, mid- and back-list titles, public domain works, independent publishers, and individual authors. And there was also discussion about many ways the ebooks could appear in libraries: in Adobe Digital Edition catalogs, through e-reader applications, in public access catalogs, and so forth. In between the sources and the destinations was the "marketplace" concept. And that reminded me of a similar architecture -- the internet "hourglass".

The Internet's "Hourglass" Architecture
As an open data network, the Internet can operate over different underlying technologies, including those yet to be introduced, and it can support multiple and evolving applications and services. In this layered architecture, bits are bits and the network does not favor by its design or effectiveness any particular class of application. Evidence of this openness lies in the fact that the Internet's essential design predated a number of communication technologies...and applications and services...in use today -- and that within the Internet all of these technologies and services, both new and old, can coexist and evolve. The shape of an hourglass inspired its selection as a metaphor for the architecture -- the minimal required elements appear at the narrowest point, and an ever-increasing set of choices fill the wider top and bottom, underscoring how little the Internet demands of its service providers and users.

- The Internet's Coming of Age, National Academies Press, 2001, page 36. (emphasis added)

In 2008, in the book The Future of the Internet--And How to Stop It Jonathan Zittrain put the analogy into a diagram and expanded on the description:

[caption id="attachment_25413" align="alignright" width="300"] "Hourglass architecture of the Internet" from Jonathan Zittrain's book 'The Future of the Internet--And How to Stop It'[/caption]

The hourglass portrays two important design insights. First is the notion that the network can be carved into conceptual layers.... On one basic view of the network can be understood as having three layers. At the bottom is the "physical layer," the actual wires or airwaves over which data will flow. At the top is the "application layer," representing the tasks people might want to perform on the network.... In the middle is the "protocol layer," which establishes consistent ways for data to flow so that the sender, the receiver, and anyone necessary in the middle can know the basics of who the data is from and where it is going.

By dividing the network into layers and envisioning some boundaries among them, the path is clear to a division of labor among people working to improve the overall network. Tinkerers can work on one layer without having to understand much about the others, and there need not be any coordination or relationship between those working at one layer and those at another....

The second design insight of the hourglass is represented by its shape. The framers of the Internet Protocol did not undertake to predict what would fill the upper and lower layers of the hourglass. As a technical matter, anyone could become part of the network by bringing a data-carrying wire or radio wave to the party. One needed only to find someone already on the network willing to share access, and to obtain a unique IP address, an artifact not intended to be hoarded. Thus, wireless Internet access points could be developed by outsiders without any changes required to Internet Protocol: the Protocol embodied so few assumptions about the nature of the medium used that going wireless did not violate any of them. The large variety of ways of physically connecting is represented by the broad base of the hourglass. Similarly, the framers of the Internet Protocol made few assumptions about the ultimate uses of the network. They merely provided a scheme for packaging and moving data, whatever its purpose. This scheme allowed a proliferation of applications from any interested and talented source -- from the Web to e-mail to instant messenger to file transfer to video streaming. Thus the top of the hourglass is also broad. It is only the middle that is narrow, containing the Internet Protocol, because it is meant to be as feature-free as possible. It simply describes how to move data and its basic parameters have evolved slowly over the years. Innovation and problem-solving are pushed up or down, and to others.

- The Future of the Internet--And How to Stop It, by Jonathan Zittrain, 2008, page 67-68.

Applying the Hourglass Analogy to the Library Ebook Ecosystem

This hourglass analogy is useful when thinking about how we want the ebook ecosystem in general to look and what we want the marketplace in the narrow middle to do. We want the marketplace to make no assumptions about where the content is coming from -- it can be from the big five trade book publishers, from professional publishers and university presses, from independent publishers, public domain book distributors, or self-publishers and library imprints. We also don't want the marketplace to artificially constrict what can libraries receiving the ebooks do with them. ((I think one useful constraint to put on the marketplace is to say that it is only concerned with libraries as recipients of the ebooks for eventual delivery to their patrons. To expand the scope of the marketplace to envision supplier-to-end-reader or supplier-to-ebook-reseller relationships would probably require assumptions that would expand the narrow middle of the hourglass and complicate our task.)) (That is to say that suppliers and libraries can agree upon restrictions in a marketplace transaction, but that the marketplace itself would work equally as well in the absence of restrictions, such as the case of public domain works.)

It might be useful to reframe the words from the National Academies and from Jonathan Zittrain into our context:

• As an open ebook ecosystem, the ebook marketplace can operate over different underlying technologies, including those yet to be introduced, and it can support multiple and evolving applications and services. In this layered architecture, books are books and the marketplace does not favor by its design or effectiveness any particular class of application.
• On one basic view of the ebook ecosystem can be understood as having three layers. At the bottom is the "supplier layer," the actual paths from which ebooks will flow. At the top is the "library application layer," representing the tasks people might want to perform on the ebooks.... In the middle is the "marketplace layer," which establishes consistent ways for ebook to flow so that the supplier, the library, and anyone necessary in the middle can know the basics of who the ebook is from and where it is going.
• The framers of the ebook ecosystem did not undertake to predict what would fill the upper and lower layers of the hourglass. As a technical matter, anyone could become part of the marketplace by bringing a feed of ebooks to the party.
• The large variety of ways of supplying ebooks is represented by the broad base of the hourglass. Similarly, the framers of the ebook ecosystem made few assumptions about the ultimate uses of the marketplace. They merely provided a scheme for packaging and moving data, whatever its purpose. This scheme allowed a proliferation of applications from any interested and talented source -- from the ebook apps to assistive devices to catalog records to long-term preservation to textual analysis and indexing. Thus the top of the hourglass is also broad.

The last few sentences of the quote pulled from the Zittrain book are the most instructive for the next steps of the marketplace development:

It is only the middle [of the hourglass] that is narrow, containing the marketplace, because it is meant to be as feature-free as possible. It simply describes how to move ebooks and its basic parameters have evolved slowly over the years. Innovation and problem-solving are pushed up or down, and to others.

What is in the Ebook Marketplace?

If we apply this hourglass analogy to the library ebook ecosystem we aim to build, what is in the narrow middle? Here is my starting list:

• Negotiate model licenses for various forms of content from various suppliers to varieties of libraries.
• Provide a directory of suppliers that adhere to marketplace principles that libraries can use to acquire content.
• Advertise the formation of buying groups for purchasing/licensing content from suppliers. (Others would be the agents for negotiation with suppliers, collecting/dispersing funds, etc.)
• Register identifiers for the parties involved in the marketplace.
• Promulgate standards for transaction metadata, definition of terms, analytics, etc.

The marketplace would also facilitate the advertising of service providers at layers on either side of the marketplace. These are optional -- a supplier or library could do these on their own, or they may call upon one or more service provider.

• Statistics gathering (ebook purchases and use) and analytics, for both suppliers and libraries.
• Auditing (ensuring libraries have access to what they have purchased and that terms of agreements with suppliers are being honored)
• Dark archive preservation of content purchased with perpetual rights.
• Transformation services (EPUB to Kindle, ONIX to MARC, metadata enrichment)
• Distribution services (sites that host Adobe Digital Editions for delivery to patrons, setup of library-specific reading apps, display to HTML)
• Computational services (textual analysis, customized indexing, union catalog building)

By putting these activities outside the narrow middle of the marketplace, we can see competition and evolution in these services and technologies without changing the core of what the marketplace is doing. Some examples of the marketplace in action:

1. Public domain book provider GITenberg can be match up to a public library through an advertisement on the marketplace of a public domain model license. The library might make use of a transformation service to convert the GITenberg-supplied RDF to MARC, and distribute it through a library-branded ebook reading app offered by a supplier.
2. University press publisher Alpha offers a catalog of ebooks with a marketplace model license that offers the library perpetual rights with the option to put the content in a dark archive. Alpha Publisher also insists in the model license that it receives statistics on the maximum simultaneous use, and specifies the end-point of its internal statistics gathering operation to receive circulation reports. The library specifies the StorageForever dark archive to receive the preservation copy, and the contents of the archive are audited by EbookAuditors service providers.
3. Independent author Jane Smith uses catalog provider BooksForAll to make her book available. Ms Smith specifies a model license that insists on circulation counts and designates the CircStatisticsCounter agent to receive circulation reports from the library. In the transaction, the library specifies that it will use its own dark archive service and neither party specifies the need for an auditor of usage or dark archive services.

Does this make sense as a starting point for the activities of the marketplace? Is there too much there now? (Should the directory listing and advertising activities be outside the marketplace?) Are there things that are missing as core marketplace activities? Are there other things that service providers could do on either end of the marketplace.