DH09 Tuesday, session 4: collaboration, XML geekDOM, collaborative modeling
Oooh, late to the Julia Flanders talk, “Dissent and Collaboration.” I’ll do what I can.
We have an implicit contract with future scholars, who need to know how we did what we did.
Is there a conduit through which collaborative negotiation can take place? There’s data itself, potentially a schema for the data; hopefully documentation of both; and an implicit agreement (social contract) to use a common language, and to use it according to its accepted usage.
These agreements, in a human world where scholarly expression has a high value and standards are still being developed, aren’t enough to ensure perfect collaboration. So what we need is not a common language but a common mechanism for the creation of such a language. TEI provides this: it’s a mechanism not for collaboration but for the creation of a common language.
TEI is customizable in several ways.
- Subsetting: You can say I agree with the TEI representation of the world, and I am interested in this specific part of it.
- Vocabulary constraint: in your customization process, you can constrain things that TEI originally doesn’t constrain, for example the meaning of <div> — the TEI guidelines don’t specify this, but they give us space to do so.
- Renaming: you can rename elements and attributes to your heart’s content, as long as it can be translated back to TEI’s original tag set. That way, you still conform but have the space for differences in terminology.
- Extension: you can tack your own tagsets onto the TEI schema. This represents a difference of opinion with the TEI, and is properly put aside in its own namespace. (But there’s a namespace to put it in.) So it’s different from the three customizations above because it’s not, in fact, conformance.
All of these diminish, though don’t eliminate, the potential for conflict. Each project, through its customization, puts itself into a common space while registering its dissent.
Dissent is nothing new in the humanities. TEI, though, formalizes dissent, and bi-directionalizes it: dissent from the TEI can be expressed in a general –> specific direction, but can also be traced back.
The agreement is on the *possibility* of creating a data models that will satisfy everyone’s needs. The agreement is, implicitly, on utilizing the collaborative function of TEI.
For collaborative nirvana, we need tools that visualize TEI customizations, assess the degrees of difference between two TEI customizations, and also arrange customizations according to their levels of agreement with each other. And for these tools to *lead* to collaborative nirvana, we need more community guidance with regard to customizations themselves, which are too often only used and available for project-internal purposes. We also need more constraints on how customization files are written. [more and better standards!]
Lynne Siemens et al., presented by Ray and Lynne Siemens, “The Apex of Hipster XML GeekDOM: TEI-Encoded Dylan: Understanding and Reaching a Community of Practice (A Case Study).” [vz: hands down, my favorite paper title of the conference.]
Background: take a look at this fantastic video called “TEI Encoding of Dylan’s Subterranean Homesick Blues.”
The video [and putting it online, readily accessible, and using Google Analytics, Excel etc.] helped authors understand some more about the TEI community of practice, and in related communities of practice. The video could even be considered viral!
When the video widget was unleashed last October, the next day it was number one in Canada. For a little while, but still! Authors spent a bunch of time analyzing website visitor log data to figure out who was interested in this stuff. Besides TEI-C members, who are TEI practitioners, how do we attract possible members, etc., using viral marketing like the video proved (was, in fact, designed!) to be?
They collected benchmark data for the TEI website (?) for June-to-September, to identify (at the ISP level) who uses the website; and then analyzed October data in light of the benchmark data.
Many people looked at the video at home, not at work! Makes it kind of impossible to identify the institutions they’re associated with. So next time you look at the video, do it from your home institution!
In any case: who is out there, the ~60% of total visitors using and looking at TEI but not identifying themselves as TEI members?
In October, people mostly looked at the site from non-academic ISPs; and much larger and more geo.spread community than might’ve been originally thought.
So TEI learned a lot about the community that uses the site, both those who are involved formally and those who aren’t. This viral marketing project may be productively adaptable to other DH practice communities.
John Bradley, “No Job for Techies: Technical conributions to research in digital humanities.”
Humanities scholars still dismayingly use “techie” to imply that digital humanists are like car mechanics. Is there a problem with this? Where does innovation come from, in DH? How do we create an environment that encourages innovation and rewards it?
North American model for development: faculty *vs.* staff. Scholar brings ideas; staff enact/enable them. One person knows the subject area, the other knows the technology. The latter’s job is implementing the former’s vision.
Outside of North America, it’s clearer that the two are equal intellectual contributors. John works at the Centre for Computing in the Humanities in Kings College, London. The CCH is an academic department, full of staff who contribute highly intellectually significant work, which has both a teaching mandate and a research agenda. (So the “centre” moniker is a bit misleading.)
CCH research activities include both “traditional” research (e.g., John Lavagnino editing Thomas Middleton) and innovative, multi-year, externally funded projects. Tech staff is expected to do traditional research. Collaborative research happens between “home-discipline” specialists and computing humanists.
Kinds of technical and intellectual contributions to the humanities: document analysis; sophisticated user interfaces; modeling. Document analysis markup is an intellectual task, we are reminded. User interfaces and modeling have great potential to transform understanding, we are reminded. [vz: if only people outside of this conference took this for granted as well. I'm struggling with this at my own institution.]
John then presents the history and present state of the Online Chopin Variorum Edition, which I’ll let (and encourage) you discover for yourself. Yet another project that couldn’t have happened without significant intellectual contributions by scholars and CCH developers.
Who owns the models? Without [technical] modeling expertise, a humanities researcher probably wouldn’t be able to construct a good model, and without something to model, the digital humanist would have nothing to construct. Collaboration is essential there, and everyone benefits. Everyone’s thinking re: their area of expertise is augmented by the process.
In conclusion: digital resource building is a collaborative activity requiring different intellectually heavy areas of expertise. Turf wars are bad.