Digital humanities: Challenges, difficulties, reflections, and questions

Last night on Twitter over at We The Humanities we got onto the subject of collaboration, in particular digital humanities collaborations, and some of the pitfalls and problems that can be faced:

Since it’s hard to encapsulate these very complex issues in 140 characters, we thought we’d devote a blog post to some of the challenges and difficulties we faced in the development of the Dictionary, as well as some questions — because sadly, we don’t have any answers, at this point.

In an ideal world, digital humanities collaborations would involve experts on both sides: Experts in some field of the humanities pooling their resources with experts on the technical and computational side of things. Unfortunately, the world is not always ideal.

Many DH projects receive their impetus on the humanities side, and thus involve someone without the technical/computational skills looking to collaborate with someone who does. (For ease of discussion, I’m going to call the humanities person Hums and the technical person Comp.) This is the first hurdle: How to find suitable collaborators. Some universities are lucky enough to have digital humanities clusters or centers which have technical people whose dedicated job is to collaborate on such projects. Unfortunately, such dedicated clusters are still quite rare. Even where they exist, there are challenges. The people who work in these clusters are probably already involved in a number of other programmes, which means that Hums has to pitch his project in such a way as to get Comp interested. If Hums isn’t able to, he’s going to be out of luck in utilizing that resource. Now, maybe Comp is interested, and furthermore doesn’t already have enough projects on her plate to prevent her from taking on a new one. Odds are that Comp has been hired into this cluster/resource so that she can contribute to the technical research agenda of the group. This may be the building of some software or infrastructure, the development of search types of methods or algorithms, or something else: Whatever the reason, Comp is going to have to find a way of integrating her contribution to the collaborative project into the work that she has been hired to do. This means that Comp comes into the project with an agenda, some pre-conceived idea of the approach/software/methods/mechanism to use, rather than coming to the project asking “What are the best approaches/software/methods/mechanisms for this project?”

When the Dictionary was in its infancy, we were incredibly lucky to have access to the members of Heidelberg Research Architecture, who were incredibly generous with their time and helpful with the initial “what, exactly, is it that you want to do?” stages. Ultimately what we learned was that the infrastructure that they could offer was not going to be well-suited for our needs: Their focus was primarily on projects where the data already existed, but simply needed to be appropriately marked-up (usually using TEI) so that it could be accessed by a search interface, while in its infancy, the Dictionary was focusing on collecting and creating data, rather than taking pre-existing and already published information. But this period in the development of the Dictionary was marked off by another challenge that Hums can face when talking to Comp: Hums probably only knows very generally what it is that he wants, and not any of the specifics of how it can best be realized. This is, after all, why he is talking to Comp in the first place! (There are not many unicorns out there, people who are both Hums and Comp in equal measure.) This means that Comp has to be able to listen to not only what Hums says he wants, but what he actually wants:

In the end, we knew enough about what we wanted to know that what HRA could offer wasn’t for us, so we had to start looking elsewhere (as would Hums who don’t have a dedicated DH group within the institution to tap). There are two options: Within the university and without. Even universities that don’t have dedicated DH groups are likely to have Comps of various flavors, and maybe even a Comp or two who is interested in the humanities and interested in collaborating with Hums. A difficulty that arises here is that what counts as research for Hums and what counts as research with Comp is likely to be different, and often what Hums needs from Comp is the production of a product using already known/available resources, whereas what Comp needs to justify her involvement in the project to her department is the production of research output. But if what Hums is doing doesn’t look like research to people in Comp’s department, Comp will have trouble justifying her spending the necessary time on Hums’s project.

The next option is to go outside the university: There are plenty of qualified Comps out there. But this leads to the next challenge: Cost. The problem is, if these Comps are not working in the university, they’re probably far too costly for a DH project to be able to afford, in two ways. First, quite literally: Unless Hums can find a demi-unicorn (i.e., a Comp who is willing to provide her services free of charge/on a volunteer basis), it is not unreasonable for Hums to have to cough up $100/an hour if he wants ot hire a consultant; and if Hums wants a good job done, Comp is going to spend a non-negligible number of hours working for him. Second, even if Hums is lucky enough to have grant money for his project (perhaps in the form of some seedcorn money, or a start-up grant designed to get DH projects off the ground and up and running), that grant money often comes with strings. When the Dictionary‘s base of operations moved to England, we were, naturally, quite interested in seeing what sorts of funds for starting up collaborations of this type were available. What we found is that many funding agencies specifically restrict recipients of their money from using it to pay consultants. So even if Hums has the money, he might not be able to use it to pay the people he’d need to pay.

In the end, the Dictionary has been incredibly lucky: We achieved our excellent infrastructure without any monetary outlay (The lack of monetary outlay is also why we don’t have too many bells and whistles yet: The whole Beggars Cannot Be Choosers thing!). But as we discussed on twitter last night, our experience is not one that generalizes easily:

So, what are some of the challenges Hums faces when trying to get a DH project up and running? (a) He may not know what he wants, or he may know but not know how to articulate it to Comp. (b) Finding Comp is difficult. (c) Comp’s agenda may not align with Hums’s. (d) Comp costs too much. Unfortunately, we have no good solutions to offer for these difficulties; the best we can offer are some reflections and questions:

  • Can we change the perception of the contributions of Comp to DH projects so that such collaborative work does count in the eyes of her academic/university colleagues? If collaborative outputs which genuinely further Hums’s research agenda was valued in the context of Comp’s research context, then it would be easier to find Comps who are willing to lend their skills to Hums.
  • How can we work with funding agencies and bodies to change their perceptions of the use of grant money for consultants, especially in the start-up phase? If Comps inside the university are hesitant to devote the necessary time to DH proejcts, the only other option is to go outside the university: And outside of the academic ivory tower, experts cost money. If you want to have a good product, you have to be able to pay for it.
  • The Dictionary benefited quite a bit from having a long incubation period: More than a year from inception to first creation, and that year involved a lot of protracted discussion, much of which happened in small increments and not at scheduled times. The fact that our Hums and Comp simply spent a lot of time in each other’s presence made determining the appropriate way forward significantly easier. How can this sort of experience be translated into more standard DH arrangements?

In this post, we’ve mostly focused on the problems facing Hums without any Comp; there are also problems that face Comp without any Hums. We make no promises, but we’ve got someone we’d like to tap for a guest post on this side of things! As we said, we don’t have any of the answers for these challenges, and many of these difficulties are not ones that a single person or a single project can change. But these challenges can only be surmounted if we get the conversation going, which we hope this post will contribute to.


Filed under technical

4 responses to “Digital humanities: Challenges, difficulties, reflections, and questions

  1. I also worked on a dictionary ( Thankfully, they already had the dictionary encoded in TEI so I only had to ingest into an XML database and us XQuery. However, I have been tangentially involved in the early stages of another dictionary (for Scots Gaelic). My main problems were around discussing very technical things that Hums think should be straightforward but are not. For instance, sort order. Sort order is set by the Unicode standard and trying to get people to understand that changing the sort order would be a *huge* undertaking that would involve most of the computer industry. Thankfully, I was able to head that discussion off.

    I think we need to change a few things but change is already happening so fast in UK around university that I very much doubt that anything will happen in the medium term. Very careful though about what the goals of the project are is the best way to get a good project. The other problem that I have, generally, is that funding comes in spurts and if funding runs out, bit rot inevitably sets in. You see this all the time in Comps when a paper comes out and the software is put on a web site then never, ever maintained (see Semantic Web and Linked Data for watching half written software for a single paper get abandoned).

    If you want, I can drop you my email and we can discuss lexicography software and XML editing off line.

    • I suspect you and our chief technical guru would have A LOT to talk to each other about sorting! Another thing that I would’ve thought would be simple but which turned out quite complicated was sort order not of words/letters but of dates. He ended up writing his own bison parser for them.

      I also agree that funding in spurts, or for individual subcomponents of a project in a significant problem that DH projects face. Most DH projects in order to be done well need to happen over a protracted period of time, and there needs to be continuity over that period — continuity of people, of methods, of machinery. Funding that comes in 1-3 year spurts is not conducive to this.

  2. Pingback: Digital Humanities: a fairy tale? (Guest Post) | Dictionary of Medieval Names from European Sources

  3. Pingback: The DMNES goes (went) to Luxembourg! | Dictionary of Medieval Names from European Sources

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.