Liquid Books
In the LiquidPub project we have explored and proposed the concept of Liquid Books (LB) as collaborative, evolutionary, possibly open-source and multifaceted versions of the traditional books (either printed or digital). Liquid Books are a new way of thinking about books in the Internet era. In Liquid Books, authors share material (and so, collaborate, as authors in an ordinary book or in a wikibook) but each author is then free (within the boundaries of a contractual agreement that we have identified) to take any of the shared material and edit/organize in any way they want, and to then have an own edition of book that leverages the knowledge of the group but that does not require everybody to share the same view on the content or organization of the edition. Liquid books include multifaceted content, which stay up to date with the current state of art (as they continuously evolve over time) while reducing the typical time to market interval. The key issues we have found in our research are not IT-related but rather related to the setting up of a suitable contract, licensing, credit attribution, royalties and dissemination model.
In a nutshell, a liquid book is characterized by the following entities (in italics):
- content added by contributors
- A content is published to the public via editions, prepared by editors (editors are a subset of contributors).
- a contract defines who can add or consume content, who can create editions, what is the frequency of editions. A contract defines also the licensing/visibility policies for content among contributors.
- A contract also includes the specifications of a number of processes, e.g. for modifying the pool of authors (including new authors or removing previous ones), defining credit attribution mechanisms etc.
- a publisher publishes and distributes the editions of the book, typically holds the copyright, and possibly provides additional services, including IT services supporting LBs.
A traditional book is one instance of the model above. In a traditional book (think of authored books, not of edited books for now) we typically have one or a very small number of editions, typically not in parallel. All contributors (the authors) are listed as authors of the book, and get royalties based on a pre-agreed contract. Variants of the book are typically subject to new contracts. In particular, an author cannot just take the content and publish its own variant without contractual agreements with the other authors and with the publisher. Also, in a typical publishing process, there are rigorous quality checks. The “time to market” is overall quite high, both because it takes a long time for authors to prepare the manuscript and because of the publishing process after the initial manuscript has been delivered, that also takes several months. Overall this resembles very much a waterfall software development process, with all its benefits and limitations.
The opposite extreme of a liquid book resembles more agile and open source software development, with some twists due to the nature of book publishing and copyright management. So, at the "liquid extreme" we can have a Liquid Book where contributors add content, possibly in a continuous fashion, and where contributors can freely decide at any point to prepare new editions by collecting and editing content put by other contributors to the same LB. With such flexibility, each edition could be easily tailored for a set of specific readers. At the proper phase, the associated processes (as defined in the contract) starts. These processes can range from very simple rules (e.g., editors always take 20% of the royalties and the rest is shared equally with all contributors) to more complex procedures (for example, a voting mechanisms that approves royalty distributions proposed by the editor). The key here is to have these processes simple and well defined, at the beginning, otherwise the complexity is excessive and very likely this will not scale.
The main goal behind the LB concept is to enable authors to easily share and reuse their content, giving them at the same time the guarantee that their content will be used appropriately and so producing versions of the book tailored for the needs of the prospective readers (students, consultants, etc.) LB can be open source, partially open, up to the case of traditional closed book. In our model we aim at covering all the possibilities, leaving to authors the final choice of how to distribute their content.
Documents
"Liquid Book: reuse and sharing of multi-facet content for evolving books" Fabio Casati, Azzurra Ragone
"Liquid Book Demostrator" Maurizio Marchese, Fabio Casati, Christian Daniel Parra Trepowski, Ralf Gerstner
Presentations
In this presentation we explain the Liquid Book vision, what is new and what is different with respect to traditional books or WikiBooks. We show some challenges that arise while trying to make the Liquid Books idea real. Motivations and challenges are illustrated through stories describing possible scenarios in the Liquid Book era.
Related Work
- WikiBooks
- 'How to Think Like a Computer Scientist' series of publications by Green Tea Press, where the same core programming text has been adapted to several different programming languages
- 97 Things Every Programmer Should Know example of collaborative written book, with hundreds of contributors
- Fast pencil platform to write, publish and sell collaborative written books
- Business Model Generation example of collaborative written book, with 470 co-authors and without a publisher
- Papers by Richard Stallman where he sets out a distinction between 'functional works' like recipes, computer programs, manuals and textbooks, where there is a clear case for allowing freedom to re-use and modify; 'opinion'-type works or testimony along the lines of, 'I think this' or 'We did this' (e.g. scientific reports) where to modify them is to misrepresent the authors; and other works, such as aesthetic or entertaining works.
