Civil War Washington

The Civil War Washington project team at the University of Nebraska–Lincoln includes scholars, librarians, technologists, and students, both undergraduate and graduate. Individuals are affiliated with the English and History Departments, the University Libraries, the School of Geography, and the Center for Digital Research in the Humanities. Our successes as a team can be attributed to many things, including sound project management and the fact that our participants have been committed to achieving set goals. Most important, the interdisciplinary nature of the team has been highly advantageous in the research itself and in creating the composite web site.

The project was started with seed monies from the University of Nebraska–Lincoln Libraries, which provided a Council of Library and Information Resources Postdoctoral Fellow in Scholarly Communication to serve as the first project manager, the Office of the Vice Chancellor for Research provided early grant funding, and the Center for Digital Research in the Humanities funded the GIS staff. With this initial funding package, a prototype of the web site was built, and a grant proposal was submitted to the National Endowment for the Humanities Office of Research for a Collaborative Research grant. The resulting NEH award was received in 2010. Throughout, servers, equipment, software, space, and administrative support have been provided by the Center for Digital Research in the Humanities.

This essay reflects upon the team and its resources, some of the challenges of archival research, and decisions made regarding the metadata for text and images, fields and functionality of the relational database, and site functionality and design.

Research Process

In "Accidentally Found on Purpose: Information-Seeking Behavior of Historians in Archives," Wendy M. Duff and Catherine A. Johnson interviewed ten historians to identify information-seeking practices.1 The study revealed four research practices common among historians performing archival work: orienting oneself to archives, collections, and finding aids or other sources; looking for specific known items; developing a broad knowledge of the context of the period; and identifying relevant materials. The information-seeking behavior of Civil War Washington's research team—composed of faculty, staff, and students—seems to confirm the findings of Duff and Johnson, with the added advantage of group discussion and information-sharing among those with broad contextual knowledge and knowledge of specific resources. To aid others making decisions concerning digital resources, we offer background information on our methods of research, on our decision making about appropriate technologies, and on the process of combining these.

The development of Civil War Washington has been based on discussion, research, trial and retrial of technologies, and more discussion. Through group processes, people have brought their particular knowledge and skills to bear on the research questions until a sense of satisfaction in the expression of our research through technologies has been reached. Without question, the journey has been as important as the destination. One such journey has been the development of the interactive map, described in detail in Rob Shepard's essay. In that process, one of the issues concerned translation of street addresses from one system to another in order to accurately chart locations. This was aided by city directories. Boyd's Washington and Georgetown Directory, in particular, helped us to locate businesses, churches, police stations, theaters, and specific residences. Maps and resources concerning forts and batteries ringing the cities of Washington and Georgetown have also been invaluable.

Civil War Washington team members have conducted archival and library research in many repositories, as apparent from citations on the web site. These repositories range from large government agencies, such as the Library of Congress, the National Archives & Records Administration, and the Smithsonian, to smaller private historical societies, such as the Historical Society of Washington DC and the Civil War Veterans Museum and G.A.R. Hall in Nebraska City. Online resources have been used as well, such as census data of 1860, the Internet Archive PDFs of the Medical and Surgical History of the War of the Rebellion, and the Chicago Center for Population Economics databases.

Of the archival repositories consulted, the National Archives & Records Administration has offered the greatest range of materials. For example, thanks to NARA's long-standing microfilming program and the ever-expanding Archival Research Catalog (ARC), team members were able to locate microforms of slave petitions dating back to the Compensated Emancipation Act in the District. The petitions are found in the "Records of the Board of Commissioners for the Emancipation of Slaves in DC." These microfilmed records revealed 1,127 petitions of slave owners with remarkable descriptions of how a slave was acquired or inherited, physical description and age, wages received by hiring out slaves, the types of work that slaves did, and family relationships among slaves.2 We found the location of the records somewhat startling. The records are in Records Group 217.6.5, Records of the Accounting Officers of the Department of the Treasury, 1775–1927, and are part of the Settled Treasury Accounts series. Hence "accounting" takes precedence over "emancipation." At http://arcweb.archives.gov, these can be found as ARC identifier 464416 / MLR number A1 347.

Following the DC Compensated Emancipation Act of April 1862, a supplemental act was issued in July 1862 that enabled slaves in DC to petition for their freedom if their owners had not applied for compensation under the initial act. The petitions filed under the July act are held with the Records of the District Courts of the United States, 1685–2004, in Record Group 21. Within ARC, these petitions are cataloged by ARC Identifier 4314547 / MLR Number NC-2 33. Yet evidence pertaining to these petitions filed by former slaves is grouped with the petitions filed in response to the April act. These evidentiary materials, like the April act petitions, are held at the National Archives in Record Group 217.6.5, Records of the Accounting Officers of the Department of the Treasury, 1775–1927. The fact that these materials reside in two different record groups is significant, because initially team members believed the evidentiary materials housed with the April act petitions were the petitions of the former slaves. Only some serendipitous searching of ARC returned the second batch of materials, housed in the District Court records, and careful research elucidated the connection between the materials located in both record groups.

Descriptions of materials that have not been microfilmed or digitized but are in ARC may be sketchy or present significant issues of authority control. In part, the limitations of ARC relate to the limitations of finding aids or indexes that may date back to the nineteenth and early twentieth centuries. Standards for finding aids and cataloging have changed considerably through the years, and in some respects local practices have strongly determined the way in which resources are described and made accessible.3 In some cases, we found it necessary to actually have a citation in hand in order to locate specific information. For example, the project team was interested in researching prostitution in Washington during the Civil War. A search of ARC might rely on terms such as "bawdy houses," "prostitution and civil war," "houses of prostitution," "prostitutes and civil war," or other terms along these lines. The records that proved most pertinent to our research were actually in Record Group 393, Provost Marshal, Department of Washington, 22nd Army Corps, 1864–1865. The ARC record for this record group does not refer to houses of prostitution in association with the items in this group, and yet it contains a ledger with detailed information on addresses, names of madams, and ratings of such houses based on quality and cleanliness. The ledger books kept by the Provost Marshal noted where various services were located in the city. Hence blacksmith shops and bawdy houses are among services listed. If the project team had not already had a citation to this particular record group from other scholarship, research in ARC almost certainly would not have returned the most relevant result for our research.

Civil War Washington also presents cases of (primarily) soldiers treated in hospitals in Washington. We reproduce the text of these cases from the Medical and Surgical History of the War of Rebellion, a six-volume set. Here the project team began with text of the cases as derived via optical character recognition and made available at the Internet Archive. As part of our research into the patients and hospitals described in the cases, we also consulted the University of Chicago's Center for Population Economics (CPE) database. An unexpected problem here was that twentieth-century health privacy concerns regarding medicine and treatment of patients had been applied to nineteenth-century Civil War soldiers, and names were omitted from the CPE records. The team was ultimately able to circumvent this problem through negotiation with the CPE. As with the emancipation petitions, the National Archives has proven to be an indispensable source, in this case for researching medicine in Washington. In particular, National Archives Manuscript Record Group 94 contains a "list of general and post hospitals in Washington and Georgetown DC giving location" as well as other relevant information. Members of the project team identified this item through the Archival Resource Catalog at NARA.

Technologies and Metadata

Civil War Washington technologies, to the extent possible, are based on open source standards. Such technologies range from the Text Encoding Initiative (TEI) P5 metadata to MySQL, an open source relational database management system presented in a web interface using the webscripting language PHP. Underlying foundational server software is based on Cocoon and Apache Tomcat. The map alone is rendered in proprietary software using various ESRI products, particularly ArcGIS. At the time of development, no existing, open alternatives would allow us to do the work we imagined, largely because ArcGIS has been decades in development. Although many digital humanities mapping 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. Although we had good reasons for choosing ESRI products, the decision was not a simple one. To help alleviate our anxiety—and to allow others to use our data in ways that interest them—we 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 and publication framework for the map that is not available to everyone.

We have used the Text Encoding Initiative Consortium's TEI P5 guidelines for encoding the variety of textual materials presented on Civil War Washington. This TEI encoding provides provenance information for both the original documents and the digital surrogates, along with administrative details, and it ultimately enables rich queries of the texts on the project web site. The TEI P5 documents are rendered in eXtensible Markup Language (XML), allowing the greatest measure of interchange and consistent online presentation. In addition to bibliographic and administrative information, the project team has encoded a variety of features within documents, although the specific treatments of the texts vary according to the type of document being transcribed and described (e.g., whether a petition, a medical case, or a hospital newspaper). Our encoding practices for emancipation petitions, for example, differentiate between handwritten and preprinted form content; identify all instances of personal and place-names; mark every instance of a date with an ISO-standard format; and represent the structure of the document, including page breaks and textual divisions and sections. Our TEI markup for the medical cases encodes all instances of personal, place, and organizational names; renders all dates in an ISO-standard format (while also transcribing the date as it actually appears in the text); and provides keywords descriptive of diseases and injuries, based in part on the taxonomy established in the Medical and Surgical History of the War of the Rebellion. In the case of hospital newspapers presented on the site, the TEI markup is very limited, because we have not been able to transcribe the entirety of the newspaper issues. Instead, the TEI document provides information about the original document and represents the basic structure of the newspaper issue (represented by page breaks), which point to digital facsimiles of the newspaper's pages.

Civil War Washington exposes TEI metadata for all TEI documents published on the site, and users are encouraged to view, download, and extend the TEI markup for their own projects, so long as they credit Civil War Washington and distribute their own research products under similar terms. Civil War Washington is made available under a Creative Commons License—Attribution, Non-commercial Use, and ShareALike. We chose this license, after much discussion, to ensure that users could have as much access as possible to our research efforts.

Civil War Washington Relational Database

Development of the first iteration of the Civil War Washington relational database began in 2006, when the larger project itself was in its germinal stage. The initial emphasis on two key figures, Abraham Lincoln and Walt Whitman, guided the development of the database. In addition, the development of the database was a crash course in database design for members of the project team, who wanted to understand the underlying technologies. Finally, this first version of the database was largely a theoretical model. Each of these qualities—the relatively limited scope of the kinds of data to be stored, the pedagogical nature of the development process, and the notion of moving from a theoretical model to real-world application— had significant effects on the end product.

During this first phase of development, the project team had very little actual data to store in the database, so the database emerged out of discussion of what the system should be able to store and do. The team imagined recording data about a relatively small subset of places—theaters, hospitals, and churches— all of which promised to have interesting intersections with Whitman or Lincoln or were otherwise vital to the changing city of the war years. The intense focus on these three types of places reflected the fact that this first iteration of the database was, conceptually, about place. The project team therefore developed a model that could accommodate very fine-grained data about each of these types of places, such as the number of beds in a hospital, the size of a church's congregation, and, in the case of theaters, information about individual performances. In addition, the theoretical model that emerged during phase one attempted to make room seemingly for all possible relationships—for example, information about congregations in churches that later became hospitals where doctors worked on patients who were soldiers in military organizations—and individual tables grew exponentially in size as a result. Ultimately, the combination of having only a small amount of data in hand along with extensive plans for imagined, ungathered data did not allow us to formulate a sound, normalized database. In a properly normalized database, each of the tables of data would have only the minimal fields necessary to describe a unique entity, and unnecessary redundancies are eliminated, making it easier to manage and update the data.

During this stage of development, the project team also grappled with a series of theoretical and methodological issues that had direct bearing on the database design. On a most fundamental level, for example, team members had to define what combination of qualities or attributes constituted "a place." In addition, the team had to deal with representing unknown and fuzzy or disputed dates in a computational system that inherently does not do well with representing uncertainty. Again, these issues were intertwined with what the team believed to be the research questions of the project; in fact, they became part of the research questions of the project. As research, there were some false starts, and the team's understanding of how best to handle such features from a computational perspective, as well as from the perspective of scholars grounded in literary and historical studies, evolved over time. As a case in point, attempting to define one date for a place proved almost impossible. Allowing for a beginning date and an ending date was easy enough both conceptually and practically, but the issues of unknown dates and fuzzy dates—pervasive across primary and secondary source documentation—were more difficult to resolve.

The project's response to these issues was twofold. First, we developed the notion of a "war boundary" date as a mechanism for dealing with unknown or uncertain dates. If the founding date of a theater was unknown, but the team knew the theater existed during the war, that basic information— that it existed in Washington during the war—seemed comprehensive enough for the project's goals and areas of study; a set of generic beginning and ending dates, what we defined as a "war boundary" parameter, which merely identified a place as existing during the Civil War, would work for the project. This decision underscored certain assumptions: the project was not concerned with the history of a specific theater, including its possible founding decades before the war or its operation into the twentieth century, except to the extent that the theater existed in Washington during the war. Unknown dates and approximate dates could simply be limited to the project-defined war boundary dates.

Second, for each beginning date and each starting date, we actually recorded two date values (four date values total): beginning date start, beginning date end, ending date start, and ending date end. This approach allowed us to represent, for example, that Amory Square General Hospital was established sometime in August 1862 (beginning date start value of 1862-08-01, and beginning date end value of 1862-08-30) and closed sometime in September 1865 (ending date start value of 1865-09-01, and ending date end value of 1865-09-30). Likewise, if we knew that a theater was established no later than April 10, 1863, because we had records of a performance held at the theater on that date, but we did not know the exact date of opening, we could take a combined approach: enter the project war boundary date (1860-11-01) for the beginning date start value and the performance date (1863-04-10) as the beginning date end value. Such a record would codify that the theater started operation no later than April 10, 1863, was active during the war years, and its beginning date was inconsequential for the project's purposes. The advantages of this approach were that it provided a means to deal with some uncertainty and, by limiting the scope of dates to those that mattered to the project's identified goals, preserved resources—especially research time—for more significant questions. Downsides of this approach, including the extent to which the "war boundary" designation might hamper future research both for Civil War Washington and other projects, and our nonstandard vocabulary of "beginning date start" and so on for dealing with uncertainty, ultimately trumped the advantages. In the second version of the database, therefore, we revised our handling of dates to reflect more standard practices, an eye toward the future of the project as well as its present, and a further refined argument about the data we were collecting.

In the fall of 2010, the project team began planning for version 2 of the database. Since the completion of version 1, and the population of the database with data from a variety of sources, several conceptual and practical problems with the database emerged. The most significant problems included the non-normalized database tables, an increasingly unworkable and unrealistic model of relationships among the data, the extreme differences in the level of detail to be accounted for the different entities, and the lack of a fully functional graphical interface for querying, editing, and viewing the data. The redesign of the database addressed these issues, and it also took into consideration the shifted emphasis of the project, which now sought to explore the broader theme of race, slavery, and emancipation in Washington during the war in the wake of NEH funding for this work. Guiding principles of database development during this phase included developing a solid database system that could accommodate the project's interests in the present and in the future, as well as be shared with other projects that may need a similar system; having the database model how we believed relationships work among entities in the real world (this principle countered the model of the previous database in which individual people could not be related to one another except through a shared relationship to a place or organization); creating a fully normalized database to meet best practices as well as to facilitate data management; and allowing the public to access and interact with the database for research and analysis, in addition to having the database serve as an internal mechanism for organizing project data.

In this second version of the database, the database model at once became simpler and more complex. The number of entities about which we proposed to track information increased to include people, places, events, organizations, and documents, and the number of potential relationships among entities exploded, as we proposed to allow many-to-many relationships among all entities. That is, a single person could be related to one or more people and to one or more places, while each of those other people and places also could be related to one or more people or places. Such a description of relationships among entities seems simple to human minds, as we know how relationships work in the real world (that any one person really does have multiple relationships with other people, who also have relationships with multiple other people, and the relationships may or may not overlap). Allowing for such many-to-many relationships in a database system, however, can immediately make a relatively straightforward model significantly more complex. While the database's complexity increased in this way, we simplified the number of fields available in any one table (such as for people or places) and made consistent the type and level of information to be gathered about the different entities to the extent possible. For each entity (people, places, events, organizations, and documents), we could record information about that entity's name or title, along with alternate names or titles and dates, whether life dates or dates of operation, and so on. For people records, we could also include demographic data not relevant to the other types of entities. And for events, organizations, places, and documents, we developed a taxonomy for identifying each record in further detail (what type of place, for example). The taxonomies differed across the entities (the categories available for describing places are different than those for describing documents), but we aimed for consistency in the level of description and the nature of the description. Where it was possible to use elements of one taxonomy in a second, we did so.

Version 2 of the database also provided an opportunity to reimagine our strategy for recording date information and to rethink our thinking about what date information to enter. To deal with uncertain or fuzzy dates, we preserved the requirement to record two values for a beginning date and two values for an ending date. We renamed the fields and shifted our understanding so that these four dates recorded the earliest possible beginning date and the latest possible beginning date for a place, for example, and likewise for ending dates. This approach allows us to represent in the data that the start date of a place was sometime between date 1 and date 2. If the values of date 1 and date 2 are the same, then we know with certainty that the place "began" on a specific day. Similarly, we can represent the earliest possible beginning date without doing extensive research, the concern of which in part had prompted the "war boundary" designation in version 1. For example, if we know that a theater that was in operation during the Civil War opened sometime in the 1850s, we could represent the beginning date as "not before January 1, 1850," and "not after December 31, 1859." The information is not as precise as it might be—such as finding the date of opening as precisely as possible—but it does not make the same claim as version 1 of the database, that the dates that matter are "war boundary" dates, and it does not preclude or discourage entering information as specifically as we can, if we have it. This shift in thinking, in the data model, and in the values recorded makes it more likely that Civil War Washington's data will be of use to other projects, and it also looks forward to a time when the project may itself be interested in years other than the immediate war period.

Despite changes in the scope of the project, collected data, and database models, some features of the database have remained consistent across versions. In particular, the fundamental technology for the database storage has remained consistent in all phases of development. We use MySQL primarily because of its flexibility and portability. Since MySQL is supported on a variety of system platforms and uses a structured query language (SQL) that is common to many other database formats, our data is usable not only in the current project but in future iterations as well. We can export data easily from MySQL for migration from server to server and for import into other database technologies if necessary, both of which are important factors for ensuring long-term access and the progression of the project. MySQL also supports spatial extensions, following the specifications of the Open Geospatial Consortium (OGC). The ability to store and perform some spatial functions in MySQL, even while we use different software for our full geographic information system, made MySQL an excellent storage system for the master data.

Similarly, we have relied on PHP throughout the database's development in order to create graphical user interfaces for the database front end, the place where project members, and now public users of the site, encounter and interact with the database records. For version one, we created a simple graphical user interface (GUI) to access the database. This GUI was intended to provide project staff a means to easily add and modify the existing MySQL data. The ability to search the database from the graphical front end was very limited, and there was no public view for the data, other than what we choose to render as part of the mapping component of the project. In its first iteration, the database was understood primarily as a mechanism for storing and organizing data internal to the project. In the GUI, then, records were presented in a fairly raw format resembling a spreadsheet. This approach proved extremely cumbersome for project staff, especially for working with the relational aspects of the data. Ultimately, usability issues with the graphical interface caused some staff members to abandon the GUI and to edit records through an administrative interface not intended for this purpose, a misunderstanding that caused some database records to become corrupt.

For the second phase of the database, then, we developed a new web interface that has a private view for the project team, with robust editing mechanisms in place, as well as a public view. We continued to use PHP for the public interface, but we relied on a PHP framework, CakePHP, which supports multiple views of the data, such as the public and private views, and can be customized based on user roles. The new interface provides an intuitive, well-developed means of finding and editing the data for project team members, and we are able to present site users with several options for accessing the data, including the ability to browse records in the major categories, perform simple keyword searches, and construct highly specific advanced searches using a graphical interface.

Indeed, these more developed searching capabilities are a major improvement of the second version of the database. As noted above, the capacity for searching in version 1 of the database was very limited from the graphical front end. Project team members with working knowledge of the structured query language (SQL) could construct queries executed on the command line, but most project members did not have the knowledge necessary to perform these kinds of searches. From the outset, then, a comprehensive search facilitated easily by a graphical interface was a priority for the project team. First, we developed a basic keyword search for both the public and administrative interfaces. This keyword search likely will meet the needs of the majority of Civil War Washington users, but an advanced search is also available for "power users" and members of the project team, who may wish to construct more fine-grained queries. We imagine that many users who come to Civil War Washington will be working on some form of genealogical research and would like to see records in the database that feature a certain family or individual name. The basic keyword search should provide these users with the information they need. Others, however, may want to limit their search to certain types of places or to individuals who meet certain demographic criteria. The advanced search enables users to construct such queries easily, as well as queries that limit the search to a specific beginning or ending date, among other options. In building the advanced search, the project team balanced consideration of its own known research questions with consideration of the types of questions that site users might want to ask. While developing a search form to meet the needs of every potential user and his or her queries is impossible, we have attempted to anticipate the most regular types of queries, and we hope to continue to develop the advanced search functionality and interface over time. We also plan to offer better matching through full-text searching with relevancy results. In addition, the data are available for download so that users with the requisite skills can construct their own queries on the command line or use other tools and perform their own analyses. Finally, we hope to combine all of the search strategies in place across the Civil War Washington site (database, GIS/mapping, searches of textual records), preferably under the umbrella of Apache Solr, a popular search server written in Java.

Despite these achievements with version 2 of the database, some challenges remain, and there are a variety of features and functionality we would like to see in a later version of the database. Synchronizing data between the relational database and the project GIS remains a pressing need. Because of the way our current GIS software accesses the data to create its visualizations and mappings, the GIS software needs certain data available in its local database. Finding the best means of getting the data from the master MySQL database ported to GIS and allowing for changes to the data to be made in the GIS and synced back to the relational database are ongoing. We want to store in the GIS the data that is best natively stored there and do likewise in the relational database. We want the data from one available to the other, without duplicating data. The duplication of data brings with it significant concerns for data management, as experiments with the first version of the project GIS and database demonstrated. On the content side of the database, one area for development is the creation of both more database records and more highly detailed records. Without these types of records, we will not be able to realize the power and flexibility of the database's design, interface, and search, thus limiting the full research potential of the database. As one way of developing these records, we have laid the groundwork for creating user accounts and an approval system for the database, so that the public will be able to add and edit records.

Web Site Design

The design process for the Civil War Washington web site also involved discussion and iteration by the entire team. There were months of discussion about content, desired features of the site, and navigation. Gradually the group fleshed out ideas and prioritized what should be accomplished in the first iteration of the web site. Due to time and technology restraints, a fairly limited version of the site was planned.

Once an inventory of content and a sense of the desired structure were achieved, wireframes were created to demonstrate the potential site structure and functionality. Wireframes are used in the web development profession to demonstrate bare bones navigation, hierarchy, functionality, and interaction of a site so that these elements can be discussed apart from the design aspects, such as colors, fonts, and images. Wireframes usually look like a web site skeleton, with only a layout and something like an outline represented. Often wireframes are built in an image editing program or a dedicated wireframe program. In the case of Civil War Washington, the wireframes were built using hypertext markup language (HTML) and cascading style sheets (CSS). This allowed the designer to start developing the HTML structure for the site and to test out a css framework (the 960 Grid System). This actually shortened the design process since, once the wireframes were approved, the html was already written. The wireframes consisted of a page for each first level navigation item, as well as extra pages demonstrating the controls for searching. The designer created a graphical representation (also known as a mind map) of the site structure so other members of the team could easily see and discuss the various paths a user might follow through the site. Once done, we met to discuss the graphical representation, and the wire-frames were uploaded to a URL for further study. At the next project meeting, the group discussed suggestions for improvements. After only a few discussions with feedback and recommendations for changes, the design work could really begin.

The first step in the design process was to develop a color scheme. Because of the subject matter, the group chose a color scheme of blue and gray. Early on, the group identified the unfinished photo of the U.S. Capitol building by Brady Studios (1860) as one setting the right tone for the web site's home page. From historical sources, the designer generated examples of possible fonts to use. Once the color scheme, fonts, and images were selected by the team, the designer worked up site sketches on paper, then in Photoshop, and finally in HTML and CSS. Completing the design in HTML and CSS allowed the designer to present the web site as it would look in various browsers right away, rather than using mockups for discussion. The 960 Grid System, which was retained, forced a strict, grid-based format to the design. Once the design was approved by the team, the designer also created the site in a simple PHP framework—a process made easier since the site was already in HTML. Finally, the designer and the programmer incorporated the database and the map into the framework.

Three years after the initial Civil War Washington launch, the same team worked on a redesign of the web site for a relaunch with many new features. The technology in the intervening three years had changed so much that the HTML could be streamlined and CSS3 elements for features such as drop shadows and embedded fonts could be employed. At the same time, the designer chose to drop the 960 Grid System css framework. While useful at the beginning of the project, it proved to be too easy to accidentally break the layout of the site, especially when others were editing the HTML. This was because the 960 CSS framework relied on very strict naming conventions that were hard to adhere to unless one understood how the framework behaved. Instead, descriptive classes on HTML elements were used to facilitate development, while the grid layout was retained.

In this second version of the web site, elements of the design remained largely consistent, although content was redistributed among several newly agreed upon categories on the home page that necessitated additional explanatory text on secondary pages. Moreover, the changes on the back end were quite substantial. To improve functionality and display, the designer rewrote the HTML for each page, rewrote the CSS, and redesigned several pages (including the home page) to incorporate new information more simply. Comments were added within the code files so others working on the site could more easily understand where to make changes when needed. One of the biggest changes between the first and second iterations of the site was the use of a CSS element @font-face, which was finally supported by all major browsers (including Firefox 3.5). This change allowed us to make considered typographical choices, instead of presenting text as an image or relying on fonts on the user's system. Due to licensing restrictions on fonts, we determined that the font had to be open source or come with a license that allowed embedding. There are many web sites devoted to providing open source fonts and many to choose from. Several CSS3 elements facilitated removing clunky graphical elements, including the ability to add drop shadows on boxes and text, and code that allowed for more precise positioning. The result was a web site with streamlined code and a fresh look.

In both the original design and the redesign, deciding what not to include involved some of the most difficult decisions. From the design perspective, one of the ideas cut was a mobile version of the site. Some sections of the site, such as the map and the data section, did not lend themselves to mobile design, and the team agreed that it was better to build a strong structure that could later be modified using css rather than build a mobile interface that was not completely functional. As mentioned in other essays, mapping the district was considered one of the most important aspects of the project (technical aspects of the map are covered in Rob Shepard's essay, "Historical Geography, GIS, and Civil War Washington"). To present the map poorly would be a disservice to the public and to scholars. The database, too, would be extremely difficult to present in a mobile application at this time.

Conclusion

Future directions come readily to mind. Due to the database design, there are currently two searches on the site—one for the data section and one for the texts—and a third search within the mapping application. While currently difficult to create, a combined search is desirable, and we hope in future versions of the site to develop one. The team has discussed other types of content to add, such as more images. Some may result in new categories on the home page, such as "realia" or images of physical objects.

While this essay has dealt primarily with collaborative work at Nebraska, the truth is that many other collaborations have resulted or are developing because of research, content, and technologies associated with Civil War Washington. Scholars from other universities or organizations serve as advisors and have also contributed to the site's development. E-mails with questions, comments, and offers of help or content have been received from the public and scholars alike. Our decision to develop a blog called "Dispatches from Civil War Washington" was partly in response to such interest and questions. The blog allows us to talk about both the research and changes to the web site. Nor is it unusual to receive ideas for new directions in research or publishing. Recently Anvil Academic's Built-Upon contacted the team and offered us an opportunity to participate in an open access endeavor. While we are unsure when the next proposal for collaboration will transpire, we know that it is sure to come. Digital scholarship is often an organic and iterative process. The scholarly interests now reflected on the site could easily change as new team members join or as new grant proposals are funded.

The Civil War Washington team has so far approached two research areas simultaneously—race, slavery, and emancipation and the history of medicine. The project's emancipation research benefited from generous research funding from the National Endowment for the Humanities. Through this grant, we were able to publish the petitions of slaves and of slave owners as well as redevelop the site's major infrastructure, among other work. The history of medicine component has been developed through more modest and eclectic means. John Unsworth, now at Brandeis University, describes this approach as "stone soup" after the children's book of that name. The medical cases recipe included internal grants, private donations, work study students, Undergraduate Research and Creative Arts Experience (UCARE) awards to students, and Center for Digital Research in the Humanities funding for the GIS graduate research assistant, the programmer, and the digital resources designer. Both of these funding approaches have been successful, and they make apparent that research questions may be determined in part by the resources available.

Finally, peer review of digital scholarship remains an unresolved conundrum. Federally funded grant proposals may be considered peer reviewed based upon scholarly panel review; however, this vetting occurs before the work is done, and academic departments and administration may not regard such review as peer review in the same way as traditional peer review for journal articles and monographs. Some federal agencies are requiring white papers at the end of the project—a type of reflective report available online to one's peers, which may function as a type of open peer review. This practice recognizes that the scholarly community can learn from the results of grant research—from both the successes and the failures. With federal funding increasingly more difficult to acquire as budgets shrink, however, there are no guarantees that highly ranked scholarship will be funded. Therefore, while grant funding in some instances may serve as a kind of de facto peer review, it is not a comprehensive solution. One challenge for the digital scholar may be to find scholar-to-scholar peer review options. Although some exist, it may be difficult to find reviewers who can meaningfully assess content, underlying standards, navigation, and design. Throughout academic institutions, researchers and administrators must be open to changing models of peer review.

Notes

This essay was first published in Civil War Washington: History, Place, and Digital Scholarship, ed. Susan C. Lawrence (Lincoln: University of Nebraska Press, 2015). It is reproduced with permission and has been revised and updated for publication here, as described in "Civil War Washington: The City and the Site." The copyright to this essay is held by the Board of Regents of the University of Nebraska, and Civil War Washington's Creative Commons license does not apply to it.

1. Library Quarterly 72 (2002): 472. [back]
2. Kenneth Winkle assesses the potential of the petitions for historical analysis in his essay "Mining the Compensated Emancipation Petitions." [back]
3. A useful article for those interested is "Authority Control at the National Archives and Records Administration" by Lydia J. E. Reid and C. Jerry Simmons in Journal of Archival Organization 5 (2007): 95–120. [back]