Week 07: Materiality + Modeling

Tunga brings in this passage from Flanders and Jannidis, and poses a question about process and conscientiousness that I think is worth repeating in full for those who haven't seen it yet:

So one could say that a model is a representation of something by someone for some purpose at a specific point in time. It is a representation that concentrates on some aspects—features and their relations—and disregards others. The selection of these aspects is not random but functional: it serves a specific function for an individual or a group. And a model is usually only useful and only makes sense in the context of these functions and for the time that they are needed. (Flanders and Jannidis 46)

This paragraph made me pause at how explicitly contingent modeling is: it’s not a neutral capture of “what is,” but a time-bound choice about what matters. That contingency feels less like a flaw and more like the point that models are instruments for reasoning, not mirrors which reframes how we should present and critique them. For someone trained in literary analysis, here is what I see: every critical argument is also a model, imposing boundaries that enable certain insights and foreclose others. I find myself wondering: If a model is always chosen “by someone for some purpose at a specific point in time,” what concrete steps should modelers take to document those purposes and assumptions so future users can treat the model as an interpretive artifact representing the interpreter's thought process rather than a neutral fact? (emphasis added)

Thoughts welcome! I (Ben) would posit three words will be important: documentation; about; and README. (I'd love to call in Yixuan to show the GitHub README for her project, which is a great starting point.)

Responding to Cairo's remark that "When you devise a mdoel, it's never possible to know exactly where it lies in the continuum," John asks a big question: "What can we do as researchers to move our model toward the 'Absolutely True' end of the spectrum?" There have to be many answers, of course, not just one – but one, I think, is suggested by Scylla in response to another passage from the same text:

Something that sticks out to me is towards the middle of the reading, where Cairo discusses emailing back and forth with Anatoly Bondarenko, discussing Ukrainian politics and protests that were being covered in the media, and mapped out in various data visualizations:

I immediately shot an e-mail to Anatoly asking, “Do you remember the map that you showed me when I was in Kiev? It explains everything that is going on right now in your country! It’s so prescient! Ukraine is clearly two completely different countries!”

A few hours later, Anatoly replied. His suggestion, which I am not reproducing verbatim, became a motto that I share with my students every semester: “It’s more complicated than that.” I usually add: “And if it’s really more complicated than that, then that complexity, which is crucial for understanding the story, needs to be shown in the visualization.” Good visualizations shouldn’t over-simplify information. They need to clarify it. In many cases, clarifying a subject requires increasing the amount of information, not reducing it.

There's an interesting tension between simplification and clarification in the way that data is visualized and represented that this passage flags that gives me pause. The idea of increasing information to clarify screams, "Add context!!! Prevent context collapse!!!" to me, but I was curious what other folks thought of, involving this quote.

Ensmenger's "The Cloud is a Factory" is not computational: it's not underwritten by a relational database or engaged in replicable visualization techniques. But nevertheless, I would argue it's very much a digital humanities project. How do you understand the work he's doing here?

If it's helpful, here's a sample passage:

All of this is to establish that it is impossible to understand the emergence of the modern information society without reference to the larger history of industrialization. Why is this significant? Because industrialization is fundamentally as much a social and political project as it is technological or economic. The ostensible driving force behind industrialization is the pursuit of efficiency, but the actual history of how, when, and why certain economic sectors chose to industrialize suggests otherwise. New techniques and technologies do not emerge out of nothing to revolutionize work practices; they are designed explicitly to do so. Machines are designed by humans to accomplish human agendas, and as such it is essential to always ask why industrialization is happening, to what ends, and for what purposes. (43)

Rose draws our attention to some of the takeaways at the end of Ensmenger's "The Cloud is a Factory" and brings them into a particularly local context: Pittsburgh's historical access to the things that attract factories, including digital ones. Starting in the middle of her quoted passage:

When Amazon recently encouraged cities to bid for the privilege of hosting their “second headquarters,” they were clearly pushing for those cities with well-established physical and social infrastructures: housing, highways, schools, restaurants, and recreational facilities. When Microsoft or Facebook looks to locate a new data center, they require easy access to inexpensive electricity, a plentiful water supply, and an appropriately skilled labor force. It is any surprise that these data centers are often located in the same places that housed industrial-era factories just a generation ago?" (Ensmenger 43–44)

This made me wonder about Pittsburgh as a location for the Cloud Factories, as one of these places that used to house industrial-era factories. I remember Alison mentioning the construction of new data centers in Pennsylvania, which led me to find this interactive map (an interesting data visualization in its own right) that shows their locations across the state.

I wanted to adjust Ensmenger's question: with this sense of geographical closeness, how can we more accurately depict the Cloud as a factory in our digital work at the University of Pittsburgh, and not as a disembodied computational device?