Remixing and forking books

Library practices of bibliographic description have so far taken for granted the stability of the book. In the future, we might have to deal with describing versioning, forking and remixing. The article ” Forking the book” argues that dynamic content will become possible. As an example, it highlights a tool that lets you edit EPUB with GIT as a backend. “[W]ith this demo we are using GIT with a book so you can clone, edit, fork and merge the book into infinite versions.” There is already a platform for remixing books, BookRiff, which has not yet gained wide acceptance but which is slated to enable the kind of forking the article talks about.

Data modeling has to be aware of developments in the creation of the objects it primarily describes and makes discoverable. Borrowing expressions from the print paradigm, the forked book is comparable to a kind of “bound with”, multi-work constellation, but more complicated since only parts of works might be used, different versions might be created and licensing information would have to be noted. I guess Bibframe will be able to accommodate these versions and remixes, but that would mean that the statement in the November Bibframe report, “Each BIBFRAME Instance is an instance of one and only one BIBFRAME Work”, will not hold, because, as I see it, the instance (the remixed/forked book) would be in a relationship with two or more works.

BIBFRAME datastore

The current issue of the Code4Lib journal contains an article by Jeremy Nelson of Colorado College, “Building a Library App Portfolio with Redis and Django”, that highlights the development of FRBR datastores that run on a NoSQL database server (Redis). More interestingly, perhaps, this platform is based on the BIBFRAME model with four core classes: creative work, instance, annotation and authority (for further details, see the project site on GitHub). To me, such a two-level mapping makes a lot of sense. In fact, I quite like the reduction of the FRBR complexity in the BIBFRAME model, especially with the anticipated re-use by other communities in mind. Jeremy Nelson explains on the BIBFRAME mailing list:

Because of Redis’s flexibility, I’ve been able to use RDA element names as either discrete properties for each BIBFRAME entity or as part of the naming scheme for the BIBFRAME entity’s associated keys.  A nice feature of this approach is that we are not restricted to just RDA but we can use other metadata standards (MODS, DC, ONIX, VRACore, etc.) as discrete properties or as part of the Redis key naming schema for the BIBFRAME entities. We are also using a simplistic mapping of FRBR Work and Expressions to BIBFRAME Creative Work, along with FRBR Manifestation and Item to the BIBFRAME Instance…

HathiTrust Research Center video

The HathiTrust Research Center (HTRC) “is a collaborative research center launched jointly by Indiana University and the University of Illinois, along with the HathiTrust Digital Library, to help meet the technical challenges of dealing with massive amounts of digital text that researchers face by developing cutting-edge software tools and cyberinfrastructure to enable advanced computational access to the growing digital record of human knowledge.”

Here’s a video that details HTRC’s mission of supporting scholars (e.g. in the digital humanities) in their research:

I would be particularly interested in learning more about a project mentioned 2.45 minutes into the video that involves “automatically enhancing the metadata that describes the volumes”, ultimately resulting in higher quality metadata – maybe we’ll hear more about it in the future.

via CDLINFO News