The Summer of Japanese Puppets, Part 1

#sql   #jekyll   #php

This post is part 1 of 4 in a series. Feel free to skip around to:

part 2: data transformation,
part 3: the site, or
part 4: epilogue.

Enter: Bunraku

A few months ago, I was given access to a MySQL database with 27 tables of data on Bunraku, or Japanese puppet theater. The data consists primarily of digitized images from the Barbara Curtis Adachi Bunraku Collection here at Columbia University Libraries, but it also contains a ton of relational data on the Bunraku community as Barbara encountered it—which is to say, as a rich network of performers, plays, productions, puppets, craftsmen, narrators, musicians, authors, theaters, instruments, old friends, and even older tales. To be more specific, the data models the complex interrelations of…

… spanning decades of Barbara’s involvement with the leading Bunraku troupes in Japan. [Aside: Want to learn more about Barbara?]

Act 1: The Task

Both the MySQL database and the PHP site it powers have been slated for retirement this summer, so my task has been to create a modern, sustainable, and static replacement. This replacement needs to handle each of the ten main data object types and their associations—connecting authors to the plays they’d written, connecting those plays to their respective performances (via productions), connecting performers to those performances, and so on in a semi-hierarchical and sprawling fashion. It also needs to approximate the advanced search capabilities of the current site, add new navigational entry points and paths, and accommodate the sometimes enormous number of images associated with a given play or other type of object.

Sounds a bit tedious but simple enough. Yet the project necessitated tackling several difficult (or at least new) questions, namely:

  1. How can the data be modeled and converted into static, browser-friendly formats?

  2. How should the site relate to that data? (i.e. should all the pages be pre-built from the data, or should the browser do the relational heavy-lifting?)

  3. How will search be implemented without the use of a database (or any communication with the server)?

  4. How will the site deal with pages that include upwards of 1500 images?

  5. How can I create visualizations of the data, and recast them as functional navigational tools to the user?

  6. Is it possible to make the site lightweight-enough to run smoothly on less-than-stellar connections? …on mobile?

  7. Can I implement advanced English/Japanese search? With both roman and kanji characters?

Next >> part 2: data transformation