Author Archives: David Ainsworth

How to present work

One of the problems with digital humanities work is that much of the work is invisible by design. Metadata, for example, can be handled transparently. Users typically see none of the code that makes a program or site function unless they go out of their way to do so; code which must be compiled may not even be viewable by users. In addition, digital humanities work does not transparently present itself as scholarly, nor does it automatically situate itself in the way that a monograph may and a journal article typically does. Being published in Shakespeare Quarterly means being contextualized for Shakespeare scholars within the context of peer review, revision and presentation of work which goes along with that journal. The advantage of being published in a top journal is that this context for your work implies its quality and scholarly merit. Self-publishing an article, by contrast, brings along with it none of those external contexts or elements of outside review.

Peer review and the digital humanities strikes me as a large topic. We’ve engaged with it secondarily (from Digital Humanities Now to a range of other sites) and primarily (our Project Reviews), but especially for collaborative DH projects, peer review is an ongoing process. I think we must take it as such here, too, although not all of you will continue your work on these projects.

How, then, can you make a case for the scholarly value of the work that you are doing? In part, the answer must be dictated by that work: a program is distinct from a textual analysis is distinct from an online edition or archive, and all these may differ from a tool or commons or journal or procedure or the like. In addition, DH work may be indirectly productive in the sense of bringing about scholarly work of various sorts, or it may be directly productive, the object in question itself.

I suggest three elements involved in presenting and justifying your work:
1. Context.
2. Document what went into the project.
3. Credential the project as scholarly.

Context involves situating whatever work you’ve done within the framework which produced it. Having that context when learning calculus would probably help students, for example, by explaining that calculus was developed initially to help model physical interactions between objects in motion. Context here involves understanding how your work situates itself within an existing project or within what has been done–or what has yet to be done–in digital humanities more broadly. Your main concerns should be to explain your purpose and establish that you are doing digital humanities, to the extent that is possible.

Documenting your work will help you address the common (and I suspect, large) problem in DH projects that they often appear, when functioning, to be quite simple, but they all take levels of effort not obvious or visible. There are some possible exceptions (as with “straight text” work where you simply type in a bunch of words without including pictures or links, like this post), but you want to be certain that you get credit for the blood, sweat and tears invested in your project, even (or especially) if what you end up with doesn’t look like much yet.

Credentialing the project can prove difficult, as we’ve seen. I think your best approach, especially for the work you’re doing for this seminar, would be to think along one of two lines:
A. Value added. With the caveat that this approach fits the neoliberal/capitalist criticisms laid upon DH, I suggest you sketch out how what you have done makes a contribution, however small, to scholarship or the scholarly community. This will be easier if you’re a small cog in a big machine, as you only really need to establish that you contributed to the big project and point to that project’s own scholarly justification/engagement. For a new project, you’d need to identify who it serves and explain how it does so. (Copy/pasting an existing site under a Creative Commons license wouldn’t qualify as adding value, to provide an example of something NOT scholarly.)
B. Scholarly content. While necessarily nebulous, the “scholarly” can nevertheless be distinguished from that which is not. One of Roger Ebert’s film reviews would be more scholarly than me tweeting “That movie sucked!” to a personal Twitter feed; a critical analysis of a film or group of films would be scholarly; a Youtube video talking about a film could be. Generally speaking, your approach, audience and content will all help you to describe your work as scholarly (or not). Your best example here would be to think of a post to a personal blog. One post might be clearly unscholarly, which another might be clearly scholarly, and a third might be ambiguous, reflecting mixed audiences and mixed purposes. I think it in some ways unhelpful to be dogmatic about what is or is not scholarly; that said, if you want your DH work to be treated as scholarship, you need to be able to make a case for it, whatever form it takes.

Both credentialing options involve identifying your audience and what you expect your audience to get out of your work. Again, if you’re contributing to an existing project, this part of your task should be easier as that project has implicitly or explicitly answered these questions already.

For your projects this semester, I’d aim for a 1-3 page reflection on your work. Feel free to include analysis of various sorts (what went well or poorly, what you learned from the experience), as I think these help to establish the scholarly productivity of the experience.

Work as a problem with DH

One of the things I’m hoping has become clear–perhaps painfully so for a few of us–is the extent to which a digital humanities project represents a substantial amount of work. Even a supposedly small element in a project, like metadata tagging, can turn out to be a difficult and time-intensive piece of work, one which generally isn’t much fun but which has to get done. Continuation, expansion and maintenance of an existing site, like EBBA, typically entails a repetition or reiteration of this kind of work. If the EBBA site adds a new search term (searching by place or by type of image), then a new set of metadata must be developed and then entered for every single item in the archive.

Projects involving tools require either direct coding or adoption of existing code from other sites. In theory, a tool developed to speed the entry of metadata for the EBBA project could be employed for similar projects; in practice, tools often are either outdated or coded in a way so specific to a single project that they require modification for broader use. Hence, the development and proliferation of project platforms (WordPress and Blogger, for example, are blogging/web-page platforms; Omeka is a platform tailored for more metadata-intensive application). Standards for metadata exist alongside such platforms, like the TEI standard we’ve looked into earlier in the semester.

When a collaborative online project exists in the way that user involvement typically exists (with Facebook or myspace or Youtube or Wikipedia), everything seems easy enough. You log in, post your edit to the wiki entry, other people vet the entry, and it’s all good. In practice, this kind of open development conceals from the typical user the degree of work which was involved, from developing and maintaining a platform (like the wiki platform), to administrating a site (Wikipedia servers must be purchased, maintained, replaced, just as one example), not to mention the difficulty in starting up such a project in the first place. And while the Internet bills itself as a kind of instant gratification engine–Google tells you how many tenths of a second it took to generate its results, for instance–the actual time and investment of energy required to develop an online project, not to mention the requirements to put it into practice, looks much closer to scholarly and academic norms and expectations. Most projects I’ve seen which make their histories known took years to get past the starting gate. EBBA, for example, began development in 2003. That means the EBBA development has gone on longer than, say, the iPhone, from initial conception to present implementation.

One of the challenges digital humanities face going forward, within the academic community, is articulating more clearly to those who assess scholarly work the degree of time, planning and organization required to prototype, much less “complete,” a single project.

Andrew Torget, Monday Feb 11th 3-4 PM

This event qualifies for your Theory review, but I encourage you all to attend regardless.
David

Speaker: Andrew Torget, “The Promise and Perils of Doing History in the Digital Age”
Mon, February 11, 3pm – 4pm
Gorgas Library, Room 205

What will become of the humanities in the Age of Google? Andrew Torget will talk about the unprecedented challenges and opportunities that face historians in the twenty-first century. Tracing the evolution of the digital humanities over the past two decades, Torget will explore how new research methods (such as geospatial analysis and text-mining) are creating a quiet revolution among historians, and what that could mean for how we understand the past.

Andrew J. Torget is a historian of nineteenth-century North America at the University of North Texas, where he directs the Digital History Lab. The founder and director of numerous digital humanities projects — including Mapping Texts, Texas Slavery Project, Voting America, and the History Engine — Andrew served as co-editor of the Valley of the Shadow project, and as the founding director of the Digital Scholarship Lab at the University of Richmond. The co-editor of several books on the American Civil War, Andrew has been a featured speaker on the digital humanities at Harvard, Stanford, Rice, and the National Archives in Washington, D. C. In 2011, he was named the inaugural David J. Weber Research Fellow at the Clements Center for Southwest Studies at Southern Methodist University. He is currently completing a book titled Cotton Empire: Slavery, the Texas Borderlands, and the Origins of the U.S.-Mexico War.

Digital Humanities in Practice?

I’ll try to make some posts prior to our class sessions, both to guide your thinking and to contextualize some of what we’ll be doing.  In our next session, we’ll be looking at some digital humanities projects “on the page,” as it were, so I want to highlight a potentially artificial contrast established by the shift in topic.  As we’ve discussed, there’s some question as to whether digital humanities are something one does, or a field or discipline or area of study.  Are they an approach to doing things we already do?  A new set of tools to accomplish a new set of tasks?  Are they in the design of those tools, or just in their usage?

Turning from theory to practice risks an endorsement of a particular (and suspect) definition of the digital humanities, whether it be as code or as specific accomplishments which live at specific web addresses.  But even in the list of sample projects I’ve provided you, serious questions arise as to what truly constitutes digital humanities “work.”  Can one simply scan a text and declare that enough?  What goes into archival work, curation, and editing and to what extent do those things themselves exist as elements of (or central to) the digital humanities?  And to what degree would we classify these projects as “academic?”  How much does visual presentation, sophistication of form, ease of use, or employment of specifically designed or adapted technologies influence our responses to digital humanities work?  And to what degree must digital humanities replicate the pre-existing work of the academy, or challenge and revolutionize it?  Are these very possibilities inherently polarizing?  Should we instead think in terms of an ongoing process of evolution which inevitably includes blind alleys and dead ends?

As a further complication, while on the one hand the digital humanities present a strongly popularist and democratic approach to matters, emphasizing quick feedback, collaboration and collective intelligence, in practice such approaches undercut the possibility of defining a field or area of study as a discipline.  That a blog posting, or a YouTube video, or a website, could potentially qualify as a contribution to digital humanities, seems not in much doubt (Fish’s concern about blogs notwithstanding, as I think that very post proves that blogs can contribute).  But what criteria exist to allow differentiation?  Who is to differentiate?  How can criteria be developed, and by whom?  In practice, I don’t see how anything other than existing academic standards and procedures will get the job done.  A thumbs-up/down count on a YouTube video can’t establish its dig hum credentials.  The community of digital humanists must do that, in part, as must the scholars who produce digital humanities work.

Milton scholars define the field as they write scholarship on Milton, but they do so within an established context for their work.  The established context for digital humanities strikes me as so contested, so unwilling to dictate or exclude, that I am not convinced digital humanists can generate coherency beyond a generic “family” of work, but these are early days and I expect to be surprised soon enough.  The key question remains: who, precisely, will delineate the field, either through theory or practice, and to what degree will that delineation differentiate digital humanities from specific humanities fields?

Tom Wilson’s visit

As promised, here’s a digital copy of Tom’s presentation text.

Something I increasingly think characterizes DH, as I constantly cut & paste items here, is the degree to which it remixes, reuses, directly links or incorporates other texts.  That’s not unheard of in traditional humanities work, but I wonder whether DH is unique in its attitude towards drawing upon other people’s words.

Here are some of those words:  DH-Tom Wilson