“The only
way my troops can come to respect your crew is to fight alongside them. Mixed
teams in every aspect of the mission.”
When this idea of mixed teams was put into practice, the Jem'Hadar showed even more wisdom when science officer Jadzia Dax questions one of them about his behavious:
“Am I
really that interesting? You've been standing there staring at me for the last
two hours.”
The Jem'Hadar answered with:
“You are part of my combat team. I must learn to understand your behaviour"
With this parallel in mind the most important elements for interdisciplinary collboration in a Digital Humanities context can be tackled:
1. Unlikely collaboration becomes likely when there is a common goal
2. Mutual respect and understanding is necessary for a succesful collaboration
2. Mutual respect and understanding is necessary for a succesful collaboration
3. Collaboration means working with each other, not next to each other
4. Yes, it is interesting to know what your team mate does and it is worth studying that (even though under normal circumstances it might be advisable not to do this by staring at each other for two hours).
5. It is important to understand each other, get to learn each others 'language' and customs. Even though biologically speaking humanities scholars and computer scientists are more related to each other than the crew of the Defiant to the Jem'Hadar, it still can seem that they come from different planets, have other customs and speak an other language.
5. It is important to understand each other, get to learn each others 'language' and customs. Even though biologically speaking humanities scholars and computer scientists are more related to each other than the crew of the Defiant to the Jem'Hadar, it still can seem that they come from different planets, have other customs and speak an other language.
These elements might seem to speak for themselves, but in practice quite some Digital Humanities projects encounter difficulties because the collaboration is failing. Are there really so many differences between the academic discplines then, except for the obvious statements that a computer scientist usually does not know much about historical source criticism and that a historian's mind tends to go blank when one speaks of RDF and ontologies? Is the academic approach to get as close as possible to the 'truth' not something which binds all academic disciplines? Possibly,
but there still are enough differences which make interdisciplnary collaboration something to get used to.
First of all there is the case of the self centered humanities scholar. Historians and their humanities brothers and sisters usually publish alone, or with a maximum of two or three people. They even think they can 'claim' a certain topic and it is the nightmare of many that someone 'secretly' is working on the same topic [1]. People who have in some way contributed to a book or paper are mentioned in a footnote or in a preface. Naturally, this entails the risk that people who are not mentioned feel intensely insulted. The writing itself is a fundamental part of a publication. The synthesis based on the presented, analyzed and interpreted sources do not only show the historian as a scholar, but also as a creative artist knowing his craft.
Things go quite differently in computer science. The way computer scientists work however, fits collaboratiuon in a digital humanities context much better. Computer scientists work and publish in teams. It is not rare that a paper knows seven, ten or even twelve authors. In practice this does not mean that all authors have actually written the paper or even read it. Usually only one, two or three people write a paper and the rest has contributed in discussions, has given suggestions or otherwise made a small contribution. As human nature predicts, conflicts arise here as well about being included in an author list or not. Writing has to be as structured as possible within established conventions. There is hardly any room for creative writing, especially not for the younger scientists who still have to prove themselves.
Then there also is the difference in the kind of publications sprining forth from humanities and computer science. Humanities scholars publish in a wide range of journals, in the Netherlands usually rated A, B or C.
These days only the A rated journals really count for the academic output, which involves double blinded peer review[2]. This peer review process takes several months when one is lucky, but with a bit of bad luck it takes six or twelve months before a decision is made on acceptance or rejection.
Computer science also knows a status difference in its publications, but journals are not the most common outlet for output (anymore). Usually publications are directly linked to the conferences where research is presented. You have demos, poster presentations proceedings of workshops et cetera. Contrary to the humanities publications of a lower status, almost all of these contributions are judged in a peer review process. This peer review knows strict time limits, connected to the dates of the conference for which the work was submitted. It also is much more common to publish work-in-progress, which makes the pace of publication faster, but also makes work outdated (by one's own work) quicker. The results of a conference usually are published online. Scientists also know journals ( with journal papers) with a similar peer review process as the humanities. Usually journal papers are considered most valuable.
Because in the past collaboration in a digital humanities context has not always been succesful, there even are publications on that topic, like the article of Lynne Siemens in Literary and Linguistic Computing 24 [nr. 2 (2009) 225-233] with the telling title:‘It’s a team if you use “reply all”’: An exploration of research teams in digital humanities environments’. [3] On the basis of a survey filled in by a quite meagre number of (12) people in digital humanities projects, she points among other things to the following elements which are important for the success of a project: a 'round' representation of all disciplines, a forced reflection on collaboration during the recruitment process, training in team work and techincal skills to be able to understand each other's work, and plenty of real life communication.
First of all there is the case of the self centered humanities scholar. Historians and their humanities brothers and sisters usually publish alone, or with a maximum of two or three people. They even think they can 'claim' a certain topic and it is the nightmare of many that someone 'secretly' is working on the same topic [1]. People who have in some way contributed to a book or paper are mentioned in a footnote or in a preface. Naturally, this entails the risk that people who are not mentioned feel intensely insulted. The writing itself is a fundamental part of a publication. The synthesis based on the presented, analyzed and interpreted sources do not only show the historian as a scholar, but also as a creative artist knowing his craft.
Things go quite differently in computer science. The way computer scientists work however, fits collaboratiuon in a digital humanities context much better. Computer scientists work and publish in teams. It is not rare that a paper knows seven, ten or even twelve authors. In practice this does not mean that all authors have actually written the paper or even read it. Usually only one, two or three people write a paper and the rest has contributed in discussions, has given suggestions or otherwise made a small contribution. As human nature predicts, conflicts arise here as well about being included in an author list or not. Writing has to be as structured as possible within established conventions. There is hardly any room for creative writing, especially not for the younger scientists who still have to prove themselves.
Then there also is the difference in the kind of publications sprining forth from humanities and computer science. Humanities scholars publish in a wide range of journals, in the Netherlands usually rated A, B or C.
These days only the A rated journals really count for the academic output, which involves double blinded peer review[2]. This peer review process takes several months when one is lucky, but with a bit of bad luck it takes six or twelve months before a decision is made on acceptance or rejection.
Computer science also knows a status difference in its publications, but journals are not the most common outlet for output (anymore). Usually publications are directly linked to the conferences where research is presented. You have demos, poster presentations proceedings of workshops et cetera. Contrary to the humanities publications of a lower status, almost all of these contributions are judged in a peer review process. This peer review knows strict time limits, connected to the dates of the conference for which the work was submitted. It also is much more common to publish work-in-progress, which makes the pace of publication faster, but also makes work outdated (by one's own work) quicker. The results of a conference usually are published online. Scientists also know journals ( with journal papers) with a similar peer review process as the humanities. Usually journal papers are considered most valuable.
Because in the past collaboration in a digital humanities context has not always been succesful, there even are publications on that topic, like the article of Lynne Siemens in Literary and Linguistic Computing 24 [nr. 2 (2009) 225-233] with the telling title:‘It’s a team if you use “reply all”’: An exploration of research teams in digital humanities environments’. [3] On the basis of a survey filled in by a quite meagre number of (12) people in digital humanities projects, she points among other things to the following elements which are important for the success of a project: a 'round' representation of all disciplines, a forced reflection on collaboration during the recruitment process, training in team work and techincal skills to be able to understand each other's work, and plenty of real life communication.
The question rermains how in practice such a collaboration can be shaped in the most fruitful manner. When I applied for the BiographyNet project, a substantial part of the procedure was dedicated to how I saw my role in the project and especially how I envisioned the collaboration between me and and the computational linguist and the computer scientist. The project leaders, also with all disciplines represented, have done exactly what Lynne Siemens would have advised in that respect.
Another strong decision to aid collaboration was the placing of the three researchers in the same room. In many other projects everyone does his or her 'own thing' and then meets every once in a while. By doing so however, the creative potential in the work process is not fully tapped into. While for the individual researcher the best ideas usually come to him or her on the bicycle or under the shower, the best exchange of ideas in a team usually also comes on unplanned moments: during coffee breaks, when someone spontaneously sprouts an idea or when the clarification of a point of view by one team member leads to unexpected inspiration for an other team member.
A third wise decision made by the project leaders was to hire all team members more or less full time. Collaboration does not go well when the historian can appeal to the computer scientist once every week with a request to solve a software problem, or if the computer scientist builds beautiful things but only can get input every now and then.from the historian to know if it also makes senses to humanities scholars. Only with an equal input there also can be an equal commitment to the same goals and output. Mixed and round teams in every aspect of the mission therefore.
Finally, a (lay) interest in each other's specialties is imporant for collaboration. It is as the Jem'Hadar from the introduction said, it is necessary '[to] learn to understand your behaviour'. In practice this does not mean that the historian has to become a computer expert, or that the computer scientis needs to be able to learn sixteenth century hand writings, but it does mean that they have to know what the other discipline is about and what kind of practical and methodological issues team colleagues have to face. Some further education, with courses or by learning from each other, can be necessary to achieve that goal.
In practice such a collaboration will not always be possible. Many digital humanties projects are collaborations between multiple institutions, sometimes even across borders, which makes it logistically impossible to have everyone in the same room all the time. The necessary reflection on how fruitful collaboration can be facilitated most easily under the given circumstances however, is something project leaders should occupy themselves with from the very start of writing a research grant proposal, in order to increase the chances of a succesful digital humanities project.
Another strong decision to aid collaboration was the placing of the three researchers in the same room. In many other projects everyone does his or her 'own thing' and then meets every once in a while. By doing so however, the creative potential in the work process is not fully tapped into. While for the individual researcher the best ideas usually come to him or her on the bicycle or under the shower, the best exchange of ideas in a team usually also comes on unplanned moments: during coffee breaks, when someone spontaneously sprouts an idea or when the clarification of a point of view by one team member leads to unexpected inspiration for an other team member.
A third wise decision made by the project leaders was to hire all team members more or less full time. Collaboration does not go well when the historian can appeal to the computer scientist once every week with a request to solve a software problem, or if the computer scientist builds beautiful things but only can get input every now and then.from the historian to know if it also makes senses to humanities scholars. Only with an equal input there also can be an equal commitment to the same goals and output. Mixed and round teams in every aspect of the mission therefore.
Finally, a (lay) interest in each other's specialties is imporant for collaboration. It is as the Jem'Hadar from the introduction said, it is necessary '[to] learn to understand your behaviour'. In practice this does not mean that the historian has to become a computer expert, or that the computer scientis needs to be able to learn sixteenth century hand writings, but it does mean that they have to know what the other discipline is about and what kind of practical and methodological issues team colleagues have to face. Some further education, with courses or by learning from each other, can be necessary to achieve that goal.
In practice such a collaboration will not always be possible. Many digital humanties projects are collaborations between multiple institutions, sometimes even across borders, which makes it logistically impossible to have everyone in the same room all the time. The necessary reflection on how fruitful collaboration can be facilitated most easily under the given circumstances however, is something project leaders should occupy themselves with from the very start of writing a research grant proposal, in order to increase the chances of a succesful digital humanities project.
[1] I. Thomson, ‘My race not to be the second Primo’, in: M. Bostridge ed., Lives for sale. Biographers’ tales (Londen/New York 2004) 134-138.
[2] This does not necessarily mean however, that A journals are more strict in their acceptance policy or that they give better feedback to submitted papers
[3] See also the similar reflections of Patrik Svensson, 'Envisioning the Digital Humanities', Digital Humanities Quarterly 6 (2012) vol.1, part III.
Geen opmerkingen:
Een reactie posten