Civil War Washington: An Experiment in Freedom, Integration, and Constraint
Delivered at the Annual Conference of the Alliance of Digital Humanities Organizations, June 2011
Brett Barney, Elizabeth Lorang, Kenneth M. Price
We proposed this paper not with the idea of doing a show-and-tell but rather with the hope that we could use our experience of doing the project to invite reflection on the terms in our subtitle—freedom, integration, and constraint—since they transcend our particular area of research and the hardware and software systems that we are using to conduct it. We mention this because we are going to spend some time describing the particulars of our project, but we'll confine ourselves to those bits of information that serve to ground the consideration of the more general issues.
The impetus for the Civil War Washington project goes back to 2005, when Ken Price, one of the co-editors of the Walt Whitman Archive, began to wonder if the emerging interest in place-based digital research could suggest productive angles for work on Whitman. Although we could have concentrated on any of the three major cities in which Whitman lived, and although we considered treating all of the dozens of places Whitman visited or mentioned, focusing on Washington, DC made particular sense. Whitman left behind a voluminous amount of material rooted in that place, from published work to notebooks to personal correspondence to the thousands of recently identified documents he produced as a clerk in the Attorney General's office. Yet, curiously, the importance of Washington to Whitman's writings had been largely overlooked by scholars. We also considered that a focus on Washington would reinforce work on the Whitman Archive, which had already started editing Whitman's Civil War materials, most of which were generated in DC. Important as well, Whitman's time in Washington overlapped with that of Abraham Lincoln, and their paths sometimes crossed as they navigated the city streets. As it happens, Kenneth Winkle, a historian on the faculty at UNL, is an accomplished Abraham Lincoln scholar with an interest in community-based studies and the use of statistical data in historical analysis. For these various reasons, then, we concluded that concentrating on the physical spaces Lincoln and Whitman inhabited had the makings of a collaborative digital project, one that stood a good chance of generating useful scholarship. We also felt emboldened by the support of Nebraska's Center for Digital Research in the Humanities, which provided a conducive environment for experimentation.
Over the next months, the aims of our work came into greater focus, as the evolution of the project's working title illustrates. In October of 2006, the project was "Lincoln and Whitman in Washington DC," and by February 2007 had become "Abraham Lincoln, Walt Whitman, and Washington, DC during the Civil War." A few months later in August, we were calling it "Civil War Washington: Studies in Transformation." We ultimately abandoned the phrase "studies in transformation" because we are just as interested in important continuities in the city as we are in the dramatic changes. Our current—and we hope final!—title is the most ambitious of them all: simply, Civil War Washington. On the one hand, these changes represent a temporal narrowing, from all of the years that Lincoln and Whitman spent in the city to just the four years of the war. At the same time, the project expanded thematically as we widened the spotlight from two individuals to the city itself.
Among the factors that drove this development were the processes of data-gathering, data-storage, and data-structuring. As we brainstormed the particular sorts of materials and information we wanted to collect, designed the data models that we imagined we would need, and then began researching and collecting information, it became increasingly clear that, in fact, our real interest was in pursuing a bottom-up approach to history and culture, rather than the top-down, "great men" approach that a focus on Lincoln and Whitman implied. The data and materials we were assembling might tell us something interesting about those two important figures, but they would much more certainly illuminate life in the city, and the life of the city. Granting the impossibility of documenting all aspects of life in the city, we nonetheless intend to fail honorably in trying to do justice to the full range of experiences in the war-time capital. We also want to develop a site that is more than a compilation of documents: We want to create our own interpretations and enable others to develop interpretations of their own, including interpretations potentially in conflict with ours.
With this shift in our sense of the project's nature, the amount of relevant information that we might conceivably include increased—in fact, it exploded. We are spending as much time, if not more, with data about ordinary citizens and soldiers, drawn from such sources as census records, criminal cases, and records of bawdy houses, as we are with data related to famous politicians, doctors, or writers. This year, for example, much of our focus has been on the 1,000 petitions filed by DC slaveholders, who under the Compensated Emancipation Act of 1862 were allowed to seek remuneration for those they were required to free. These legal documents, now located in the U.S. National Archives, include the name, age, and description of every slave freed, along with additional, sometimes lengthy, documentation of both their personal and family histories. This material is of importance because establishing details of nineteenth-century African American lives is extraordinarily difficult. In this case we have an opportunity to reconstruct a remarkably vivid portrait of an entire community of people at the moment of transition from slavery to freedom.
As this example highlights, expanding our scope beyond Lincoln and Whitman was liberating, but it has also brought sobering challenges. These challenges are related to infrastructure, integration, and communication, as well as to concerns we have about freedom and constraint. Our project's concerns regarding these key issues have both actual and metaphorical connections to the substantial changes and challenges that confronted Washington during the course of the war. We find ourselves discussing our project, and our work on the project, with many of the same terms that surround discussion of Civil War Washington, including freedom, integration, and infrastructure, so we are using these terms as a rhetorical thread. Our use of the term "integration" as it relates to Washington, DC during the Civil War is not intended to suggest the civil rights movements of the twentieth century. Nor do we intend to imply that the challenges the Civil War Washington project faces with regard to software or anything else are on par with the challenges faced by African Americans in DC before, during, and after the war, with regard to freedom and integration.
During the course of the Civil War, Washington DC required a new infrastructure, layered on top of Pierre Charles L'Enfant's initial plans for the city streets, public spaces, and buildings. The city went from being barely defended to being the most fortified city in the world. It attracted a new and flourishing theatrical life and an equally flourishing trade in prostitution. Washington also became a city of hospitals—it went from having one to more than a hundred as all manner of places, including a blacksmith shop, were converted into hospitals. In addition, the city's population more than tripled in four years, as thirty thousand fugitive slaves and thousands of others—bureaucrats, actors, authors, nurses, and laborers, among them—were drawn to the capital. This huge influx of people requiring residences, transportation, and waste disposal necessitated the creation of new infrastructure. Likewise, the Civil War Washington project has faced pressures that are at least metaphorically similar as we have strived to build a system adequate to house, move, sustain, and clean up after data rather than people. (We hope, however, that our own efforts are not so primitive as Washington's, which relied chiefly on pigs for garbage removal and a putrid canal for a sewer system.) On a certain level, constructing roads, buildings, and legal codes is akin to designing data structures, enabling data integration, and writing documentation. And on a more fundamental level, the infrastructural changes in Washington, DC one hundred and fifty years ago constitute part of the very data that we are now, in the twenty-first century, building frameworks to accommodate.
One key part of our own infrastructure is a MySQL database to record people, places, events, organizations, documents, and the relationships among them. For example, in addition to basic information about Willard Bliss, chief surgeon at Armory Square Hospital, we can add one or more relationships to other people in the database, such as the soldiers on whom Bliss operated, as well as other people Bliss knew, including Walt Whitman and Abraham Lincoln. We can also create relationships to places, documents, organizations, and events, linking Bliss to Armory Square Hospital and to issues of the Armory Square Hospital Gazette, a newspaper published within the hospital on a printing press he owned. Bliss's record also will include information about sources on which we base the claims encoded in the database. We will be able to record these types of relationships for every person, place, and so on, and the number of entries will continue to grow as we bring in more census information and individuals from the Compensated Emancipation petitions. In cases where we have digital surrogates of documents, the database will link to these. All places, including Armory Square Hospital, will be given a location ID, which should in turn point to the project GIS. (We'll say more about the GIS a little later.) Currently, the database is internal to the project, but in the near future we will be developing a public front end, which will be integrated into our website.
Developing the database has been an iterative process. In undertaking a project like this one, you cannot know from the beginning everything that you need to know or will want to study. Such is the nature of humanities research, as is the fact that what you regard as important can change significantly over time. It is important to acknowledge this process of technical development as part of the research. In the case of both the Whitman Archive and Civil War Washington, we have had need for significantly revised project databases over the last several years. The Whitman Archive used the same manuscript tracking database for more than a decade. In that time, the purview of the Archive expanded to include materials and representations of materials that could not be recorded in the original database, even with the most ingenious of hacks. The more we knew about our materials, the more we imagined what a more robust database would let us say and record about them. Just as important, when we started working on a new project database, having to think about how we would describe the objects in the database made us think about the objects themselves differently. Similarly, having to revise the Civil War Washington database required us to revisit previous assumptions, and it highlighted for all members of the project—some of whom had not before had to think in technical terms—that the technical is not separate from the intellectual. We might not have gotten the database "right" this time, either, but not for lack of careful and sustained thinking and experimentation.
A project GIS constitutes another important component of the site infrastructure. The importance of maps, mapping, and cartography in the Civil War are exemplified by the short story "George Thurston," by Ambrose Bierce, himself a mapmaker in the Union Army. The cartographer-narrator of the story describes map-making as "a business in which the lives of men counted as nothing against the chance of defining a road or sketching a bridge. Whole squadrons of cavalry escort had sometimes to be sent thundering against a powerful infantry outpost in order that the brief time between the charge and the inevitable retreat might be utilized in sounding a ford or determining the point of intersection of two roads."(1) Bierce's literary representation of the importance of maps in the war effort, and the cost at which they were produced, suggests another analogy for our work on Civil War Washington. At the outset of the project, we imagined that a map would be the point of entry for users of the website, would provide access to all of the related data, texts, and images, and would let users perform sophisticated queries to study, among other possible topics, the relationship of geographic features and the built environment. Developing the project GIS has sometimes felt a bit like sending out "whole squadrons of cavalry" in order to see progress figuratively as small as Bierce's "point of intersection of two roads." Yet, as the Civil War armies knew, even a single point could have dramatic impact. Without a doubt, however, building the project GIS has had its share of frustrations because the most robust software and the most open software are not one-and-the-same; because the most robust software carries a number of other limitations; and because even when using the best product for our research purposes, we're not able to do everything we would like to do.
We are using ArcGIS desktop applications to create the materials, and we plan to publish these materials on our website using ArcGIS Server. ArcGIS made sense from a functional perspective, since we were interested in utilizing the more analytical tools full-fledged GIS software can offer. This choice, however, has raised some serious issues and required some compromise. ArcGIS can be expensive and both the software and the file format, the shapefile, are proprietary. Other GIS software can work with shapefiles, but longterm preservation of shapefiles could be an issue. In addition, both the desktop and server applications are Windows-based. The desktop software does not run natively on either Mac OS or Linux, and ArcGIS server requires a Windows server.
As a project and in the CDRH, as in the digital humanities community more broadly, we value openness—openness in information, exchange, and software. To our knowledge, however, no existing, open alternatives would allow us to do the work we imagine, largely because ArcGIS has been decades in development. Although many projects use Google's KML-based approach, applications built on the Google Maps and Earth APIs do not allow for the more complex analysis that ArcGIS enables. Interestingly, directors of two prominent mapping projects gave talks at UNL recently, and despite the fact that both projects deliver content via Google Maps or Google Earth frameworks, they relied on screenshots of maps created in ArcGIS in their presentations. In our own project, we had good reasons for choosing ESRI products, but we remain conflicted about this choice. To help alleviate our anxiety—and to allow others to use our data in ways that interest them—we will make our files available for download as shapefiles and as KML. This decision does not, however, quell larger concerns we have about choosing a tool that is not available to everyone.
Even in choosing the most advanced software, we still find that we're not able to do everything we would like to do. No doubt some of the problem is the steep learning curve associated with ArcGIS. Various resource constraints—computing, financial, time, expertise—play a role as well. As primary functionality, we want our users to be able to view historical maps overlayed with data, and to toggle between layers, as well as query the data—all features that have become pretty standard at this point and are certainly doable. But we also want to allow users to perform some more sophisticated GIS analysis in the browser. For example, users may want to know how many hospitals were within a certain distance of a water source or railroad. Or they might want to create perimeters around features to look for points of intersection. And users almost certainly will think of questions to ask of the data that we have not imagined. We want to allow users the ability to manipulate the attribute data in the GIS to ask some of their own questions, and to be able to see the results of their queries on the map. Recently, however, we have been rethinking what we can realistically do in the browser, given current constraints of software and other resources. Rather than having the more sophisticated data manipulation, such as overlay and buffering, take place in the browser, we will probably need to create some static maps that facilitate our interpretation and make our files available so that users can perform their own manipulation in desktop applications. We might then consider allowing users to contribute their maps and accompanying analyses to the site.
In the emerging area of geospatial analysis in the humanities, GIS approaches and software have been the subject of criticism because of their apparent rigidity, which can make them seem ill-equipped to deal with more nebulous and inexact humanities data. Certainly, practitioners in the humanities must be both responsible and creative when using these tools developed for military, government, and social science purposes. We wonder whether humanists, digital or otherwise, need to participate in the open source GIS community and in the development of open, fully-developed GIS software to create or modify tools and approaches that seem better suited to the kinds of materials with which we deal. Here we're thinking beyond virtual maps and virtual globes. Whether or not humanists become involved in the development of these tools, the rhetorical framing of GIS in the humanities is something to consider. In a humanities GIS, we do not get answers; we have a methodology for thinking differently about our objects of study. We should embrace, as we do with other research methodologies, that a humanities GIS is embedded with assumptions and is interpretive. Further, in the words of historical GIS scholar Ian Gregory, "just because it's good graphics, don't think it's necessarily good history or good humanities scholarship."(2) Good scholarship will be transparent about the sources of data, potential error, projections, and so on. Again, GIS does not offer explanations but is a tool in the research process. In our view, Civil War Washington should not appear to be a neatly packaged, unambiguous, and static product. We do not want to create the illusion that we are presenting a "true" version of Washington, DC during the Civil War. Even as we amass an ever-increasing number of facts, we should be at pains to highlight the fictive connecting tissue and interpretive nature of our work.
We've spent most of our time today talking about just two of the site's key components because they have posed especially thorny and illustrative problems, but besides the MySQL and GIS data, we are also generating hundreds of TEI/XML files to represent primary and secondary texts, gathering a large number of photographic and other images, and compiling sets of statistical data. For the sake of time, we aren't discussing these other features in detail today, but we would be happy to field questions about them during the Q&A. The integration of all of these types and formats of information has been the source of much rumination, anxiety, and effort. Part of what makes this problem so perplexing for our project is that it is not, in reality, a single issue but a tangle of several interrelated concerns. What internal mechanisms can effectively and efficiently manage and navigate the network of connections between all of our datasets—connections without which our goals for the site will be greatly compromised? And what technology or combination of technologies is most likely to allow us to query, aggregate and present all of the data in the sophisticated and flexible ways we have envisioned? What kinds of site design will allow us to avoid compromising that sophistication and flexibility for the sake of ease-of-use?
