At a moment when Britain is anxiously debating its relationship to the Continent, the kind of story one chooses to tell about the nation’s past matters a great deal. According to recent polling, the area around Peterborough is the second most skeptical of E.U. membership in Britain. One archeologist at Must Farm told me that he and his colleagues sometimes joke about the contradictory narratives that could plausibly describe the former life there. “You could probably write either a Euroskeptic or a Europhile account of this site,” he said. One researcher might see an indigenous community that was closely tied to the landscape of East Anglia; another might see an outward-looking people linked to the Continent by its waterways. Archeology is always an encounter between a fixed past and a shifting present; we bring to it our fantasies, prejudices, and predilections—this year different from last year, next year different again.
Saturday, June 4, 2016
Bronze Age Britain and the "Brexit"
In an article from the New Yorker, describing the latest discoveries at Must Farm quarry near Peterborough in England, Charlotte Higgins reflects on the openness of the evidence toward the larger cultural narratives.
Saturday, April 30, 2016
anecdotally approximating the needs of digital humanity work
(The following is akin to the prologue of a future paper in the digital humanities, a motivator for my research and work.)
Biographically speaking, I am the embodiment of a digital humanities researchers, as I aspire to spend about half of my time in the digital world as a software engineer, and half of my time in the humanities, mostly working on problems of socio-economic history and its impact on religious thought. Moving in both of these worlds makes the disconnect between their tools and capabilities noticeable in a way that I find instructive for the efforts of tooling the digital humanities.
Assume I open my email inbox in the morning and find an email from my fellow software engineer Pace, who has difficulties with a piece of software that I am responsible for. For historical reasons, software engineers have termed these problems "bugs", and the process of bringing this issue to my attention is termed a "bug report". In her bug report, Pace will describe what she did, what the expected outcome was, and what happened instead. Software engineers have a standard method for dealing with these issue: we boil the "bug" down to a small program that verifies that the expected inputs produce the expected outcomes---we call that a "unit test"---and then tweak and modify the existing software until the unit test passes, that is, the program no longer exhibits the erroneous behavior. In doing so, good software projects draw upon their existing unit tests---long-running projects will have tens of thousands of these. Passing all unit tests ensures that eliminating one bug did not introduce any other issues: Primum, non nocere.
Assume that in the afternoon, when I check my other inbox, I find an email from fellow digital humanities researcher Paige. Paige just found a problem with one of the transcribed sources that I shared with her from the archival work that I did for my dissertation. The problem may be very small. Perhaps we can even sort out what the difficulty was and rectify it---the source may now be digitized and accessible on the web. But I have no quick and safe way to incorporate that correction into my dissertation, though it exists as a set of LaTeX files that are themselves easy to change. I have no representation of the argument that my dissertation is making. I have no way of verifying that incorporating Paige's correction is local and will not affect other claims that I make.
Of course, that situation is not very different from the one that I found myself in while writing the dissertation to begin with. It seems statistically implausible that there are no flawed steps in an argument spanning a dozen chapters, a couple hundred of pages and consisting of tens of thousands of words. No manager would hire a developer who wrote a program of that size and had checked its correctness only in their head.
Don't get me wrong: I love lemmatized POS-tagged corpora of major writers as much as the next guy does. But the main product of the humanities is arguments, and crucially counter-arguments, narratives that go against what the public already believes to be the case. Should we not devote the same care to them as software developers toward their code?
Biographically speaking, I am the embodiment of a digital humanities researchers, as I aspire to spend about half of my time in the digital world as a software engineer, and half of my time in the humanities, mostly working on problems of socio-economic history and its impact on religious thought. Moving in both of these worlds makes the disconnect between their tools and capabilities noticeable in a way that I find instructive for the efforts of tooling the digital humanities.
Assume I open my email inbox in the morning and find an email from my fellow software engineer Pace, who has difficulties with a piece of software that I am responsible for. For historical reasons, software engineers have termed these problems "bugs", and the process of bringing this issue to my attention is termed a "bug report". In her bug report, Pace will describe what she did, what the expected outcome was, and what happened instead. Software engineers have a standard method for dealing with these issue: we boil the "bug" down to a small program that verifies that the expected inputs produce the expected outcomes---we call that a "unit test"---and then tweak and modify the existing software until the unit test passes, that is, the program no longer exhibits the erroneous behavior. In doing so, good software projects draw upon their existing unit tests---long-running projects will have tens of thousands of these. Passing all unit tests ensures that eliminating one bug did not introduce any other issues: Primum, non nocere.
Assume that in the afternoon, when I check my other inbox, I find an email from fellow digital humanities researcher Paige. Paige just found a problem with one of the transcribed sources that I shared with her from the archival work that I did for my dissertation. The problem may be very small. Perhaps we can even sort out what the difficulty was and rectify it---the source may now be digitized and accessible on the web. But I have no quick and safe way to incorporate that correction into my dissertation, though it exists as a set of LaTeX files that are themselves easy to change. I have no representation of the argument that my dissertation is making. I have no way of verifying that incorporating Paige's correction is local and will not affect other claims that I make.
Of course, that situation is not very different from the one that I found myself in while writing the dissertation to begin with. It seems statistically implausible that there are no flawed steps in an argument spanning a dozen chapters, a couple hundred of pages and consisting of tens of thousands of words. No manager would hire a developer who wrote a program of that size and had checked its correctness only in their head.
Don't get me wrong: I love lemmatized POS-tagged corpora of major writers as much as the next guy does. But the main product of the humanities is arguments, and crucially counter-arguments, narratives that go against what the public already believes to be the case. Should we not devote the same care to them as software developers toward their code?
Friday, April 29, 2016
some early thinkers in the Digital Humanities
(mostly taken from here)
John Unsworth, now the CIO and Vice-Provost at Brandeis, wrote a lot about the digital humanities, some of it quite early, including musings on the use of knowledge representation and ontologies that mention John Sowa. Unsworth drew inspiration from a Randall Davis paper from AI magazine in 1993 on what knowledge representation is (PS version).
Stephen Ramsay's papers are not accessible from the old links on the DH-website; but his website links to the famous Writing-Programming-Writing dialogue (in four flavors), and has links to the paper on sketching dynamic action (StageGraph), and the 2011 book on Reading Machines, available on Amazon.
Edward Vanhoutte was a key player in the TEI initiative, writing an introduction to the effort and the consortium in 2004.
More such as Julia Flanders, Willard McCarthy, Jerome McGann and Martha Smith to be extracted later.
PS: Apparently even then, Ben(jamin) Ray had realized that the Salem Witch Trials material would make for a nice thing to put into a database, leading to the Salem Witch Trial Project at the University of Virginia in 2002. I thought we mentioned that at the 2007 proposal to NEH ....
John Unsworth, now the CIO and Vice-Provost at Brandeis, wrote a lot about the digital humanities, some of it quite early, including musings on the use of knowledge representation and ontologies that mention John Sowa. Unsworth drew inspiration from a Randall Davis paper from AI magazine in 1993 on what knowledge representation is (PS version).
Stephen Ramsay's papers are not accessible from the old links on the DH-website; but his website links to the famous Writing-Programming-Writing dialogue (in four flavors), and has links to the paper on sketching dynamic action (StageGraph), and the 2011 book on Reading Machines, available on Amazon.
Edward Vanhoutte was a key player in the TEI initiative, writing an introduction to the effort and the consortium in 2004.
More such as Julia Flanders, Willard McCarthy, Jerome McGann and Martha Smith to be extracted later.
PS: Apparently even then, Ben(jamin) Ray had realized that the Salem Witch Trials material would make for a nice thing to put into a database, leading to the Salem Witch Trial Project at the University of Virginia in 2002. I thought we mentioned that at the 2007 proposal to NEH ....
not drowning in digital humanities websites
There seems to be no shortage of them, to be honest.
There is even an Alliance of Digital Humanities Organizations to put them all under an umbrella. That alliance used to have an essay section that members of the MONK project recommended as a good introduction, but that can only be found in the Internet Archive/Wayback Machine. (They do have a cool list of publications, however.)
There is even an Alliance of Digital Humanities Organizations to put them all under an umbrella. That alliance used to have an essay section that members of the MONK project recommended as a good introduction, but that can only be found in the Internet Archive/Wayback Machine. (They do have a cool list of publications, however.)
digital humanities on Twitter
Courtesy of Doron Goldfarb a list of good Twitter handles for digital humanities, including a list by Martin Grandjean, who seems to be a key player in the Swiss DH scene.
https://twitter.com/ADHOrg
https://twitter.com/eadh_org
https://twitter.com/dhnow
https://twitter.com/DH_UniWien
http://www.martingrandjean.ch/
https://twitter.com/
https://twitter.com/ADHOrg
https://twitter.com/eadh_org
https://twitter.com/dhnow
https://twitter.com/DH_UniWien
http://www.martingrandjean.ch/
https://twitter.com/
Subscribe to:
Posts (Atom)