Last week I was in Athens organized by the DARIAH project entitled ‘Scholarly activity and information process’
This was principally about understanding the processes of research that an e-infrastructure – whatever that might be – underpins and supports. Numerous perspectives emerged on how such a process might be conceptualized; but I think what emerged as the common theme was definition, and how we define the things we are talking about. For example, a starting point for much of the workshop was John Unsworth’s conception of the ‘scholarly primitive’; building blocks of research which, in a 2000 paper, he defined as ‘Discovering, Annotating, Comparing, Referring, Sampling, Illustrating and Representing‘. Seamus Ross’s critique of this however conceived of these more as processes; whereas a primitive should be seen as something which engages more fundamentally with generating knowledge from ‘primary data’ (itself a thing which used to have a widely accepted definition but, I would suggest, is much harder to pin down in the digital age). One example he gave was ‘question forming’ – which, of course, is not a primitive aspect of research that is confined to the digital milieu. Simon Mahony from UCL developed this idea with a perspective on the titles of projects his students come up with – which rarely include an actual question, which defines how the work they will do will bring new perspectives.
For me, it was interesting that this question of ‘what is the building block of [digital] humanities research’ reflects so closely the discussion in the last year or so on e-science fundamentals. Both areas – digital humanities and e-science – I think, share a implicit desire to show that they are fully professionalized academic disciplines, which I have no problem with (despite my own suspicion that academic disciplines are themselves basically nineteenth century concoctions to make Oxbridge colleges look tidier). But the problem is always one of language and description. This also applies to research methods, as well as object of research. César González-Pérez’s very interesting presentation on methods, for example, introduced the idea of the ‘method fragment’, a particular way of approaching or manipulating information, which can be defined consistently, and linked to others in a non-linear way to describe an overarching workflow. (The non-linear bit is, I think, crucial). This agrees well with the position set out in a forthcoming paper in the proceedings of AHM2009 by myself, Sheila Anderson and Tobias Blanke, which utilizes Short and McCarty’s famous ‘Methodological Commons’ for the digital humanities. However, again we come back to the problem of definition and language. It is convenient and logical for us, as developers and providers of a research e-infrastructure, to conceive of the research process in such a way, but we also have to remember that an historian about to embark on a research project does not go to their bookshelf, take down the Big Bumper Book of History Research Methods, select one, and stick to it for two years. Even if such a book existed, and if it were fully comprehensive, footnoted, agreed by the history research community (the economic history community? Or political history? Or social history? Since when have academics every agreed about such things anyway?), they would select, choose, modify, ignore, change, make it up as they go along… and if an e-infrastructure gets in the way of that, it is doomed. I was also glad to have the opportunity to get off my chest a problem I have with the word ‘tool’ to describe a software application, interface etc… a hammer is not likely to give me ideas and thoughts on better and better ways to knock in nails. However, a piece of research software might – if it is any good – give me pause to think about how I approach data, and to think computationally about the knowledge I could generate by analyzing it. As Alexandra Bounia made brilliantly clear in her presentation – which invited us to think what research we would do if we were putting together a museum exhibition, and how we would do it and why – we are talking here about a whole lot more than acquiring, storing and distributing data. An obvious point maybe, but one that is too important not to be made explicitly in such discussions.