Category Archives: digital humanities

Digital Humanities, Digital Scholarship, and Digital Libraries: Fuzzy Boundaries of a False Trichotomy

alt-ac, digital humanities, libraries

If there is one thing that unites digital humanities practitioners, it is our aversion to defining ‘Digital Humanities.’ I get it. I really do. But defining and redefining DH on a regular and ongoing basis comes with the territory. Especially in today’s academic and GLAM sector 1 climate where digital tools and methods are being recognized as crucial components of workflow, access, and analysis.

Like politics, all DH is local. And depending on your local politics, you may find yourself needing to distinguish between the trifecta of Digital Humanities, Digital Scholarship, and Digital Libraries. These three terms usually live in happy, overlapping harmony with each other – until you have to tease them apart for administrative or funding purposes. Then things can get surprisingly complicated, surprisingly fast.

So, in an effort to ease this process, I propose the following interlinking definitions.

Digital Libraries consist of the human and cyber infrastructure required to build and maintain structured repositories of metadata and digital objects designed for access and reuse by researchers with an undelimited set of research questions. Digital libraries vary widely in size, content, and audience. But some examples include:

Digital Scholarship is the set of skills, methods, and tools required for researchers to work with digital materials, as well as the people who teach these skills. Skills that fall under Digital Scholarship include, but are hardly limited to:

  • Geographic Information Systems (GIS)
  • Proper use and application of statistical analysis (on textual, numerical, or image data)
  • Citation management (Zotero started as a DH project)
  • Data Curation and Data Management
  • Data visualization, physicalization, or sonification

Digital Humanities is a field of research and a labor structure. As a field of research, Digital Humanities is characterized by “using information technology to illuminate the human record, and bringing an understanding of the human record to bear on the development and use of information technology.” 2 As a labor structure, Digital Humanities is designed to maximize collaboration and, in the words of Ed Ayers, “scramble hierarchies” to the betterment of scholarship and the human experience. Digital Humanities practitioners use the skills and tools of digital scholarship and rely on (or create) the metadata and objects in digital libraries to answer their research questions.

Digital Humanities as a field is primarily characterized by Digital Humanities Projects.3

Digital Humanities Projects often have features in common with digital libraries, but DH projects are designed to answer a delimited set of research questions.

So, those are my suggested fuzzy boundaries for the false trichotomy of Digital Humanities, Digital Libraries, and Digital Scholarship. In the wild many organizations use one of these terms to stand for a host of activities that stretch across the taxonomy I have laid out above – The Digital Library Federation being the obvious example.

But sometimes you need just need a short, and not entirely misleading, definition. I hope these help.

_______________________________________________________

Has anyone seen a sheep?: Ada Lovelace Day Tribute to Deb Verhoeven

alt-ac, digital humanities

This Ada Lovelace Day I want to stop and thank a woman who is making the Digital Humanities Community a more just and scholarly place: Deb Verhoeven.

I have had the extraordinary privilege of working with and for many amazing women in DH.  In fact, I would consider my intellectual DH heritage to be distinctly (if not unusually) matrilineal.  These amazing women gave me the gift of their experience [Elli Mylonas], their wisdom [Julia Flanders], their diplomacy [Kay Walter], their technical skill [Bess Sadler], and their example [Bethany Nowviskie].

Deb gave me something else.  Deb gave me her anger.

When Deb stood on the stage at DH2015 and asked the crowd “Has Anyone Seen a Woman?” Something in me uncorked.

The first days of that conference had been stultifying for me.  It was my first real experience with the sexism so many others have felt in DH for so long.  I was sick of the double takes from colleagues (senior and junior) when they heard my title: Associate Director of the Center for Digital Humanities at Princeton (really? You?).  I was sick of being ignored by men while they talked over me and mansplained my areas of expertise (technical and administrative, even feminism).  I was sick of everything, including the community that had always felt like my intellectual home.

Then Deb took the stage and called for a reckoning.  She called out the “Parade of Patriarchs” that we had all witnessed the day before as white men, one after another, took the stage to start the conference.  She called out the systems we participate in that somehow always manage to privilege men over women.  And then she proposed a series of concrete solutions that male colleagues could and should take to ensure equity in the field.

And the crowd went wild.  As I jumped to my feet to applaud, so did so many of my fellow DHers – women AND men.  It was a big room, but I could clearly see Glen Worthey near the front on his feet cheering.  And I thought: Yes.  We can fix this.  The system is rigged, but WE CAN HACK IT.

I managed to introduce myself to Deb before I left Australia; we had a beer in a converted church.  I followed her on Twitter.  I friended her on Facebook.  I read her amazing theoretical work on databases [“Doing the Sheep Good“], which I cannot believe no one suggested to me while I was working on my dissertation.  And through Twitter, Facebook, and her scholarship I met a lot of sheep.

By the time I saw her a year later in London, it felt like we had known each other for much longer than a year.  We took a break and vented over coffee when things got too insane.  We attended the Diversity Track at DH2016 in Krakow (why a separate track, seriously?). She and my husband had great conversations over pierogi.  Basically, we had a blast.

And over the past year I have been finding my own voice as an activist as well as a diplomat.  It sounds different than Deb’s, but I hope it harmonizes.  And I am so pleased to be among a digitally connected diaspora of more amazing DH women: Roopika Risam, Amy Earhart, Padmini Ray Murray, Élika Ortega, Melissa Terras, and so many more.

So thank you, Deb.  Before I met you I was mad as hell.  But now, I won’t take it anymore.

Baking Gingerbread, as a DH project

digital humanities, Uncategorized

Earlier today I was trying to put together slides for a workshop called “Getting Started in DH.” And I just couldn’t get started.

For the record, I have given versions of this workshop more times than I can remember.  I have slides from those workshops, and looking them over, I despaired.  DH is so big, DH has so many communities, and, like any other community of theory and practice, participating in DH can become a serious commitment.  Getting a group of people “started” in DH over a lunch talk just seemed impossible.  At least given my rotten mood on this particular Saturday afternoon.

I gave up on the slides and decided to make some gingerbread.  Technically, I decided I needed to bake something, and when my husband saw me look over the recipe for from-scratch gingerbread, his eyes went soft.

So I forged ahead even though we were missing a crucial ingredient — buttermilk.

We were also out of milk, which is how I usually make buttermilk (just add a dash of lemon juice).  But, we did have some creme fraiche hidden at the back of the fridge, and a quick google search confirmed that a blend of creme fraiche and water would work just fine as a buttermilk substitute.  Onward.

I pulled out all the ingredients and lined them up on the counter.  I got really interested in cooking the same summer I took Intro to Molecular Biology, so I cook like I’m in a lab. Although baking has always felt more like alchemy than chemistry.

As I measured and poured and stirred the batter into existence, I found myself thinking about the historical and contemporary imperial structures present in a recipe for gingerbread.

I had blackstrap molasses swirling with creme fraiche: need I say more?

My molasses and brown sugar are organic and fair trade (because seriously, if you are a scholar of early America and you don’t buy fair trade sugar products, I strongly recommend that you reconsider that decision), but I had bought them at Whole Foods, that great appropriator of other food cultures.  And fair trade isn’t cheap, so the fact that I can afford to buy it should be an important modifier on that last statement.  The recipe comes from Williams Sonoma, where the appropriation continues.   My last-minute buttermilk substitution was confirmed by a blog post written in 2009 that had been crawled by the Google bot. The list goes on and on.

Systems and structures, past and present.  Not much here that is natively “digital,” except the readout on my oven and the Google search — both of which elide vast systems of industry and manufacturing.  A great deal here that is “humanities,” because what is closer to us than the food we eat and how we make sense of the world?

And so, I decided that my gingerbread was a Digital Humanities project.  I didn’t design a database for this one, or write a single line of code, but that has never defined DH for me anyway.  I did make “a thing.”  I made it using the resources I had available to me, lab procedure, tacit knowledge, and pre-built digital tools.  I decided on the project in consultation with those it would most impact.  But none of that makes it “DH”either  — at least not for me.

What, IMHO, makes my gingerbread Digital Humanities, is that I made it thinking about the systems and structures that I participated in.  This time I didn’t have a research question, I just had a goal.  But I didn’t leave my training in history or information architecture at the door.  I brought them with me.  That doesn’t change the gingerbread.  It should taste the same.  But for me, DH is in the process, not the outcome.

And I am sick and tired of people with strong technical skills sitting on their mountains and declaring that non-programmers can’t “do DH” or that a certain project “isn’t real DH” because it doesn’t meet some imaginary standard of DIY grit and sophistication, or that somehow becoming a more diverse community will mean lowering our standards.

Digital Humanities needs both sides.  It needs all sides.  DH should be a conversation, a process, and a community.  It should not be a checklist, a test, or yet another way to exclude the people that major structural forces already exclude.

I am hardly the first person to say this.  Among the many people I have learned from, I cannot commend enough the works of Roopika Risam, Bethany Nowviskie, Miriam Posner, Deb Verhoeven, Alex Gil, and Bruce Janz.  And that is just for starters.

But I want DH, especially my new DH home, the Center for Digital Humanities at Princeton, to be balm as well as a trumpet call.  I want CDH to be a place where people feel safe enough to be brave.  And I want them to feel (and be) protected, because the academy is scary enough all on its own.

So I had better write those slides.

But first, gingerbread.

Some thoughts on “Niceness” and the Yack-Hack Cycle

digital humanities

So apparently Twitter exploded yesterday, in that way that Twitter has of “exploding.” I missed it thanks to back-to-back meetings, a long commute, and a desire to spend time with my husband rather than check social media.

On any other day, I would probably be pissed as hell. But it’s not any other day. It’s September 11th, and I’m a New Yorker. I’m a New Yorker who watched a real explosion, who still lives with the fallout, and who tries to hallow the memory of the dead on that day and in all the wars since by studying diplomacy and seeking new ways of communicating in the hope of finding common ground.

Part of that search lead me to Digital Humanities. Some are now saying that Digital Humanities is too dysfunctional to be considered a community. Maybe that just makes us a family. I don’t know. I do know we’ve become quite comfortable with name calling over the past few years. We said we wanted a bigger tent and now we’re pulling the poles from the ground. Growth pains are inevitable, but vindictiveness, suspicion, and careless dismal of pain are choices. 140 characters may be just enough space for the cut direct, but we don’t have to give it.

And speaking of Twitter, if Digital Humanities has taught me anything, it is that we are called to be thoughtful, critical users of technology. Tools and workflows shape our content, whether it is fixed menu categories or editorial practices. But we (should) know enough to explain our choices. There is no web authoring platform so restrictive it cannot have an About page or tool so small it doesn’t need a Readme.md file that explains the creator’s intentions.

There are no self-signifying technologies. We choose our tools in full knowledge of their strengths and weaknesses. We build tools knowing our own limitations. At any given moment the tool is what is it is, whether you built it or someone else did. The choice to use it is yours, and you owe it to yourself and your scholarly community, to explain the choices you made. When our best faith efforts to promote openness and share our knowledge exclude others or warp perceptions in unacceptable ways then it’s time for us to take responsibility, to apologize, and to figure out how to fix it.

This is the Yack-Hack Cycle. It’s not a debate. There is no “right side.” We theorize, we model, we build, we reflect, we tweak. Wash. Rinse. Repeat.

I was on nowviskie.org earlier today and watched the letters fall down the side. At one point a capital H and a capital D came into view and danced with each other down the screen.

DH
HD
DH
HD
Digital Humanities
Humanidades Digitales
Digital Humanities
Humanidades Digitales

It reminded me of Isabel Galina’s incredible closing keynote at DH 2013 in Lincoln, Nebraska. If you haven’t already watched it, do so ASAP http://www.youtube.com/watch?v=O6dP66JMwgc or read it here http://humanidadesdigitales.net/blog/2013/07/19/is-there-anybody-out-there-building-a-global-digital-humanities-community/

This brilliant, insightful younger woman stood at the same podium Willard McCarty had spoken from the night before and, in her second language, quietly (and I would say nicely) told the international community of Digital Humanists that we are not nearly as nice as we want to believe. We exclude people on the basis of language, culture, gender, geography, finances, and access to cyberinfrastructure. Ignorance or mistaken good intentions doesn’t get us off the hook, they just commit us to fixing the problem. She then listed a number of tasks ranging from simple to complex that will help address those issues. I was floored, humbled, and inspired.

I am part of the problem. I want to be part of the solution. But after seven years in DH, I know I am not alone.

Network Analysis for Humanists

digital humanities, network analysis

Today I am teaching a workshop called “Network Analysis for Humanists” at Northeastern’s NULab for their Boston Area Days of DH.

If you attended my workshop (or are just interested in learning more), here are a few suggested readings. I would include more, but following the links from Scott Weingart’s blog posts will help you find most of them.

If you have additional readings, put them in the comments and I’ll move them into the main post.

Happy Networking!

Scott Weingart’s Demystifying Networks I & II
2 blog posts from his great blog “The Scottbot Irregular”, republished in the first volume of the Journal of Digital Humanities

Gephi Tutorials
Gephi is one of the main open source packages for analyzing and displaying networks. It is very powerful, but also finicky and rarely intuitive. I strong suggest looking through the 3 ‘Official Tutorials’ before you start using the program. There are presented as slides (without audio) but provide a good overview to the software. If you keep using Gephi, you will probably find yourself returning to them again and again.

Tales from the Port: Part 2 — Migrating the Database

databases, DAVILA, design, digital humanities, Uncategorized

In retrospect, maybe I shouldn’t have promised to write a blog post every night this week. The port has been going well, but I’ve been working late each night, and it’s just too hard to write clear English prose starting at midnight. So here, at last, is the promised post on migrating Project Quincy’s database from Rails to Django.

My first love in Digital Humanities is data modeling and database architecture. The actual “code” in Project Quincy is pretty basic by professional programming standards. The underlying data structure is the real intellectual achievement. I spent six months of my nine month fellowship at the Scholars’ Lab designing a database that would effectively and efficiently model historical sources and allow scholars to catalog and analyze their research in meaningful ways. I even wrote a program called DAVILA to auto-generate interactive, color coded, annotated diagrams of my schema to show other historians how the system works. After all that work had been done, designing the interface for The Early American Foreign Service Database (EAFSD) took about two weeks.

As I mentioned last time, Rails and Django are similar frameworks for connecting databases to websites. They both have procedures for creating new database instances in several open source databases: MySQL, PostgreSQL, or SQLite3. But I already have a MySQL database with all the information I’ve been entering for the last three years. I really didn’t want to redo all that work, so I kept the same underlying database and connected it to the new Django project, with a few minor changes.

In the past three years, I’ve found a few shortcomings in the data model I created. So, I’ve used the port as an opportunity to add a couple more tables. Project Quincy records a “latitude” and “longitude” point for every location in the database, but I forgot to indicate which geographic coordinate system the latitude and longitude were from. Luckily for me all my coordinates were in the same system, so my maps work properly. But I can’t count on that forever, so I added a table called CoordinateSystem. I also extended the table that records which individuals were members of a specific organization. I had a field called “role” but there was no way of creating a list of all those roles and reusing them. I added two new tables “RoleTitle” and “RoleType” to allow for lists and grouping by type.

Then there were a few changes required by Django, mostly to my Footnotes module. Since Project Quincy is designed to store scholarly research, it gives users the ability to ‘footnote’ any record in the system by attaching the record to a cited source and saying whether or not that source supports the information in the record. This is accomplished by the Validations table, which can (but does not have to) be connected to any record in the database. This type of unspecified relationship is known as a “polymorphic association,” and Rails and Django implement polymorphic associations differently. Rails uses the name of the table to create the relationship. Django makes a meta-table that holds the names of all the other tables and assigns them a numeric key. So, I had to replace my table names in the Validations Table with their new keys. Figuring out how to do this took a post to the ever helpful Stackoverflow website and I was back in business. The old Footnotes module also had a little “Users” table that kept track of the people who could upload into the system. Django comes with a very powerful authentication system which also records users, so I got rid of my little table and hooked the footnotes module directly into the django_auth_user table.

I had greater plans to include an “Events” module. But, as I started to design one, I realized that this was not a decision I should make on my own and under a deadline. Project Quincy is an open source project, and I want other scholars to use it for their research. I need to do more reading on modeling events and talk to people before I commit to one particular structure.

So how did I actually migrate the database? MySQL has a nice command for backing up and redeploying a database; it’s called mysqldump. I took a dump (yes you read that correctly:-) of the database off my server and used it to create a transition database on my local machine. I then went in made the changes to the transition database directly, safe in the knowledge that could always restore the original database if I messed up. Once I had the transition database the way I wanted it, I made a second dump and used it to populate the database Django had already created for the new project.

Once all my data was in the new database, I ran an extremely helpful Django command ‘inspectdb.’ This lovely little program examined my database and created a file with its best guess on how to represent each database table in Django syntax. Then all I had to do was check for errors, and there weren’t many. It mistook my boolean (true/false) fields for integers and wanted me to specify some additional information for self joins (tables containing more than one relationship to the same, second table).

Once I had the tables properly represented it was time to sort them into their appropriate ‘applications.’ One of the biggest diferences between Rails and Django is their file structure. Rails creates a folder (with its own nested folders) for every table in the database. Django asks developers to chunk their database into folders called applications, designed to keep similar functions together in the system. Project Quincy was always designed with six modules: Biographical, Locations, Correspondence, Citations, Organizations, and Assignments. Each of these modules has 2 to 8 database tables inside it. One of the biggest decisions I had to make in planning this port was how to use applications. Did I put everything in one app folder, create an app for every module, or find an new way of grouping my system?

To make the decision, I wrote out index cards for each module listing the tables involved and what other modules it related to. I realized that Assignments and Organizations both brought people to a location for a reason, and that I would likely be visualizing those two kinds of relationships in vary simliar ways, but what should I call the new app? I ran the idea past my father, who has been designing databases since before I was born and recently took his entire development to python and django. He suggested the name “Activities” and that my future Events module could go in the same application.

After I sorted my tables into their appropriate (and newly created applications) I synced my Django project with the underlying database. So far, everything looks good.

Tales from the Port: Day 1 — Dry Dock

databases, design, digital humanities, django, ruby on rails

Welcome to my one week blog series, Tales from the Port, chronicling my rewriting of Project Quincy from Ruby on Rails to Django. This series may be a little rough around the edges — I’ll be writing it every night after I accomplish my goals for that day. But I wanted to give people a window into the life of (at least one) Digital Humanities developer. To see what it’s like to imperfectly translate your research and theories into lines of code and then watch your project come ‘alive.’

Of course, Digital Humanities is not about writing code or knowing how to program. DH is a community of people searching for a new way of working and researching, and we find inspiration in many disciplines. But, this is going to be one of the more intense work weeks of my life to date, so I’m hoping you’ll keep me company.

First, some background:

Project Quincy is an open source software package I wrote a few years back to trace historical networks through time and space. It is an integral part of my dissertation and currently runs The Early American Foreign Service Database, which went live almost two years ago on October 18, 2010. Project Quincy got its start at the University of Virginia’s Scholars’ Lab, where I was a graduate student fellow in 2008-2009. I was very pleased with the system when I first designed it, but technology doesn’t stop when your fellowship ends. Faced with an aging code base and an interface that could no longer accomodate the visual arguments which are becoming more and more central to my dissertation, it was time to upgrade. I could have taken Project Quincy from Rails 2.3.8 to 3.0 and tweaked the stylesheet along the way, but I am no longer at the University of Virginia. Last summer I was hired by the Brown University Library as their first Digital Humanities Librarian. My new colleagues program (mostly) in Django, and I’ve already met one or two professors here who could probably use the system for their own research. It was time to learn some new skills.

I have thoroughly enjoyed learning Python and Django, so much so that I will probably write more on them once this week is over. Since finishing up the tutorials, I have spent the last two weeks planning the port. As the week unfolds I’ll discuss how the system is changing and my reasons for making those changes. Although both Django and Rails exist to connect databases to websites with minimal headaches for the programmer, they have different affordances and make very different assumptions about what constitutes beautiful code.

So what have I done today?

Today I created the new Django project which I will be extending into ProjectQuincy. I had hoped to have the entire data model rewritten by now, but no plan survives contact with a new development environment . . . Apparently when I got my new MacBook Pro my MySQL installation did not survive the transfer. It took a few hours of research, then reinstalling MacPorts, before I could really get underway. I will have more to say tomorrow on my changes to the data structure.

Planning this port has been a bittersweet experience. I’ve had a great deal of fun learning a new language and framework. My colleagues at Brown, particularly Birkin Diana and Joseph Rhoads, have been extremely helpful: suggesting good training materials, answering questions, and teaching me the ever crucial “best practices.” Thanks to their help, I am looking forward to having a cleaner, more robust system. But, my fellowship year at Scholars’ Lab is a cherished memory, and so many people there helped and taught me as I figured out how to make The Early American Foreign Service Database a reality. As I worked on the project my friends pitched in, putting their own stamp on the code base. This new, fresh start won’t have code from Bess Sadler, Matt Mitchell, Joe Gilbert, or Wayne Graham. For a little while it will just be my code, and that feels a little lonely. But it won’t last. Soon I’ll be showing the system to my colleagues at Brown, and I can’t wait to see Project Quincy afresh through their eyes.

Safe Spaces and Kind Words

digital humanities

Every generation has to kill the dragon, or so the saying goes.

I disagree.

I may be starting a new chapter in my life, but I refuse to slam the door behind me.

If I am privileged, then I owe that privilege to my teachers — female and male — who took time out of their busy lives and frantic production schedules to answer my questions, critique my data models, debug my programs, and tweak my code.

I am lucky. By the time I got to the Scholars’ Lab, I was on my fifth dissertation prospectus. Feelings of isolation and unworthiness, those constant companions in graduate school, were beginning to reach critical levels. I have a vivid memory of meeting Bess Sadler (then head of R&D), talking with her, and then watching her turn to Joe Gilbert and say “She is one of us!” No one had said anything like that to me in . . . well . . . years.

When I started my fellowship, I hadn’t written a computer program in seven years. Bess started to teach me Ruby on Rails, and when she realized that I didn’t know HTML and had never even heard of Information Design, she gave me books on those topics as well. When Bess left the Scholars’ Lab for another position in the library I panicked, until I realized that the new head of R&D, Matt Mitchell, was just as happy to work with me and so was his successor, Wayne Graham.

And behind it all was Bethany Nowviskie. Triple-booked most days of the week, tweeting intriguing project links and encouraging words faster than I could follow, and always working on some new way to bring more people under the big tent of DH, Bethany fostered community wherever she went.

And she is still doing it. The Scholars’ Lab has undergone an almost complete staff turnover since I started my fellowship in the Fall of 2008, but it remains the same welcoming and challenging community where I found my intellectual home.

Programming was the least important skill I learned in those years hanging out on the 4th Floor of Alderman Library. I learned how to work collaboratively, not just with software developers, but with Archeologists, Musicologists, and Literary Theorists. My fellow fellows challenged my assumptions about evidence and argument and helped me craft a rhetoric that (hopefully) breaks out of my own disciplinary boundaries.

Sixteen months ago, I knocked on Bethany’s open door to ask if she had any time to meet with me in the next week. I had come to the realization that I no longer wanted to be a history professor and had been freaking out. A huge, gentle (though slightly mischievous) smile spread over her face, and for the first time since I had printed out the job postings from the AHA website, I relaxed.

Last summer, surrounded by boxes in my new apartment in Boston, I saw Bethany’s offer to include in her Tenure and Promotion Dossier any and all DMs sent in before the deadline. I cleared off a chair, thought for a while, and then wrote the following:

D nowviskie is my model for scholarly creativity and collaboration. With wisdom and kindness she creates safe spaces for people to flourish

To quote Charles Dickens, “May that be said of us, and all of us!”

Who you calling untheoretical?

alt-ac, digital humanities

I’m sorry. I need to vent. If you think you will be offended, continue at your own risk. You have been warned.

Several weeks ago, the whole Digital Humanities Theory, or Hack vs. Yack, debate sprung to life once more with a post by @ncecire. I have since read several other posts on this issue, calling for more communication, more give and take, more attention to political realities between Theory and DH.

However, I find many of the comments in these pieces insulting to those of us who work on DH projects. I doubt this is intentional, but I feel the need to defend the theoretical work already being done, while looking forward to incorporating even more ideas. Debate is good. In the academy, debate over terminology is inevitable yet often productive. So here is my rant:

I am sick and tired of people saying that my friends, my colleagues, and I do not understand or care about theory.

Every digital humanities project I have ever worked on or heard about is steeped in theoretical implications AND THEIR CREATORS KNOW IT. And we know it whether we are classed as faculty or staff by our organizations. Libraries and other groups involved in DH are full of people with advanced degrees in the humanities who aren’t faculty, as well as plenty of people without those advanced degrees who know their theory anyway. Ever heard of #alt-ac? The hashtag is new; the concept is not.

I have attended physical weeks of meetings to discuss terminology for everything from personal status (Do we label someone a “slave” or “an enslaved person?” If we have an occupations list should we include “wife,” if so should we include “husband?” What about “homemaker?”) to political structures (When do we call something an “empire?” Is “nation” an anachronism in this period?). I’ve seen presenters grilled on the way they display their index — and heard soul searching, intellectually rigorous justifications for chronological, thematic, alphabetic, or randomized results.

Just this week I was presenting The Early American Foreign Service Database and got the question “So where is the theory in all of this?” Before I could answer with my standard, diplomatic but hopefully though-provoking, response a longtime DHer called out “The database is the theory! This is real theoretical work!” I could have hugged her.

When we create these systems we bring our theoretical understandings to bear on our digital projects including (but not limited to) decisions about: controlled vocabulary (or the lack thereof), search algorithms, interface design, color palettes, and data structure. Is every DH project a perfect gem of theoretically rigorous investigation? Of course not. Is every monograph? Don’t make me laugh.

I have spent so much time explaining the theoretical decisions underlying Project Quincy, that I wrote a program to allow database designers to generate color-coded, annotated, interactive database diagrams in the hopes that more Humanist Readable documentation would make all our lives easier. (The program is called DAVILA.)

One of the most exciting things about DH is the chance to create new kinds of texts and arguments from the human experience. Data structures, visualizations, search tools, display tools . . . you name it . . . are all a part of this exploratory/discovery process.

So it’s time for me to stop ranting and, in the best of DH tradition, DO SOMETHING.

If we as DHers are creating something new, then I believe our vocation includes teaching others how to read our work. If someone looks at The Early American Foreign Service Database and doesn’t see the theory behind it, maybe I need to redesign the site. Maybe those color-coded, annotated diagrams should be more prominently displayed. Maybe I need a glossary for my controlled vocabulary. I wrote DAVILA, but the download only parses one kind of schema. Maybe I should write some more.

I’m going to stop talking (for now.) But, I’ll end with a tweet from Matthew Kirschenbaum, a great practitioner and theorist of DH: “More hack, more yack, and please, cut DH a little slack. We’re just folks doing our work.”

Am I even qualified?: Writing about Digital History

databases, digital humanities, history

About two weeks ago, my article “Fielding History: Relational Databases and Prose” went online for open peer review and possible inclusion in the open access essay collection Writing History in the Digital Age, edited by Jack A. Dougherty and Kristen Nawrotzki. If you haven’t heard about Writing History in the Digital Age, you owe it to yourself to head over to the website and learn more. It is a fabulous project and experiment in open peer review and open access publishing. I am honored that my essay has made it this far.

As part of the experiment, the editors have asked their prospective contributors to publicly reflect on their writing process. That’s something I have neglected to do until now, for a variety of reasons . . . the main reason being that this may be the most difficult essay I have ever written.

OK, my master’s thesis was probably harder, but that was five times as long, and I worked on it (on and off) for 4 years before sending it out to be traditionally peer-reviewed. “Fielding History” clocks in at 3,077 words and I only had six weeks to write it. Six weeks in which I nearly gave up on the project approximately four times. One of these times (but not the last), my husband asked why I was quitting. Before I could think, I responded:

“Because I am only qualified to write about 18th Century Diplomats!”

He just stared at me. I stared back. Until the absurdity hit me. I’m an open source developer, a database architect, and a historian. I’ve developed and built databases for three distinct historical projects (including my own dissertation). If I can’t write an article on relational databases and historical writing, then who can?

But that is the trick with an emerging field. It’s hard to know when you are ready to write about it. I know how to become credentialed to write about my 18th Century diplomats. I’m getting a PhD. Most of the time I’m very happy with the boot-strapping culture that imbues Digital Humanities with so much of its energy and allows someone like me to have a great job and contribute to the field without having to wait for tenure or even my dissertation committee to declare me “fit.”

But then I have to write about what I’m doing, and all the doubts pile in. I always wanted to write about the theory of history, even before I entered a PhD program, but I thought I would do it after I retired — an emerita’s retrospective on a life of study. What right do I have to do this when I’m only 29?

What finally got me writing was the realization (voiced by my husband) that this was not about having the final word or all the answers. But I could put in an early word for something I care about and maybe start a conversation. I wrote the piece in first person (a big no-no for academic prose) to emphasize that point. I don’t have the theoretical chops to write in the third person about databases and history. What I have is a case study, a story, that may help others think more reflectively about what we digital historians do every day.

I hope you will head over to Writing History in a Digital Age and look at the really amazing essays my fellow historians have written. Open peer review continues through November 14, 2011. Please comment if you have something it say: having an essay up for open peer review is orders of magnitude more nerve-wracking than wondering if anyone reads your blog.

Maybe stop by and read my piece as well, if the topic interests you. Let’s get this conversation started.