Feb 5, 2013
Building and (Not) Using Tools in Digital Humanities
As I mentioned in my last post, the ”Short Guide to Digital Humanities” (pages 121-136 of Digital_Humanities, by Anne Burdick, Johanna Drucker, Peter Lunenfeld, Todd Presner, and Jeffrey Schnapp, MIT Press, 2012) includes the following stricture under the heading “What Isn’t the Digital Humanities?”:
The mere use of digital tools for the purpose of humanistic research and communication does not qualify as Digital Humanities.
I’m not going to speculate on the reasons that these authors make this declaration, or on why they feel they (or anyone else) should be authorized to decide what kinds of activities do and do not “qualify” as parts of the field.
Here I want only to reflect on the potential damage done to the field by adhering to this restriction.
First, I think it raises questions about the credibility of the field. Among the strongest justifications for the existence of DH is its formal resemblance to established sub-disciplines in which computers are used to address academics subjects whose existence predates the age of computerization. The field of this sort to which I am closest and about which I know the most is computational linguistics, really a name for a group of diverse sub-disciplines ranging from machine translation to natural language processing to corpus linguistics. While there are some exceptions among some of the subfields, it is almost entirely the case that these fields do not distinguish between “building” tools and “using” tools when it comes to the evaluation or promulgation of scholarship. On the contrary, what is valued in all these fields is interesting results, results that can be widely used and shared among the community of computational linguists, especially results that expand our understanding of human language. There are a dozen or two world-famous computational linguists, all of whom use tools in any number of ways in their research. I know of no particular attention or approbation paid to them because they did or did not build the tools they use. I certainly know of no internal or external strictures dictating that the “building” part of their work is computational linguistics, while the use of those tools is not. Not only that: all of these linguists (just a few examples are Douglas Biber, John Goldsmith, Dan Jurafsky, Mark Davies, and Christopher Manning, all of them known for a wide range of scholarly activities), despite their overt and declared interests in exploiting computers for the analysis of language, write substantial analyses of their work for others to read. All of this work “counts” as computational linguistics. I know of no stricture within the field that says you must be dedicated to building things if you want to be a part of it, or that building things must constitute your primary investment in the field: on the contrary, you must be dedicated to computational analysis of languages that produces interesting results, just as the literal meaning of the phrase “computational linguistics” suggests. Just to be clear: that can and does entail building tools, if you want to do so: it just entails building as part of a suite of activities, which also includes using tools and generating analyses that compel the attention of other linguists. I think DH should and could be even more like Computational Linguistics (and more directly allied with it, as well), and the suggestion that only the building part “counts” moves in the contrary direction.
There is more to say about this analogy, because there certainly are some researchers who prefer to focus their work almost exclusively on building computational tools. For the most part, those folks live in another discipline entirely, usually computer science or electrical engineering. There are close and productive ties between computer science and computational linguistics. There are some similar ties between digital humanities and computer science, but I think there could be more. But the more of these there are, the less one might expect the humanist members of teams to be the right ones to do the heavy parts of building, since those are typically the skills that are treated in exquisite detail in computer science. So what? What I want are interesting results, period. I want them in DH the same way I want them in any other humanities specialization.
It’s worth reflecting on this just a bit more, because it speaks to a problem we hear a lot about especially in English Departments with regard to evaluation of DH scholars. Computational linguists often work in teams, just like DH teams. In these teams, the distribution of tasks varies. I don’t know of particular scrutiny being paid to who does or does not do the actual building on those teams–the interest is in the results, and in having made a significant contribution to them in any fashion, and being able to articulate that contribution.
Now if we reflect on significant DH projects, can we actually say with certainty that the significant figures in DH actually are builders, and if so, in what respect? One of the figures whose work is most often and rightly pointed to as indicative of the potential of DH is Franco Moretti. As far as I know, the work for which he is most famous, on historical trends in the development of the novel in Europe, can best be described as using tools and interpreting the results of that tool-use; Moretti famously expressed very little interest in the tools used. (In his more recent Stanford Literary Lab experiments there is more discussion of the tools, but not much emphasis on Moretti’s direct involvement in building them.) Curiously, the Digital_Humanities stricture would pretty much rule out Moretti’s work as DH, which strikes me as seriously counterproductive (and very hard to explain to outsiders). Moretti is by no means the only relatively well-known DHer whose direct, practical engagement with building–especially with actual coding–is somewhere between “unclear” and “nonexistent.” Only if you care more about boundaries than results would you want to try to distinguish whether these people “are” or “are not” DH, rather than looking at the results they produce.
Beyond the credibility issue, I think we already see the distorting effects that promoting the building of tools and demoting their use can have. One is to generate a series of what are effectively prototypes that never move beyond that phase; another is a lack of focus on the differences between prototype work and actual live supported software; related to that is a lack of focus on even the process that takes designs from prototypes to live use, so that too many prototypes simply get built and then pass out of awareness. The authors of an important recent report about digital projects in the UK, Sustaining Our Digital Future (Strategic Content Alliance, 2013), Nancy Maron, Jason Yun, and Sarah Pickle, write a lot about these problems:
For well over a decade, significant investment in creating digital resources has been spurred by government agencies and funders, as well as by private philanthropists. Even today, developing sustainability plans remains a challenge for many of these projects. While most will agree that, at the very least, early efforts to create digital content were valuable for increasing the capability and experience of those who engaged in them, some of these earlier projects have been criticised for not being “future-proofed” and indeed, not all are easily available today; a few may be entirely inaccessible and even those that do exist have lost value as their content and interfaces remain frozen in time or worse. A review of UK Digitisation Projects, funded by the New Opportunities Fund (NOF) Programme from 1999-2004, evaluated 154 grants and found that as of August 2009, 25 or 16% were found to have “no known URL or URL not available” and for 82 or 53%, it was noted that while the website exists, it “seems not to have changed since the launch”. The LAIRAH Project: Log Analysis of Digital Resources in the Arts and Humanities, a study that sought, among other things, to “determine the scale of use and neglect of digital resources in the humanities” reviewed usage logs of the 1255 projects in the Arts and Humanities Data Service, finding that “most of the projects that we studied are finished, [but] very few are being actively updated.” (11)
Such an unfortunate situation has many explanations, but it is clear that the demotion of using tools, both in the discipline of DH and in its funding streams, cannot be helping matters.
Force-Directed Graph of Topic Correlation Network Layout, 1800-1849, from Michael Simeone, “Visualizing Topic Models with Force-Directed Graphs,” generated with tool at http://isda.ncsa.illinois.edu/~mpsimeon/topics/FDE/indexvml.html
One troubling dynamic I’ve seen over the decade-plus history of digital humanities and its frequent and often overt emphasis on building above and beyond most other forms of scholarly activity is this one, which is to some extent the converse of the prototype problem. This is that when tools or methods are proven useful and powerful, and therefore become widely distributed and used by a range of scholars who may or may not see themselves explicitly as “part” of DH, that very usefulness and ubiquity ends up disqualifying them as part of DH. An old example: in the early days of the web, plain old HTML was considered enough of “building” that many projects were said to qualify as DH simply by dint of using HTML. Then, when blogs started to become popular but blogging software had not been packaged up enough to make it easy for anyone to use it, blogging was seen as part of DH and assembling a blog was seen as “building.” Then HTML skills became more widespread, building blogs became easy, and of course many DHers use blogs, but having a blog and writing HTML are no longer considered good ways to qualify a project as DH.
Now let’s take a more pointed and more current example. One of the latest technologies being promulgated through many quarters in DH is topic modeling. We’ve already seen a number of truly insightful, analytical projects using topic modeling to draw interesting conclusions about various bodies of text. Just a few of the several recent projects that have gotten attention include: Andrew Goldstone and Ted Underwood, “What Can Topic Models of PMLA Teach Us About the History of Literary Scholarship?“; Jonathan Goodwin, “Topic Modeling Signs” and “Creating Topic Models with JSTOR’s Data for Research (DfR)“; Ted Underwood, “Topic Modeling Made Just Simple Enough” and “Visualizing Topic Models“; and Ben Schmidt, “Keeping the Words in Topic Models.”
I hope and trust that there are few people who would demur from the view that all of these are excellent, worthwhile, even exemplary instances of what DH can do. They tell us important things about both the shape of literary production and of critical production, depending on the corpora to which they have been applied. As exemplars, it’s important to note what these projects have in common: building tools, using tools, and writing up the results. I would hope that some of those results would eventually be published in peer-reviewed journals or edited collections, but taken as a whole it is hard to imagine these not being the sorts of contributions that English and History departments would consider meaningful contributions to promotion and tenure files.
So, I think that topic modeling is here to stay, and there are reasons to suspect that major data providers–for example, JSTOR, which provides some of the data (via its Data for Research interface, described at some length in Goodwin’s “Creating Topic Models with JSTOR’s Data for Research (DfR)“) used in the analyses of critical writing–do too. But topic modeling is nothing more than a set of algorithmic processes. If they are valuable, I’d expect to see JSTOR, EEBO, and many others to incorporate topic modeling tools into their interfaces: in fact, I presume they see the work of Profs. Underwood, Goodwin, Goldstone, Schmidt and others as in some sense building prototypes for future applications. That should make it possible for a wide range of scholars to use the tools to draw all kinds of interesting inferences about a wide range of subject matters. But if we follow the Digital_Humanities stricture, that work would no longer count as digital humanities. Yet continuing to see it as DH would encourage even more scholars to utilize it and generate interesting results with it. The deployment of topic modeling tools by data providers would also help to address the sustainability issue, since these major data providers are already in the business of supporting and maintaining tools like these and the data on which to do research with them.
I don’t deny that there will probably remain new topic modeling tools to build. What I am hoping to point out is that the very usefulness of topic modeling suggests it will become part of the scholar’s toolkit, and that if we then arbitrarily deem that success to mean it is no longer part of our research enterprise, we are cutting off our nose to spite our face. Wide adoption and use is success, and interesting results produced with digital tools deserve to be called digital humanities.
Next: a follow-up on exclusionary definitions of DH
[...] we might have instead [that] could involve looking at great work that’s happening now and talking about what makes it [...]
In the spirit of open discussion, and because I exposed my graduate DH course to this kerfuffle last week, I would be extremely interested to hear from the authors of the Short Guide about these issues — for me, the most important issue being the line drawn between research DH and all other types of DH. Why? If David can’t draw them out, perhaps we’ll see them at the Digital Humanities Conference in Nebraska?
I promise fair questioning and reasonable debate, but it needs to be done. If not for creating a record of the discord for administrators out there, but also for all the undergraduate and graduate students of DH who don’t fit into the research-intensive role that the Short Guide defined for them.
As I point out in a note I mostly wrote to myself (http://johnlaudun.org/wtwrq), some of this definitional wobbling / strike is really the product of two once separate arenas, computational humanities and digital medias, getting folded into one arena. (And there are some funny names the older in-group members have for the other out-group. But not here.)
From my point of view, Harris raises probably the most important reason to sweat this stuff: institutional implications which can have real effects, warming or chilling, especially for some of us. The further we get from that reason the more inclined I am to adopt a wait and see approach, much like what Underwood suggested in the comments to the previous post in this triptych.
That sounds dismissive, and I don’t mean it to be. I’m happy to read and follow the arguments and discussions. And I’m glad they are being had. I especially like that the bizarre “Short Guide” is getting a good reading. I confess I found chunks of it inscrutable.
Strife, not strike. Damn you, autocorrect. And media is already singular. I have no idea how I pluralized it.
Media is already plural. Oof. It’s time to sleep.
[...] in-group and out-group dynamics that plague the digital humanities community, and, second, the role of tools and tool use in definitions of what is, and is not, work in the digital humanities. Both posts have already [...]
[...] and get into some impromptu Derrida. But, I was all fired up (again) about this DH Short Guide and David Golumbia’s response. So, I asked them to read the response and my comment. One of our own tweeted “#beardstair [...]
The paragraph that prompted this debate really suffers from its brevity. It is primarily concerned to ensure that DH is not perceived as excluding the study of cultures from the more distant past. Thus the beginning of the next paragraph insists that DH is about studying the entire scope of human history. The subsequent statement that this why DH extends outside the traditional scope of the humanities feels like a non sequitur, and, again, I think the problem is excessive brevity. But, to go back to the original claim, that the “mere use” of digital tools is insufficient to qualify as DH, perhaps we should concentrate on “mere”, taking it to mean without reflection. In this case, one need not build digital tools to do DH; the important point is that DH requires conscious reflection about digital tools and methods as some component of the research/learning process. This would seem to contradict the claim that DH is not exclusively the study of the digital, but what it really means is that what constitutes DH is some combination of *both* the study of historical or present-day culture *and* how one may use digital tools (or what it means to do so). This interpretation would seem to anticipate the later claim that “Digital Humanities is engaged in developing print-plus and post-print models of knowledge” (5). I’m curious as to whether people feel that this is an overstatement or exclusionary language.
As I write in my response to Aden, Chris, and James below, I just don’t see many places in the “Short Guide” or the full D_H book where use of existing tools and archives is described as part of DH, whereas there are many places where the development of new archives and new tools are explicitly mentioned. I don’t see the single paragraph about tool use as being addressed to the question of the subject matter of DH at all, and I don’t see evidence that “mere” means “without reflection”: on the contrary, I see a lot of evidence (particularly in the 5 case studies) that it means “without having built the tools/archives oneself.” If there is evidence that it means “without reflection” and that use of existing tools and archives to generate original analyses qualifies as DH to the book authors I’d like to see it, although it is certainly not prominent.
Several commentators (Chris, James, Aden) have suggested that in context, the authors of the D_H volume did not mean to be ruling out use (as opposed to building) of bona-fide computational tools, but only of “ordinary” digital resources like Twitter and blogs. I admit that is a generous and reasonable reading of the language of the sentence I quoted, but I’m not sure I see support for it in context:
a) The D_H book includes five “case studies,” each of which includes the building of original tools or archives, and none of which resemble even the Moretti example, which I posit here as developing an analysis using existing computational tools on an existing textual corpus;
b) The continual emphasis on “projects,” “design,” and emphases like “the environment that has been designed for the work’s performance and publication; the interface and data structures, the back-end database, and the code that enables multiple forms of audience engagement,” all suggest to me that they mean the phrase more restrictively;
c) I don’t see other places in the book where the use of existing tools is mentioned in any positive sense, although I may have missed it.
I’d be interested to see contrary evidence to this, if anyone can point it out.
As I hope to address in my next post, the restrictive meaning also happens to map exactly onto the funding priorities of the major granting institutions.
I have extensive personal experience with one of the authors of D_H, who did think that only building of tools and archives counted, and who did think, when it was not prepackaged, that blogging “counted” as D_H, and that it no longer does.
Taken in context, I suspect the authors of the “Short Guide to Digital Humanities” had no intention of establishing rigid boundaries for the field—as others noted, the intended audience is germane. Still, the authors of this essay are hardly the first to utter this pronouncement (“The mere use of digital tools for the purpose of humanistic research and communication does not qualify as Digital Humanities.”) or the implied emphasis on “more hack, less yak,” and this serves as an apt springboard for a discussion of the role of tool building in dh.
The term “digital humanities” (lower case) embraces the disciplines that attempt to comprehend cultural meaning in the human experience via digital methodologies. This describes an intellectual quest, a process of critical thinking. The tools employed in the process, be they quill or cursor, are irrelevant. Tweeting may not constitute dh, but an analysis of the role of tweeting in our culture certainly may. On the other hand, the act of designing the code that produced Twitter may not.
There will come a day when digital eclipses analog and “born digital” is a given. And in that context, the digital humanities will become simply, the humanities. We will look back and laugh at the very thought that someone wanted to establish a rigid dictum that the bona fide digital humanist must create her own tools. As Jeremy Boggs suggested (I am paraphrasing), “We don’t call the conventional humanities model ‘pencil humanities,’ why should we call something ‘digital humanities?’”
Yes, we are fascinated by “something shiny,” and yes, we quite rightly celebrate the act of creating the tools that will unlock the doors to the digital domain for humanists yet unborn. But this gestational phase will pass; the tools will become numerous and readily available. Then being a “digital humanist” will be associated with the process and the product rather than building the tools used to facilitate it.
Particle physicists don’t build particle accelerators. Neuroscientists don’t build MRI machines. Most psychologists don’t write statistics software. It seems completely insane to expect scientists who use technology to do science to also build their own technology. Given the complexity of the systems involved in fields like physics, genomics, neuroscience there is nit a single person who can understand the whole system. Maybe DH is different because ostensibly one person could write an algorithm to perform some kund of data analysis, but can they use a script or does it have to be in assembly, which would be crazy. The line would totally arbitrary. I completely agree that unless you just want to engineer tools, the results are all that matter.
Sorry about the mangled language – I wrote that on a phone.
To be fair, I think their point is that “tweeting” doesn’t a digital humanist make. Nor a “website” nor a “blog”… Nonetheless, “make” is becoming a code word for distinguishing development from use, which is a bad path to walk.
Limiting DH to tool development gives an impoverished understanding of the proto-discipline. The point of a tool is to punctualize its procedures, and on occasion we need to depunctualize it in order to understand how it shapes our understandings rather than acts as a neutral procedure. However, dwelling in the process isn’t the same as doing the job. The impulse for the reversal is simple though — development costs more than use, so living in “development” without moving to results is a way of maximizing revenue and building empires rather than doing research (a thorny problem when our administrative institutions measure research by “revenues” and “empires” rather than actually reading the results…). Like therapy, development needs an end point or it becomes an end in itself — you only return to it when needed, not as a matter of course.
Once I’ve made a hammer, I punctualize my understanding of the energy in the head of the hammer over the length of the arm — the point of the tool is that I can get to inputs and outputs without thinking the process, even if I created the hammer myself. The aim is to build a house, not to live in the hammer’s process or just “make” more hammers. Once a good markup is developed, the point is to use it. Once a good tool is developed, while it may need updates and improvements, the point is to use it.
There’s also the allocation of resources. If Moretti coded himself, it would be a misallocation of resources (and very expensive code!). Fund or hire appropriate people for the tasks.
Most folks doing DH aren’t going to code a new BIOS or OS. It’s punctualized and needn’t be considered. Likewise, sociologists and psychologists use digital tools and mathematical modelling, but they don’t mistake the tool for the job. Or for that matter, most DH practitioners read without knowing how to operate a printing press or make paper.
A tool for its own sake isn’t DH — it’s a sponge for resources that doesn’t produce results. DH isn’t simply “making” new tools; it’s making and using for a Humanities job.
So, yes, “tweeting” does not a digital humanist make, but neither does “making.”
As we continue to debate the efficacy of DH, its definition, its terminology, its participants, I’m becoming fatigued. What the authors of the Short Guide did was supply a primer to administrators (for that’s who they said it’s intended to educate) to deny tenure to a whole bunch of DHers at lower-tier non-R1 universities and colleges where bringing DH to the masses (aka our students) means bringing it into the classroom for screwing around. They unauthorized faculty like me who can’t afford to build tools. By not allowing for a distinction in using digital tools (my colleague *knows* about Twitter, tweets, but does he/she *really* use it as a DHer in the way that I do?), administrators can articulate that using Twitter in the undergraduate classroom is just another form of dialogue, that there’s nothing unique to the implementation of a new type of rhetoric.
It was irresponsible and, yes, elitist. Please come work in my university, in my department, for a year. I do DH wherever I can, and that means student-driven research.
Thank-you Katherine. I was hoping SOMEONE would point this out. Not to mention all of the adjuncts/non-tenure-track faculty who have access or the resources to learn to code, in order to build, or who are, like you, at institutions where joining a collaborative unit is also impossible.
Blogging about this as I write this…
I appreciate this comment a lot, & will try to expand on this point a bit in the near future.
I had a conversation about this at the topic-modeling workshop at MITH. I think it started when I brought up one of Ian Bogost’s quips about digital humanists being impressed with themselves for installing packaged software, which I thought was somewhat unfair but still amusing at the time. Upon reflection, I realized that everything you can do on a computer involves using someone else’s tools, even if it’s a compiler. So everyone using them, no matter what their level of coding proficiency, has an infinite debt, in Graeber’s sense.
My topic-modeling experiments, for example, relied in various ways upon two different R packages, MALLET, perl, python, the NLTK, the WordNet database, Blei’s algorithm, several generations of statisticians and probability theorists, ad infinitum. There are already GUIs for MALLET, a topic-modeling plugin for zotero (paper machines), and probably several other tools that I haven’t yet heard of that can already provide a coding-free solution for most of that stuff. A tool or interface that could produce topic-models of the DfR data would be very easy to do, and it wouldn’t surprise me if JSTOR has something like it in the works.
The main project that I have done with topic-modeling, aside from the blog posts, is an examination of a period of the intellectual history of folklore written in collaboration with my colleague John Laudun. It’s a heavily qualitative analysis, in other words, that uses topic-modeling as an exploratory tool. I like to think it qualifies as “digital humanities” as I understand the term.
I do agree with Chris that the “tools” comment was probably meant to distinguish between setting up a class blog and creating Zotero or Omeka, for example, though I also agree with you about the implications of such a distinction.
Just to briefly reply to both Chris & Roger, my topic modeling example was meant as a technology that today requires coding, but in the future might not. I definitely think the Digital_Humanities authors would say it counts today. I worry that if the JSTOR interface starts including topic modeling queries, for example, topic modeling will stop counting as DH. I think there is some reason to suspect this might happen.
I also agree with Chris’s comments about the fuzziness in “digital tools”–this deserves much closer attention and thought.
I have a lot of thoughts about Stephen’s comments about building, and based especially on comments he’s made in reaction to his initial statements, I suspect we agree more than we disagree and more than may be obvious from my comments here. To emphasize as clearly as possible: I have no problem with building. I like building. I want people to build. My primary concern is with what is getting ruled out as legitimate scholarship (in English Depts in particular) than with what is getting ruled in. With the proviso that I am unpersuaded that anything needs to be ruled in that can’t be described in a research report–as in computational linguistics and most other computational fields, I will stand by the expectation that a scholar should be able to articulate the significance of his/her work in words as a part of what they do.
As a general note, I am happy to announce the deletion of the line { text-transform: lowercase } in the design template for this site.
Like the unfortunate capaciousness of “digital humanities,” the phrase “digital tools” too seems to cause more problems than it solves. And so, at one level, I’m inclined to simply agree with everything you say here: indeed!
But then, I worry that this too easy agreement may come at the potential cost of not really understanding what’s at stake. So, what exactly do the authors of digital_humanities mean by a “digital tool”?
Would it not be possible to contextualize the piece from digital_humanities you quote a little more? Set it inside its wider context, and keeping in mind its announced audience (which certainly seems to include admins and others who turn to such a document out a sense that they don’t fully have a handle on what dh is), would it not be possible to gloss the meaning of “digital tools” in the sentence you quote more restrictively–as meaning something like “digital humanities” is not simply (pace Stephen Marche) “being vaguely in touch with technological reality — being an English professor who is aware of the existence of Twitter, for example.” That is, having a blog is not doing digital humanities. Is that also a fair reading of the passage? And, if so, I would be less inclined to disagree with it, I think. (Though, I know too, that some would find this unnecessarily restrictive.)
There is certainly nothing else in that piece (nor in the very next paragraph’s reference to dh’s embrace of “quantitative methods from the social and natural sciences [and wouldn't computational linguistics be as at home here, among the social sciences, as the 'humanities'?]“) which would lead to the conclusion that the authors would not include the topic modelling work you quote under the rubric of “dh.”
There is, no doubt, a discourse about building in dh which, as I suggested in a tweet a little earlier, seems part of a longer history about the value of interpretation as the defining fact of the humanities; (Natalia Cecire’s discussion (which I know you know) talks about these questions well, and raises skepticism. And the digitual_humanities piece’s reference to “Interface design as knowledge modeling” or “Ability to use design critically” seem to, indeed, be part of this “epistemology of doing.”
But this discussion seems to involve something other than simply whether or not a “digital tool” was used (or built).
This is yet another interesting post.
On the one hand, yes, I do agree with you that restricting DH to people who make stuff has all sorts of problems attached to it. I, for one, obviously count Richard Grusin in DH (as he has “outed” himself as a user of tech, but not a maker on Facebook).
On the other hand, I agree with Stephen Ramsay when he says that building involves completely different kinds of knowledge that aren’t available to people who simply critique media artifacts. Building and making need to be more thoroughly theorized, in my view. Not to mark a distinction between DH and non-DH, but simply to show how making leads to certain kinds of knowledges and relationships that are not the same as traditional critical work. Here I’m thinking of DIY communities, also the way figures like William Blake create fundamentally different work than other poets alive during his period simply because he had to publish that work. The making I value comes from this DIY, open source, artisan-inspired arena, which I think has some things to teach our field. But, again, I absolutely reject the notion that DH should be limited to making and not (as you say) using.
I also think that topic modeling is a bit of a wrong-headed example of using digital tools. You “make” models out of algorithmic expressions and interpretation, then refine them by running data-sets over and over again. So – at the very least perhaps – topic modeling could mark a middle space between making and using: a kind of deconstructive gesture towards the binary being laid out by other DH practitioners.