Digital Humanities Part 2: Digital Humanities Tools for Dissertations

In Part 1 of this series I asked what the digital humanities are. This post gets practical. If you are writing a dissertation right now, or about to start one, this is a guide to the tools that can actually help you, organized around the problems you actually have.

First, the claim that shapes everything else in this post. A dissertation is not just a long argument. It is a research system. You gather sources, you organize them, you transform them into evidence, you interpret that evidence, and you present the interpretation in a form your committee can examine. Most of that system stays invisible in a traditional dissertation. The footnotes gesture at it. The methods section summarizes it. But the system itself, the actual machinery of files and notes and decisions, lives in a private folder that no one else ever sees.

The real value of the digital humanities for dissertation writers is that they make the research system explicit. When you build a corpus, you have to decide what belongs in it and write that decision down. When you make a map, you have to confront how much you actually know about where things happened. When you version your drafts, you create a record of how your argument changed. None of this replaces interpretation. All of it disciplines interpretation, and that discipline is precisely what a dissertation is supposed to demonstrate.

So this is not a listicle of fifty tools. It is an opinionated walk through the research problems every dissertation writer faces, with the smallest set of tools I trust for each one, and with honest warnings about the interpretive risks each tool introduces. Tools are secondary to transformations. The question is never "should I use Voyant or Gephi." The question is what transformation your argument requires, what interpretive risk that transformation introduces, and how you will document it.

Before you pick a single tool #

Here is the advice I wish someone had given me before I opened my first piece of software. Write a method statement first.

Before you install anything, write one page answering five questions. What is the humanistic question I am asking? What evidence bears on it? What would a digital method add that reading alone cannot? What is the smallest toolchain adequate to that addition? What are the ethical and permissions issues in my sources, and how will I handle them?

That one page will save you months. Graduate students lose entire semesters to tools they adopted because a workshop made them look exciting. The workshop was not wrong. The tool was probably excellent. But excellence is not relevance, and a dissertation runs on a clock. Every tool you adopt has a learning curve, a maintenance cost, and a documentation burden. If the tool does not serve a transformation your argument requires, it is not helping you. It is a very sophisticated form of procrastination.

The method statement also forces you to name your transformations. Every digital method transforms your sources into something else. Optical character recognition transforms page images into text, imperfectly. Corpus construction transforms a tradition into a bounded dataset, selectively. Georeferencing transforms narrative descriptions of place into coordinates, with false precision as a standing risk. Network extraction transforms relationships into nodes and edges, flattening everything the categories cannot hold. None of these transformations is neutral. Each one is an interpretive act, and your committee is entitled to see it documented. Record your corpus boundaries, your cleaning steps, your exclusions, your uncertainty, your tool versions, and your settings. Future you, revising chapter three at two in the morning, will be grateful. So will the scholar who tries to build on your work in ten years.

With that frame in place, we can talk about tools. I have organized what follows by dissertation problem, not by tool category, because you do not wake up needing "a network analysis package." You wake up needing to manage two thousand sources, or to read more sermons than any human can read, or to show a committee where something happened.

The center that built your toolkit #

Before the problems, though, one piece of context that I find remarkable and that too few graduate students know. A single university center built much of the everyday infrastructure of humanities research.

The Roy Rosenzweig Center for History and New Media at George Mason University, usually shortened to RRCHNM, was founded by the historian Roy Rosenzweig in 1994. Its mission is to use digital media and technology "to democratize history: to incorporate multiple voices, reach diverse audiences, and encourage popular participation in presenting and preserving the past."^[1] Rosenzweig himself died in 2007, at just fifty-seven, and the center was renamed in his honor in 2011.^[2] He saw earlier than almost anyone that historians would soon face what he called a shift "from a culture of scarcity to a culture of abundance," and he argued in a landmark 2003 essay that scholars "need to be thinking simultaneously about how to research, write, and teach in a world of unheard-of historical abundance and how to avoid a future of record scarcity."^[3] That essay repays reading in full, and it frames this whole series. Parts 5 and 6 will return to it.

The record of software that came out of this one center still astonishes me. Zotero, the reference manager that anchors the research systems of scholars across every humanities discipline, was established at RRCHNM.^[4] Tropy, the tool for organizing archival photographs, was created there.^[5] Omeka, the platform behind thousands of library, museum, and scholarly exhibition websites, launched from the center in 2008.^[6] PressForward, the WordPress plugin that powers curated scholarly publications like Digital Humanities Now, launched there in 2011.^[7] Four tools, one center, and together they cover source management, archival photography, web publishing, and scholarly communication. Well-funded commercial vendors have not matched that record of building things scholars actually use every day. If your dissertation touches the digital humanities at all, you are almost certainly running RRCHNM code, and it is worth knowing where it came from and why it is free.

The center is now in its fourth decade, its sites draw over two million visitors a year, and it continues to train digital historians and build data-rich histories.^[8] Its current executive director is Lincoln Mullen, about whom more below, because his own work models the learning ethos I want to recommend to you.

Managing the research system: Zotero #

Every dissertation problem I will discuss sits downstream of one unglamorous task. You have to manage sources, in the hundreds or thousands, over four to eight years, without losing anything. This is the problem to solve first, and Zotero is the answer.

Zotero describes itself as "a free, open-source research tool that helps you collect, organize, and analyze research and share it in a variety of ways," and for once the self-description undersells the product.^[9] It has been in continuous development since 2006, it is maintained by the nonprofit Corporation for Digital Scholarship, and it will never charge you for the core product or hold your library hostage.^[10] That last point matters more than it sounds. Your dissertation library is a multi-year asset. Do not build it inside a commercial product whose pricing, ownership, or existence could change before your defense.

Here is what a Zotero-centered workflow looks like in practice. The browser connector captures full bibliographic metadata from library catalogs, JSTOR, publisher pages, and news sites with one click, usually grabbing the PDF along the way. The built-in PDF reader lets you highlight and annotate, and your annotations live in your library, searchable, right next to the metadata. Tags and collections let you organize the same source into multiple chapters without duplicating it. The word processor plugins format your citations and bibliography in any of the more than 10,000 styles in the Zotero Style Repository, which means switching from Chicago notes to author-date because your committee changed its mind is a five-minute problem instead of a five-day one.^[11] Group libraries let you share sources with your adviser or a writing group.

Two habits turn Zotero from a citation manager into a research system. First, tag by argument, not just by topic. A tag like "evidence-for-chapter-2-counterargument" is worth ten tags like "ritual." Second, write a sentence or two of notes on every source when you first read it, in your own words, stating what the source is evidence for. Four years later those sentences are the difference between a literature review that takes a month and one that takes a season.

Managing the archive you photographed: Tropy #

If your dissertation involves archival research, you will come home from the archive with thousands of photographs named IMG_4032.jpg, and six months later you will have no idea which box, folder, or archive half of them came from. This failure mode is so universal that RRCHNM built a dedicated tool to prevent it.

Tropy is "free open-source software that allows you to organize and describe photographs of research material."^[12] Its central insight is that the photograph is not the unit of research. The document is. A five-page letter is five photos but one item, and Tropy lets you group photos into items, attach metadata about the archive, collection, box, and folder, add tags and lists, and transcribe passages right next to the image. It is now developed jointly by RRCHNM, the Luxembourg Centre for Contemporary and Digital History, and Digital Scholar, with Mellon funding behind it, which is a reasonable proxy for institutional staying power.^[13]

The discipline Tropy enforces is the discipline your footnotes will need anyway. Every archival citation in your dissertation ultimately resolves to repository, collection, box, folder, item. If you enter that metadata the week you visit the archive, your citations write themselves. If you do not, you will be emailing archivists apologetic questions three years later. Tropy also exports to JSON-LD and CSV and integrates directly with Omeka S, so the descriptive work you do now can seed a digital exhibit later.

Versioning the argument: Git and GitHub #

Here is the tool recommendation that meets the most resistance from humanities graduate students, and the one I will defend hardest. Put your dissertation under version control.

Git is a system that records snapshots of your files over time, with a note attached to each snapshot saying what changed and why. GitHub is a service that stores those snapshots remotely. Together they give you three things no cloud drive gives you. A true history of your argument, so you can recover the paragraph you deleted in March. An offsite backup that is a deliberate act rather than a background sync you hope is working. And a log of your own thinking, because commit messages like "cut the Weber section, the argument works without it" are a record of decisions, not just of keystrokes.

The cost of entry is lower than its reputation suggests. You do not need the command line to start. The Programming Historian ran a widely used lesson on GitHub Desktop, the point-and-click application, framed explicitly for scholars writing articles and dissertations in plain text.^[14] The lesson has since been retired because the software's interface moved on, but the workflow it teaches, edit, commit, push, remains exactly right, and current GitHub Desktop documentation covers the same ground. If you write in Markdown or LaTeX, version control fits your files natively. If you write in Word, it still backs you up faithfully, though the change-by-change comparisons work best with plain text.

Version control also quietly prepares you for something bigger. If your dissertation involves any code or data at all, versioning is not optional. It is the difference between "the analysis in chapter four" being reproducible and being a rumor. Committees increasingly ask, and future scholars will certainly ask, exactly what you ran and when.

Cleaning what the sources give you: OpenRefine #

Somewhere between collecting sources and analyzing them lives the least discussed phase of digital work, and the one where more interpretive decisions hide than anywhere else. Cleaning.

Suppose you have extracted a spreadsheet of names from a mission society's annual reports. The same missionary appears as "Rev. J. Smith," "John Smith," and "Smyth, J." The same station appears under three spellings and two colonial renamings. Before you can count, map, or graph anything, you have to decide that these are the same person and the same place. Those are historical judgments, not technical chores, and they belong in your documentation.

OpenRefine is the tool for this work. It calls itself "a powerful free, open source tool for working with messy data," which it cleans, transforms between formats, and extends with web services and external data.^[15] Its clustering functions find probable variants of the same name and let you approve or reject each merge. Crucially for our purposes, OpenRefine keeps a complete, exportable history of every operation you perform. That history is your methods appendix, generated for free while you work. When a committee member asks how you standardized names, you can show them, step by step. That answer is the difference between data cleaning as silent distortion and data cleaning as documented method.

Reading more than you can read: corpora, Voyant, and AntConc #

Now to the transformations that get called "distant reading." Suppose your dissertation asks how a denomination's language about mission changed across sixty years of periodicals. No one can close-read sixty years of periodicals. A corpus lets you ask the question anyway.

Begin with the principle that governs everything downstream. A corpus is an argument about inclusion. The moment you decide which periodicals are in, which years, which genres, whether letters to the editor count, whether reprinted material counts, you have made claims about what represents the phenomenon you are studying. Write those claims down before you analyze anything, because every count, trend, and topic you find is conditional on them. A finding that "mission language declines after 1920" means one thing if your corpus includes the denomination's women's auxiliary magazine and another thing entirely if it does not.

For exploring a corpus, start with Voyant Tools. Voyant is "a web-based text reading and analysis environment" that its creators describe as "a scholarly project that is designed to facilitate reading and interpretive practices."^[16] Note that word choice. Reading, not results. You paste in or upload your texts and Voyant gives you word frequencies, trends across the corpus, keywords in context, and a dozen other views, all linked, all in the browser, with nothing to install. It was built by Stéfan Sinclair and Geoffrey Rockwell, whose book Hermeneutica argues at length that these tools are instruments for interpretation rather than proof machines.^[17] That framing is exactly right, and it is why Voyant is safe to recommend to beginners. It invites you to look, then look closer.

When you need more control, AntConc is the next step. Laurence Anthony's freeware corpus analysis toolkit gives you concordances, collocates, keyword lists, and n-grams with precise, adjustable settings.^[18] Where Voyant invites exploration, AntConc supports the focused question. Show me every occurrence of "civilization" within five words of "Christian," by decade. That is a query a chapter can be built on.

The method that makes any of this scholarship rather than decoration is the movement between distant and close reading. The corpus view shows you a pattern. You then go read the passages that make up the pattern, in full, in context, the way you were trained to. Half the time the pattern dissolves under close reading, an artifact of OCR errors or a reprinted article counted forty times. That is not failure. That is validation, and you should report it. The other half of the time the pattern survives, and now you have a finding you can defend from two directions at once. Validate every computational output through close reading before it enters your argument. No exceptions, and especially no exceptions for the outputs that confirm what you hoped to find.

Showing where: QGIS and honest maps #

Space is evidence. Where congregations formed, where presses operated, where pilgrims walked, these are facts an argument can rest on, and maps make them visible in ways prose cannot. But maps are also the digital genre most prone to quiet dishonesty, because a map asserts every location with the same confident dot.

QGIS is the tool I recommend for serious dissertation mapping. It is a full open-source geographic information system, community-owned and free.^[19] The learning curve is real, a few weeks of steady practice rather than an afternoon, but it repays the effort with complete control. You can georeference a scanned historical map, layer your evidence over it, distinguish categories of places by symbol, and export publication-quality figures for the dissertation itself.

The interpretive discipline matters more than the software. Historical sources rarely give you coordinates. They give you "near the river crossing," "the old mission station," "a village three days' walk inland." Before you map anything, classify every place in your evidence into at least these categories: exact, approximate, contested, remembered, and lost. Then make the map show the difference, with distinct symbols or explicit uncertainty notes. A map that renders a remembered place and a surveyed one with the same dot has erased precisely the thing a humanist should care about, which is how people knew where things were. Your committee may not ask about this. You should do it anyway, because a map must not erase uncertainty, and because a map does not prove an argument. It visualizes evidence for one.

Showing who knew whom: Gephi and Palladio #

Networks tempt dissertation writers more than any other method, because humanities evidence is full of relationships. Correspondents, co-authors, teachers and students, lenders and borrowers, patrons and clients. Network analysis makes those relationships computable, and two free tools make it accessible.

Gephi is the established open-source platform for visual network analysis, powerful enough for large graphs and rich in layout and measurement options.^[20] Palladio, built at Stanford for humanists, is gentler.^[21] You upload a spreadsheet and get networks, maps, and galleries with almost no setup, which makes it ideal for the exploratory phase when you are still deciding whether network structure is even part of your argument.

The warning here is the same one, wearing different clothes. Node and edge choices are interpretive. When you decide that a "connection" means at least one surviving letter, you have decided that survival equals relationship, and that silence equals absence. Archives preserve some relationships and destroy others, on lines of gender, class, and empire that your dissertation probably cares about. So say what an edge means, say what the archive cannot show, and treat centrality scores as questions to investigate, not conclusions to report. "Why does this minor figure sit at the center of the graph" is a wonderful research question. "This figure was central" is, by itself, an artifact of counting.

Working with the sources themselves: Recogito, Transkribus, and eScriptorium #

Three tools serve the slow middle of a source-driven dissertation, where you are annotating and transcribing.

Recogito, from the Pelagios network, offers what its makers call "Semantic Annotation without the pointy brackets."^[22] You upload texts or images and mark up places, people, and events by selecting and clicking, no encoding knowledge required. It is particularly strong for place annotation, linking the places you mark to gazetteers, which means your annotations can become a map dataset later. For a dissertation on travel narratives, pilgrimage accounts, or missionary itineraries, Recogito can be the bridge from reading to mapping.

Transkribus applies machine learning to handwritten text recognition. It is run by a European cooperative of research institutions and describes itself as a platform for turning handwritten documents into searchable text.^[23] If your sources are manuscript letters, diaries, or registers, Transkribus can convert months of squinting into a searchable corpus. Train or select a model, correct its output on sample pages, and the model improves. The transformation is powerful and its risk is obvious. Recognition errors are not randomly distributed. They cluster on unusual names, non-standard spellings, and marginal hands, which may be exactly the voices your dissertation exists to recover. Report error rates, and hand-check every passage you quote. eScriptorium offers an open-source alternative in the same space, worth evaluating if institutional control of your data matters to your project or your archive's permissions.

The fastest on-ramp: Northwestern's Knight Lab #

Now for the section I most want overwhelmed graduate students to read. Suppose you need a publication-quality interactive, a timeline for a conference presentation, a map-driven narrative for a digital appendix, a before-and-after image comparison for a chapter on architectural change, and you have no time to learn QGIS and no intention of learning JavaScript. There is a place built for you, and it is Northwestern University's Knight Lab.

Knight Lab describes itself as "a community of designers, developers, students, and educators working on experiments designed to push journalism into new spaces."^[24] It sits between Northwestern's Medill School of Journalism and its McCormick School of Engineering, and that location explains everything good about its tools. Journalists have humanists' problems, real stories, real evidence, real deadlines, without the luxury of semester-long tool training. So Knight Lab built storytelling tools that produce professional results in an afternoon, and every one of them is free and open source. Four of them belong in a dissertation writer's kit.

TimelineJS is "an open-source tool that enables anyone to build visually rich, interactive timelines."^[25] The mechanism is disarmingly simple. You copy a Google Sheets template, fill in rows with dates, text, and links to media, publish the sheet, and paste its address into the TimelineJS generator. Out comes an embeddable, elegant, interactive timeline. For a dissertation, think of the chronology you are already building for your own reference, the sequence of synods, editions, controversies, or campaigns, and imagine it as a navigable object your committee can explore before the defense. The Google Sheets workflow means updating the timeline is just editing a spreadsheet.

StoryMapJS is "a free tool to help you tell stories on the web that highlight the locations of a series of events."^[26] Where QGIS produces analytical maps, StoryMapJS produces narrative ones. A sequence of slides, each pinned to a place, each carrying text and media, walking a reader along a route. A pilgrimage, a preaching tour, a migration, a supply chain. Its gigapixel mode does the same walking across a large image instead of a map, so you can guide a reader across a historic map, a painting, or a manuscript page, stopping at details in order. This is the tool I recommend when someone says they want "something like a documentary, but for my chapter."

JuxtaposeJS "helps storytellers compare two pieces of similar media, including photos, and GIFs."^[27] It puts a slider between two aligned images. Before and after the fire, the renovation, the iconoclasm, the urban renewal. All you supply is two image addresses. For any dissertation arguing visual or material change, a juxtapose slider communicates in two seconds what a page of prose approximates.

SoundCite solves a problem you may not have named. As Knight Lab puts it, "audio clips force uncomfortable choices: read or listen, but not both."^[28] SoundCite makes audio play inline, from a highlighted phrase inside your running text, so a reader of your web-published chapter can hear the hymn, the sermon excerpt, or the oral history clip at the exact sentence where you analyze it, without stopping. For scholars of religion working on sound, liturgy, or oral tradition, that changes what a written chapter can do.

Knight Lab maintains other tools worth a look, including StorylineJS for annotated charts and Scene for VR stories, but the four above are the core. None requires code. All embed anywhere that accepts an iframe, including Omeka and Scalar sites and most university web platforms. If the digital component of your dissertation needs to exist by next month, start here.

Learn by doing: Lincoln Mullen and the Programming Historian #

At some point a tool will not quite do what your argument needs, and you will face the question every digitally inclined dissertation writer eventually faces. Should I learn to code? My answer is a qualified yes, and the qualification is about how you learn, and the model I want to point you to is Lincoln Mullen.

Mullen is a professor of history at George Mason University and now executive director of RRCHNM.^[29] What makes him worth your attention as a dissertation writer is the shape of his work. He is a scholar of American religion whose first book, The Chance of Salvation, is a history of conversion in America published by Harvard University Press.^[30] He is also a builder whose computational projects serve historical arguments rather than replacing them. His America's Public Bible, published by Stanford University Press as an interactive scholarly work, tracks biblical quotation across millions of nineteenth-century American newspaper pages, and it won its arguments by pairing that scale with close reading of individual quotations in context.^[31] He has released R packages for historians, including textreuse for detecting borrowed text between documents and USAboundaries for historical state and county lines, tools built because his own research needed them and shared because someone else's would.^[32][33]

Two things about his practice transfer directly to yours. First, he teaches computation as historical thinking, not as programming for its own sake. His open, in-progress textbook Computational Historical Thinking states its aim in one sentence: "The aim of this book is to teach you how to think historically with computational methods."^[34] The book proceeds through miniature research projects, real questions with real data, which is exactly how you should learn, one small project connected to your actual dissertation at a time. Second, he insists that visualizations earn their keep. In an essay answering the common objection that DH charts merely show what we already knew, he describes showing audiences a blank chart first, axes and title only, and asking them to sketch the trend they expect. "The problem," he writes, "is that often it is not possible to know what a visualization would look like in advance."^[35] Try this on yourself before every chart you make. If you can draw the result in advance and you are always right, the chart is illustration. When your sketch is wrong, you have learned something, and that is when the method is earning its place in your dissertation.

The same learn-by-doing ethos has an institutional home at the Programming Historian, an open access, peer reviewed journal of methodology founded in 2008 by William J. Turkel and Alan MacEachern.^[36] Its tutorials walk you through real methods on real data, they are "rigorously peer reviewed," and every lesson is published under a Creative Commons CC-BY license with no fees of any kind.^[37] It now publishes in English, Spanish, French, and Portuguese. When you decide it is time to learn text analysis in Python, mapping in R, or data cleaning in OpenRefine, do not start with a generic programming course. Start with a Programming Historian lesson that ends with a result a humanist would recognize. Learning by doing, on materials that resemble your own, is the only tool pedagogy I have ever seen stick.

A worked example, start to finish #

Abstractions only carry so far, so let me walk one imaginary dissertation through the whole system. Suppose you are writing on healing practices in early twentieth-century American Pentecostalism, working from denominational periodicals, a founder's correspondence in two archives, and a handful of recorded oral histories from a congregation's centennial project.

The method statement comes first. The humanistic question is how claims about divine healing changed as the movement institutionalized. The evidence is roughly forty years of periodicals, about nine hundred letters, and eleven interviews. The digital addition, stated in one sentence, is that periodical language about healing can be tracked at a scale no reader can hold in memory, and that the letters' geography can show whether healing testimony traveled along the same routes as personnel. The ethical questions are real. The oral histories involve living people and a worshiping community, so they stay out of every public dataset unless consent, your IRB, and the congregation all say otherwise.

Now the toolchain, kept small. Zotero holds every secondary source and every periodical issue you cite, tagged by chapter and by argument. Tropy holds the four thousand photographs from both archives, grouped into letters as items, with box and folder metadata entered during the trip because past you read this post. The dissertation itself lives in plain text under Git, committed at the end of every writing day, pushed to a private GitHub repository, which cost you two afternoons to learn.

The periodical corpus requires decisions, and the decisions get written down. In: the movement's two flagship weeklies, 1906 to 1945, articles and testimonies. Out: reprints from other papers, advertisements, and the children's page, each exclusion noted with a reason. OCR quality gets spot-checked, and the error rate on a fifty-page sample goes in the methods appendix. Voyant gives the first look, and the trend line for healing terms shows a dip in the 1920s you did not expect. Following Mullen's blank-chart practice, you had sketched your prediction beforehand, and you were wrong, which is exactly why the finding might matter. AntConc then shows you every "healing" collocate by decade, and close reading of two hundred passages reveals the dip is partly real and partly an editorial change, testimonies moved to a new column your corpus had excluded. So the corpus gets revised, the exclusion log gets updated, and the finding survives in chastened, defensible form. That embarrassing-sounding correction is not a footnote to the method. It is the method.

The letters yield a spreadsheet of senders, recipients, and places, cleaned in OpenRefine with its operation history exported. Place names get classified as exact, approximate, or lost, since several healing homes appear in no gazetteer. QGIS maps the defensible ones with distinct symbols for the uncertain ones. For the defense and the department website, StoryMapJS walks viewers along one evangelist's 1913 itinerary in eight slides, built in an evening from work the research system had already done. A TimelineJS chronology of institutional milestones does similar double duty in a conference talk.

When the dissertation is filed, the corpus metadata, the exclusion log, the cleaned letter tables, and the analysis scripts go to Zenodo and get a DOI, cited in the dissertation's own bibliography. The conference paper goes to CORE with a DOI of its own. The oral histories go nowhere public, and the dissertation says so plainly, because documented restraint is also documentation.

Total new software learned: seven tools, none requiring code, plus one optional Programming Historian lesson when the text analysis outgrew Voyant. Every transformation named, every risk logged, every output validated by reading. That is what a research system made explicit looks like, and no single step was heroic.

Publishing the digital component: Omeka, Scalar, and PressForward #

Some dissertations end at the PDF. Increasingly, many do not. If your project includes an exhibit, an edition, or a curated collection, two platforms deserve your attention, and both come from the scholarly world rather than the startup world.

Omeka is "a free, flexible, and open source web-publishing platform for the display of library, museum, archives, and scholarly collections and exhibitions."^[38] It thinks in items, metadata, collections, and exhibits, which is to say it thinks the way archives think. Omeka Classic, public since 2008, serves individual projects well, and it has been downloaded over half a million times.^[39] Omeka S, the newer sibling, serves institutions running many sites and speaks linked open data natively.^[39:1] For a dissertation, Omeka Classic is usually the right size. If you organized your archival photographs in Tropy, you can move them into Omeka with their metadata intact, which turns the private discipline of your research system into a public contribution.

Scalar, from the Alliance for Networking Visual Culture at the University of Southern California, suits born-digital scholarly argument, long-form writing woven through media, with multiple pathways through the same material.^[40] Where Omeka presents collections, Scalar presents arguments about collections. If your digital component is closer to a media-rich monograph chapter than to an exhibit, Scalar is the better fit.

And for a different kind of publishing problem, staying current and making your field's gray literature visible, there is PressForward, RRCHNM's WordPress plugin for aggregating, filtering, and disseminating scholarship from across the web.^[41] Its proof of concept is Digital Humanities Now, which has surfaced blog posts, white papers, and conference talks that formal journals would never carry. A dissertation writing group, a graduate program, or a small subfield can run a PressForward publication with an editor rotation and an RSS reader. It is community infrastructure at dissertation-committee scale.

Making it last and making it count: Zenodo, Dataverse, and CORE #

You will produce more than a dissertation. You will produce a corpus, a dataset, cleaning scripts, maybe an edition or a website. Two questions decide whether that work outlives your defense. Where will it live, and how will people cite it? Part 5 of this series takes up preservation in depth, but the deposit habit belongs in this post because you should start it now, not after you graduate.

Zenodo is a free and open digital archive built by CERN and OpenAIRE that accepts research outputs "in any size, format and from all fields of research."^[42] Deposit your dataset or code there and it receives a DOI, a persistent identifier that makes it citable forever, with versioning so corrected datasets keep their history. Harvard Dataverse serves the same deposit-and-cite function with especially strong support for structured data.^[43] Either one transforms "data available from the author on request," which is where data goes to die, into a citable scholarly object with a permanent address.

For humanities scholars specifically, I want to flag Knowledge Commons, the scholarly network at hcommons.org, hosted at Michigan State University.^[44] Its repository, CORE, the Commons Open Repository Exchange, is "a library-quality repository for sharing, discovering, retrieving, and archiving digital work," and it assigns DOIs to deposits, registered with DataCite.^[45] What makes CORE especially useful during the dissertation years is its breadth. It takes conference papers, syllabi, datasets, and works in progress, the dissertation-adjacent outputs that have no other citable home.^[46] The conference paper you gave at AAR does not have to vanish into a program PDF. Deposit it, get a DOI, put it on your CV as a citable object, and let other scholars find it. It costs nothing, and it starts building the public research profile you will want on the job market anyway.

Whatever repositories you choose, cite your own datasets, code, editions, and websites in the dissertation itself, with their DOIs, exactly as you cite books. This is how the research system becomes visible and creditable, for you and for everyone who builds on you.

A decision path, and a closing caution #

Let me compress this whole post into the sequence I recommend every time someone asks "which tools should I use for my dissertation."

Define the humanistic question first, in writing. Identify the evidence that bears on it. State, in a sentence, what a digital method would add that reading alone cannot. If you cannot write that sentence, stop. You have saved yourself a semester, and reading alone is a proud and sufficient method. If you can write it, choose the smallest toolchain adequate to the addition. Zotero almost always. Tropy if there is an archive. Git if there is code or plain text. One analysis tool, not four, matched to the transformation your argument needs. A Knight Lab tool if you need an interactive fast. Then plan ethics and permissions before you build, especially for oral histories, living communities, and religious materials with access restrictions. Document as you go: corpus boundaries, cleaning steps, exclusions, uncertainty, tool versions, settings. Validate every computational output through close reading. Preserve and cite your datasets, code, and sites with DOIs. And keep the argument interpretive from first page to last.

That last clause is the caution I want to leave you with, and it is the hill this whole series stands on. A map does not prove an argument. A topic model does not interpret a tradition. A network graph does not understand a community, and a timeline does not explain change. You do those things. The tools transform your sources so that your interpretation has more, and more explicit, evidence to work with. Used that way, with the transformations named and the risks documented, digital tools do not make your dissertation less humanistic. They make its humanism easier to examine, which is what a dissertation is for.

In Part 3, I will turn to what all this looks like in theology and religious studies specifically, where our sources, our communities, and our questions put particular pressure on these methods.

In this series #

1. Digital Humanities Part 1: What Are the Digital Humanities?
2. Digital Humanities Part 2: Digital Humanities Tools for Dissertations
3. Digital Humanities Part 3: Digital Humanities for Theology and Religious Studies
4. Digital Humanities Part 4: Why We Need the Digital Humanities
5. Digital Humanities Part 5: Preserving Digital Humanities Projects
6. Digital Humanities Part 6: Preservation through Minimal Computing and GO::DH

---

1. Roy Rosenzweig Center for History and New Media, "Our Story," George Mason University, accessed July 14, 2026, https://rrchnm.org/our-story/ ↩︎

2. Wikipedia, "Roy Rosenzweig," accessed July 14, 2026, https://en.wikipedia.org/wiki/Roy_Rosenzweig ↩︎

3. Roy Rosenzweig, "Scarcity or Abundance? Preserving the Past in a Digital Era," American Historical Review 108, no. 3 (June 2003): 735–762, https://rrchnm.org/essays/scarcity-or-abundance-preserving-the-past-in-a-digital-era/ ↩︎

4. Zotero, "About," Corporation for Digital Scholarship, accessed July 14, 2026, https://www.zotero.org/about/ ↩︎

5. Tropy, homepage, accessed July 14, 2026, https://tropy.org/ ↩︎

6. Omeka, "Project," Digital Scholar, accessed July 14, 2026, https://omeka.org/about/project/ ↩︎

7. PressForward, homepage, accessed July 14, 2026, https://pressforward.org/ ↩︎

8. Roy Rosenzweig Center for History and New Media, "RRCHNM: Past, Present, and Future," accessed July 14, 2026, https://rrchnm.org/about-rrchnm/rrchnm-past-present-and-future/ ↩︎

9. Zotero, "About," Corporation for Digital Scholarship, accessed July 14, 2026, https://www.zotero.org/about/ ↩︎

10. Wikipedia, "Zotero," accessed July 14, 2026, https://en.wikipedia.org/wiki/Zotero ↩︎

11. Zotero, "Citation Styles," Zotero Documentation, accessed July 14, 2026, https://www.zotero.org/support/styles ↩︎

12. Tropy, homepage, accessed July 14, 2026, https://tropy.org/ ↩︎

13. Tropy, homepage, accessed July 14, 2026, https://tropy.org/ ↩︎

14. Daniel van Strien, "An Introduction to Version Control Using GitHub Desktop," The Programming Historian, June 17, 2016 (retired lesson), https://programminghistorian.org/en/lessons/retired/getting-started-with-github-desktop ↩︎

15. OpenRefine, homepage, accessed July 14, 2026, https://openrefine.org/ ↩︎

16. Voyant Tools, "About," Stéfan Sinclair and Geoffrey Rockwell, accessed July 14, 2026, https://voyant-tools.org/docs/tutorial-about.html ↩︎

17. Geoffrey Rockwell and Stéfan Sinclair, Hermeneutica: Computer-Assisted Interpretation in the Humanities (Cambridge, MA: MIT Press, 2016), https://mitpress.mit.edu/books/hermeneutica ↩︎

18. Laurence Anthony, "AntConc," Laurence Anthony's Website, accessed July 14, 2026, https://www.laurenceanthony.net/software/antconc/ ↩︎

19. QGIS, homepage, QGIS.org, accessed July 14, 2026, https://qgis.org/ ↩︎

20. Gephi, homepage, accessed July 14, 2026, https://gephi.org/ ↩︎

21. Humanities + Design, "Palladio," Stanford University, accessed July 14, 2026, https://hdlab.stanford.edu/palladio/ ↩︎

22. Recogito, homepage, Pelagios Commons, accessed July 14, 2026, https://recogito.pelagios.org/ ↩︎

23. Transkribus, homepage, READ-COOP SCE, accessed July 14, 2026, https://www.transkribus.org/ ↩︎

24. Knight Lab, "About," Northwestern University, accessed July 14, 2026, https://knightlab.northwestern.edu/about/ ↩︎

25. Knight Lab, "TimelineJS," Northwestern University, accessed July 14, 2026, https://timeline.knightlab.com/ ↩︎

26. Knight Lab, "StoryMapJS," Northwestern University, accessed July 14, 2026, https://storymap.knightlab.com/ ↩︎

27. Knight Lab, "JuxtaposeJS," Northwestern University, accessed July 14, 2026, https://juxtapose.knightlab.com/ ↩︎

28. Knight Lab, "SoundCite," Northwestern University, accessed July 14, 2026, https://soundcite.knightlab.com/ ↩︎

29. Roy Rosenzweig Center for History and New Media, "Our People," accessed July 14, 2026, https://rrchnm.org/our-people/ and George Mason University Department of History and Art History, "Lincoln Mullen," accessed July 14, 2026, https://historyarthistory.gmu.edu/people/lmullen ↩︎

30. Lincoln A. Mullen, The Chance of Salvation: A History of Conversion in America (Cambridge, MA: Harvard University Press, 2017), https://www.hup.harvard.edu/books/9780674975620 ↩︎

31. Lincoln A. Mullen, America's Public Bible: A Commentary (Stanford, CA: Stanford University Press, 2023), https://americaspublicbible.supdigital.org/ ↩︎

32. Lincoln Mullen, "textreuse: Detect Text Reuse and Document Similarity," rOpenSci, accessed July 14, 2026, https://docs.ropensci.org/textreuse/ ↩︎

33. Lincoln Mullen, "USAboundaries: Historical and Contemporary Boundaries of the United States of America," accessed July 14, 2026, https://lincolnmullen.com/software/usaboundaries/ ↩︎

34. Lincoln A. Mullen, Computational Historical Thinking: With Applications in R (open web book, 2018–), accessed July 14, 2026, https://dh-r.lincolnmullen.com/introduction.html ↩︎

35. Lincoln Mullen, "Isn't It Obvious?," lincolnmullen.com, January 10, 2018, https://lincolnmullen.com/blog/isnt-it-obvious/ ↩︎

36. The Programming Historian, "About," accessed July 14, 2026, https://programminghistorian.org/en/about ↩︎

37. The Programming Historian, "About," accessed July 14, 2026, https://programminghistorian.org/en/about ↩︎

38. Omeka, "Project," Digital Scholar, accessed July 14, 2026, https://omeka.org/about/project/ ↩︎

39. Omeka, "Project," Digital Scholar, accessed July 14, 2026, https://omeka.org/about/project/ ↩︎ ↩︎

40. Alliance for Networking Visual Culture, "About Scalar," University of Southern California, accessed July 14, 2026, https://scalar.me/anvc/ ↩︎

41. PressForward, homepage, accessed July 14, 2026, https://pressforward.org/ ↩︎

42. Zenodo, "About," CERN and OpenAIRE, accessed July 14, 2026, https://about.zenodo.org/ ↩︎

43. Harvard Dataverse, homepage, accessed July 14, 2026, https://dataverse.harvard.edu/ ↩︎

44. Knowledge Commons, "Funding," About Knowledge Commons, accessed July 14, 2026, https://about.hcommons.org/about-us/funding/ ↩︎

45. MLA Commons, "Introduction to CORE," Help and Support, accessed July 14, 2026, https://support.mla.hcommons.org/getting-started/core/ and Knowledge Commons, "What Is a Repository For?," About Knowledge Commons, September 26, 2023, https://about.hcommons.org/2023/09/26/what-is-a-repository-for/ ↩︎

46. MLA Commons, "Introduction to CORE," Help and Support, accessed July 14, 2026, https://support.mla.hcommons.org/getting-started/core/ ↩︎