This blog is dedicated to Karl Steel; I cannot think of a better person with whom I would want to build and collaborate and co-create.
Last blog I got carried away with the argument that
we must build to know.
And it’s true. Whether it’s building an experimental set-up that allows us to collect measurements of some kind, whether it’s a form of art that allows us to see some aspect of ourselves or our world that we couldn’t quite see before, or whether it’s simply a palate of post-structuralist theories that allow us to analyze a literary text,
we all use an apparatus to produce knowledge, to take a “measurement” of the universe, in whatever way seems interesting or useful to us.
The thing I love about working across a few disciplinary boundaries, and using computational tools is that it allows me to invent the apparatus I want to ask the questions I want to ask–which usually tend to be questions I feel vehemently that everyone should have been asking all along, and yet I find to my chagrin that they haven’t been. I mean really, how could we not have been talking about what Piers circulates with in the manuscripts? How is that not it’s most immediate textual context? Doesn’t it seem obvious? Well, I guess it isn’t.
But it seems really important that as we (literary scholars? medievalists? the otherwise not technically inclined?) take on the new tools that computational methods make available to us, that we recognize that not only is the old model for asking and answering questions passing away before our eyes, but the very model of what scholarship is is changing before our eyes.
It is no longer possible–at least not if you want to do this kind of interdisciplinary, intermedia kind of work–to model ourselves off the monastic trope of scholarship: the lone monk, toiling away in his tower, using nothing more than the mere power of his own brain to produce new knowledge (or at least, from a medieval standpoint, to bring a succinct and authoritative new arrangement of rēs into existence).
Instead we must rely on each other. the amount of expertise is too great for us to gain enough of it to be an “authority” on our subject and a wielder of *all* the possible ways we can start to interact with our subject–literarily, theoretically, historically, art historically, scientifically (lasers!), or digitally. But that’s ok. That’s why we work together. That’s why we collaborate. We bring our ideas and our skills into contact and we actually bring (a) new (arrangement of ) knowledge into the world! How exciting!
I’ll give you an example, this week’s visualization (which I’ve been holding onto for a while just waiting until I could write this blog to go with it). This is something I learned how to do while working with Sebastian Heath, the Institute for the Study of the Ancient World’s very own digital Indiana Jones. He brought in an example of what one could do with data that is encoded (often in JSON) by working with some templates at bl.ocks.org.
This was a graph that tracked data for a single item (in this case, models of cars from the 70’s and 80’s) across multiple axes of data. Perhaps you want to know about how cars performed across fuel economy, engine size, vehicle weight, and time. You could use this infographic to display all of this information at once.
When Sebastian brought this example into class, I looked at it and immediately saw how it might apply to the data I care about:
maybe I want to be able to see information on multiple kinds of data about my manuscripts at once.
Well, bl.ocks.org is a viewer for code that you can host on github. The viewer itself is a code, likely created by the site’s administrator, Mike Bostock a graphics editor at the NYT who works primarily on data visualization.
On mbostock’s repository of bl.ocks, we see where he (and others) have developed code for different varieties of interactive graphics:
Each of these blocks consists of two (main) components:
1. the html structure of the visualization itself
2. the data that is being visualized by all this code:
Now, bl.ocks.org doesn’t actually store any of this information. Instead, this data is stored online at GitHub in gists (don’t ask me how you pronounce that one, I don’t know). The gist has three different documents, the first is the README that contains the text that gets displayed under the visualization; the second and third are the data and html mentioned above.
You can reach this gist by clicking on the link at the bottom of the bl.ock page:
You simply click the “fork” button and all that information is copied into a gist on your own GitHub account. Then, you are free to go in and change just the data, or fiddle with the html to get exactly what you want.
Simple as pie. So, let’s go to parallel coordinates of Piers Plowman MSS:
On this visualization, we can see each manuscript represented by a line that traces the data for that manuscript through all its axes. The axes are the date range of MS production, how many works are in the MS, where Piers is in relation to the other works, how long the Piers is in a given MS, how much of the MS the poem takes up, the version of the poem (represented numerically, with key in the text below), and just for fun, how far from Malvern the MS seems to have hailed from (this is tricky, as I’ve mentioned elsewhere, because it’s based on dialect).
But here’s what I love about using bl.ocks: they’re interactive!!!
Yes, you’ve seen one or two before, but it never gets old! So, let’s say you want to know about manuscripts made around the turn of the fifteenth century where Piers occupies the majority of the MS (let’s say 75% or more). Here’s what you can do:
Well, I can highlight the appropriate date ranges for the terminus ante quem and terminus post quem that limit my data to only those MSS. Then I notice that actually, while there are a preponderance of Piers MSS that are 75% or more Piers, there are certainly MSS for which that is not the case. So, I add another slider (just by clicking and dragging on the axis) to see what we get.
What we can see here is that most of the MSS that fulfill this criteria are C MSS (No. 5), and a handful of B MSS (No. 3). But there are two hybrids, one BC (No. 4) and one AC (No. 6). If we want to know which MSS those are, we simply rollover the MS line and it highlights the line allowing us to track the data for a single MS across all the axes:
While before it was just a really cool way to see patterns across multiple axes, now it becomes an actual reference. By being able to disambiguate your data (that is attach the visualization you’re seeing to an actual object we want data about), suddenly this goes from being a fun informational toy for those Piers Plowman manuscript enthusiasts out there (so like, me, Lawrence Warner, Ralph Hanna and Simon Horobin, I guess….) to being something that one could use to find information and conduct further study.
So, I built this cool informational graphic–sort of. I mean, I didn’t build it myself. I don’t even know my “collaborator.” Am I really just an appropriator? Well, I would argue not, since Bostock has put this visualizations online to be appropriated and used by other people for their own data. That’s all a part of the collaborative environment of doing digital research, which I’ve written about before.
I like to think of using the digital infrastructure that others have built the same way that we might think about using literal infrastructure. If you build a business, you don’t have to have built the actual office building in which it is housed, or the roads it uses for transport, or the cars, trucks, planes or trains that carry things along. But you use them nevertheless, and the business remains yours.
Likewise, it’s ok if “you didn’t build that,” in digital infrastructure either. The key is, are you allowed to use it, do you give credit to those who did build it, do you know what it is and how it works, and does it give us an apparatus to know something about our object that we didn’t know before?
Don’t let an inability to build from scratch to keep you from building at all!