I’ve been thinking a lot lately about the significance of small projects in an increasingly large-scale DH environment.  We seem almost inherently to know the value of “big data:” scale changes the name of the game.  Still, what about the smaller universes of projects with minimal budgets, fewer collaborators, and limited scopes, which also have large ambitions about what can be done using the digital resources we have on hand?  Rather than detracting from the import of big data projects, I, like Natalie Houston, am wondering what small projects offer the field and whether those potential outcomes are relevant and useful both in and of themselves as well as beneficial to large-scale projects, such as in fine-tuning initial results.

My project in its current iteration involves a limited dataset of about 4500 poems and challenges rudimentary assumptions about a particular genre of poetry called ekphrasis—poems regarding the visual arts.  It is the capstone project to a dissertation in which I use the methods of social network analysis to explore socially-inscribed relationships between visual and verbal media and in which the results of my analysis are rendered visually to demonstrate the versatility and flexibility available to female poets writing ekphrastic poetry. My MITH project concludes my dissertation by demonstrating that network analysis is one way of disrupting existing paradigms for understanding the social-signification of ekphrastic poetry, but there are more methods available through computational tools such as text modeling, word frequency analysis, and classification that might also be useful.

To this end, I’ve begun by asking three modest questions about ekphrastic poetry using a machine learning application called MALLET:

1.) Could a computer learn to differentiate between ekphrastic poems by male and female poets?  In “Ekphrasis and the Other,” W.J.T. Mitchell argues that were we to read ekphrastic poems by women as opposed to ekphrastic poetry by men, that we might find a very different relationship between the active, speaking poetic voice and the passive, silent work of art—a dynamic which informs our primary understanding of how ekphrastic poetry operates.  Were this true and were the difference to occur within recurring topics and language use, a computer might be trained to recognize patterns more likely to co-occur in poetry by men or by women.

2.) Will topic modeling of ekphrastic texts pick out “stillness” as one of the most common topics in the genre?  Much of the definition of ekphrasis revolves around the language of stillness: poetic texts, it has been argued, contemplate the stillness and muteness of the image with which it is engaged.  Stillness, metaphorically linked to muteness, breathlessness, and death, provides one of the most powerful rationales for an understanding how words and images relate to one another within the ut pictura poesis tradition—usually seen as an hostile encounter between rival forms of representation.  The argument to this point has been made largely on critical interpretations enacted through close readings of a limited number of texts.  Would a computer designed to recognize co-occurrences of words and assign those words to a “topic” based on the probability they would occur together also reveal a similar affiliation between stillness and death, muteness, even femininity?

3.) Would a computer be able to ascertain stylistic and semantic differences between ekphrastic and non-ekphrastic texts and reliably classify them according to whether or not the subject of the poem is an aesthetic object or not?  We tend to believe that there are no real differences between how we describe the natural world as opposed to how we describe visual representations of the natural world.  We base this assumption on human, interpretive, close readings of  poetic texts; however, there is the potential that a computer might recognize subtle differences as statistically significant when considering hundreds of poems at a time.  If a classification program such as Mallet could reliably categorize texts according to ekphrastic and non-ekphrastic, it is possible that we have missed something along the way.

In general, these are small questions constructed in such a way that there is a reasonable likelihood that we may get useful results.  (I purposefully choose the word results instead of answers, because none of these would be answers.  Instead the result of each study is designed to turn critics back to the texts with new questions.)  And yet, how do we distinguish between useful results and something else?  How do we know if it worked?  Lots of money is spent trying to answer this question about big data, but what about these small and mid-sized data sets?  Is there a threshold for how much data we need to be accurate and trustworthy?  Can we actually develop standards for how much data we need to ask particular kinds of humanities questions to make relevant discoveries?  In part, my project also addresses these questions, because otherwise, I can’t make convincing arguments about the humanities questions I’m asking.

Small projects (even mid-sized projects with mid-sized datasets) offer the promise of richly encoded data that can be tested, reorganized, and applied flexibly to a variety of contexts without potentially becoming the entirety of a project director’s career.  The space between close, highly-supervised readings and distant, unsupervised analysis remains wide open as a field of study, and yet its potential value as a manageable, not wholly consuming, and reproducible option make it worth seriously considering.  What exactly can be accomplished by small and mid-scale projects is largely unknown, but it may well be that small and mid-sized projects are where many scholars will find the most satisfying and useful results.

The first thing you hear, or at least that you should hear, when you present an idea for a digital humanities project to someone already familiar with the field is this: “That’s great! [pause]  What does your data set look like?”  Actually, that’s the reaction you’ll get if whoever you’re talking to is taking you seriously, so the reaction is a mixed blessing.  On the one hand, you have their attention.  On the other, they know enough to point out that projects without data go nowhere, and good data (not necessarily synonomous with big data) is hard to find. Data is truly the Moby Dick of the digital humanities.  None is ever big enough, clean enough, or well-structured enough to achieve precisely what it is that researchers would like to achieve.  Just when you (and more likely your team) feel confident that the data set is “harpooned” (structured, refined, aptly-tagged, and curated), the whale takes off again with a new standard: interoperabilty.  It doesn’t play well with other data, and the chase begins again.  When your data set works for you, that has some value, but when your data set works with others, well, that means a wider audience and a broader impact for your work.

Most projects have lifespans determined by fellowships or grants or sabbaticals, and unlike Captain Ahab, we can’t afford to have our hard work dragged out into the abyss and lost.  The DH mantra may well be “project or perish.”  Hard decisions about data are often determined by two factors: intellectual value and time.   First, your data needs to be thoughtfully selected, described (tagged with metadata) and clean enough in order to work and to reasonably make the argument that what you’ve done with the data can be trusted.  However, you need to know when it’s time to cut the rope and release what might be done, a choice between good-enough and great.  When just a few more hours of tagging, a few more weeks of correcting OCR errors seem just within your grasp, the choice feels mercinary.  Deciding to stop improving your data, though, is like the difference between Faulkner and Melville: “you must kill all your darlings.”  Data sets, really, are Modernist objects: they are “what will suffice.”

This is the lesson I learned during my first full month at MITH.  As a Winnemore Dissertation Fellow, I have approximately four months to capitalize on MITH’s resources and to produce a project that has a strong (but not perfect) data set, answers relevant humanities questions, and possesses enough sustainability, public outreach, and external support to become a viable, fundable project in the future.  In these first five weeks, I have benefitted from the wealth of experience and depth of knowledge that the team assigned to my project possess.  Jennifer Guiliano knows how to pull projects together, shepherding them through the steps of data management, publicity, and sustainability.  Taking to heart her sage wisdom about managing successful DH projects, I feel that I have a much stronger grasp on what steps must be taken now and what can and must happen later, professional development knowledge that more graduate students should have when they venture into the alt-ac or tenure track market. Trevor Muñoz’s expertise with data sustainability prompted questions that have helped shape a future to my project even at it’s earliest oustet—few graduate students have the time or the resources to think about how adequate curation in the short term could mean greater benefit in the long term.  Amanda Visconti and Kristin Keister have been helping me to shape a public portal for my work, and I know that the virtual presence they help create will lend to the future success of the project, as well as its intellectual value.

The most salient lessons I’ve learned about the lure of the great data whale, however, have been from Travis Brown.  I arrived in January with a large, but unrefined dataset of approximately 4,500 poems in a less-than-uniform collection of spreadsheets.  I had a basic understanding of what I wanted the data to look like, but in consultation, Travis helped me to determine what would work better and might last longer.  Travis created a data repository on MITH’s space with a version control system called “git.”  (Julie Meloni’s often-cited and useful “Gentle Introduction to Version Control” on ProfHacker provides a useful explanation of what git is, why it’s valuable, and where to find resources if you’d like to try it.)  Once I installed git on my machine, replicated the repository, and “pushed” (basically moved the data from my computer into the repository Travis created) the data to it, Travis could take a look.  We agreed to separate the text of the poems and their titles from the descriptive information about it (author, date, publication, etc.) and to use a uniform identification number to name the file for each poem, and to track its descriptive data in a separate spreadsheet.  We realized at that point that there were some duplicates, and in conversation agreed that we would keep the duplicates (in case there was a reason for them, such as minor textual differences) and tag them, so that later we could come back to examine them, but in the meantime not include them in the tests I’d like to run.

Then came the “darling killing.”  Metadata, the information that describes the poetic texts that make up my data set, is necessary for the tests I’d like to run—those that classify and sort texts based on the likelihood that words co-appear in particular poems.  The amount of metadata that I include to describe the poems will determine the kinds of tests and the reliability of the tests I hope to run.  However, tagging 4,500 poems, even with simple identifiers, could take the whole four months of my fellowship if I let it.  The hard choice was this: I would tag only the gender of the poet associated with each poem and whether or not the poem is ekphrastic (that is to say written about, to, or for work of visual art) or not or unknown.  Some poems were easily tagged as ekphrastic, because I had sought them out specifically for that purpose; however, more often than not, I would need to make poem by poem determinations about the likely poetic subject.  This takes time, and because of the tests I need to run to ask the questions I want to ask (eg. Can Mallet distinguish between descriptions of art and descriptions of nature?), I will need to let go of other useful, informative, helpful tags I would like to have, like the date each poem was published, the artwork to which it refers, and so on.

I am keeping record of all these things.  The decision not to be perfect is the right choice, but it isn’t an easy one.  I feel sometimes as though I have watched my whale slip from my grasp and sink back into the sea.  My crew is safe.  My project will continue on schedule, but not without the longing, nagging feeling that I need to return to this place again.  Perfect data sets are a myth, one that often forms the barrier to new scholars who wish to begin DH projects.  Rather than struggling for the perfect data set, I want to suggest that we place a much stronger emphasis on the more intellectual and more necessary component of data curation and data versions.  I would argue that we judge projects not by the “completeness” or “perfection” of the data, but how well its versioning has been documented, how thoroughly curatorial decisions such as what to tag, when, and why have been publicized and described, and how much the evolution of the data contributes to the development of other projects within the community.  Much the same way that we know more about the value of an article by how often it has been cited, we should value a digital humanities project by how much can be learned by the projects that follow it.  In this sense, we should all be called Ishmael.