Monthly Archives: October 2010

What is the object of the Digital Humanities?

By which I mean on one level, what is its purpose?, and on another, what is its field of study?

In an earlier post on this blog I listed what I saw as the major subdivisions of the discipline, such as it is, and opined that at the CCH as presently constituted we mostly focus on realising traditional humanities ends in a digital fashion. That is to say, digital humanities as we practice it tracks the other humanities disciplines pretty closely, and ultimately we’re “about” the same things that they are.

There’s a lot to be said for this approach. There’s no question in my mind that most of the scholarly genres — even those most firmly rooted in natural language as a medium — are better realised in electronically than in print. But if that was all there was to the digital humanities — the humanities, but in a more convenient and useable form — then I don’t think I would have bothered switching out from the thoroughly-traditional Classics track my PhD had prepared me for. Because this seems to me an approach to DH that belongs more properly to scholarly publishing than scholarly research.

For me, what differentiates digital humanities from other humanities disciplines and gives it some kind of distinctive value of its own only arises when it turns reflexive and experimental: when it takes as its objects of study not simply those taken by other disciplines, but starts exploring the effects and potential of digital remediation of these objects. When it starts trying to stretch the affordances of the medium and the data and examining their interaction. In other words, I’m interested in the digital humanities in the same way that Vannevar Bush was interested in hypertext, back in the ’40s. As a way of exploring new ways of thinking and understanding. Of reconceptualising our knowledge of our field of study.

To anyone with a memory that encompasses more than a decade in this field, all this will sound wearyingly familiar: do we remember all those many, many unread articles whose titles promised a radical hypertext revolution in the novel/the essay/narrative-modes-of-thought/whatever with the advent of the web?

But the problem with this entire (now-vanished) genre of research wasn’t, to my mind, that its motivations were incorrect. It’s that it was insufficiently experimental. As far as I could ever tell, they were almost always purely theoretical: based, almost all of the time, of a skimming of a McLuhan (or one of his epigones) mixed in with a soupcon of Foucault, Derrida, or, more often than not, Baudrillard. There was never any engagement with the medium, its message, or the material itself.

But here, at the CCH, we have the opportunity to work up close and intimately with the corpus of humanities knowledge, and the skills  to shape and experiment with it using digital technology. We’re in the right place, in other words, to start exploring. And this, to my mind, is what constitutes the purpose of the digital humanities: to create new tools that allow us to open up new understandings. To think better, and think different.

If, of course, we can ever find the bloody time.

Diigo – useful Cloud-based web annotation tool

I’ve been playing around with Diigo and using it for making annotations online. Not specifically a humanities tool – but intersecting with some of the things we do here.

I’ve yet to play around with any of the community/collaborative features. But I’ve found the basic annotation toolset easy to use and fantastically helpful. V. good in particular for the early stages of research when you’re skimming pages for starting salient points.

Programming and Digital Humanities

In August this year, there were two almost consecutive threads on the Humanist mailing list that I found rather disturbing. The first, with the subject “getting involved”[0], seemed to reach a semi-consensus among its participants that digital humanists should be able to do some programming, at the least. In the second, with the subject “designing an academic DH department?”[1], people gave their views on the ideal makeup of such a department. Here’s part of one response, from[2]:

I would see it as involding two clusters of people. The digital
humanists and the computer technologists / engineers who were employed within the digital humanities group as dedicated to that group itself. Roughly, I’d see a ratio of 1 computer / engineering professional to 5 or so digital humanists…

[I]n the traditional university environment, where you’d have separate computer science/engineering departments and a digital humanities department […] you’d wind up with the digital humanities having just computer support staff and the computer science/engineering departments having the truly creative people. That is, the best minds in computing & engineering wouldn’t be thinking about digital humanities ideas unless for some reason the computer science / engineering departments happened to pick up someone with those “outside” interests.

So this department would have five digital humanists getting the one creative computer scientist to implement all of their ideas, while s/he also does his/her own research and implementation? What exactly makes the humanists “digital”, then? And why would a creative computer scientist want to be the dogsbody of the group?

And from Darren Harkness[3]:

For an active DH department of 12-24 scholars, I would likely recommend a minimum of two developers, ideally split between highly structured languages such as Java and Python and less structured languages like PHP and perl as a way to cover most of your faculty’s needs. I would likely recruit a senior Java developer and a junior web developer with good research skills.

Am I simply reading these messages incorrectly, or is actual development/programming not what digital humanists do, in spite of the rhetoric? The ratios, in particular, don’t speak of the technical people being considered as anything like equal colleagues. This feels, to me, like a big problem.

[0] Both this and the later thread are available in the Humanist archive, though why a mailing list in this day and age doesn’t have threaded, dated, and searchable archives is beyond me. The first post in the “getting involved” thread is dated 19 August 2010.

[1] First post dated 1 September 2010.

[2] Message-Id: <>

[3] Message-Id: <>

A taxonomy of the Digital Humanities?

There is already a non-trivial number of Digital Humanities blogs out there, and I think it’s probably fair to say that many of them blacken a lot of pixels in blogging about what the field actually is, or what it means. But curiously, despite the very large number of answers that have been formulated to these questions, I’ve never seen any that attempt to answer them in the most basic way — that is to say, by simply cataloguing the various things that people who call themselves, or get labelled as, ‘Digital Humanists’, actually do. Which I find curious, as the  activities that get lumped together under this rubric seem to me pretty diverse.

Off the top of my head, I’d say the field is often held to include:

  1. Digital preservationists: people who are interested in making sure digital artefacts aren’t lost in the future, whether out of concern purely for informational integrity (the folks at LOCKSS), or because they’re cultural curators in some sense.
  2. Cultural commentators: people who are interested in the effects or impact of digital technologies on (usually) mainstream culture, dealing with questions ranging from online identity to ethics and privacy concerns.
  3. Scholars with traditional scholarly ends who find that these are best realised by digital technologies. This group is of course in itself very varied.
  4. Philosophers interested in issues such as philosophy of mind, artificial intelligence, singularity theory, or any other of a range of issues that are most readily discussed within a digital/technological frame of reference
  5. Computer scientists and/or developers who take traditional humanities domains as their targets.
  6. Digital artists, exploiting the computer as a medium.

Does this seem like a comprehensive list? Is it, perhaps, too broad? And can these groups all be considered to share sufficiently similar interests to form a community (or, for that matter, even to read a blog such as this?) Is it useful to try to address all of them?

My own feeling is that at the CCH we mostly do (3), with a bit of (5). (1) , (2), and (6) are mostly out of our purview, but I suspect a lot of us forage around in (4) as much as we can. Is this a fair characterisation? Is it a problem?

Knowledge Representation workshop @ CCH

A couple of months ago or so we started a Knowledge Representation workshop with a few enthusiastic colleagues at CCH. The basic idea is to take a broad perspective on the various topics related to KR, and then focus on the digital humanities so to see how these approaches and technologies can be best applied to our domain.

What is a knowledge representation? Although knowledge representation is one of the central and in some ways most familiar concepts in AI, the most fundamental question about it–What is it?–has rarely been answered directly. Numerous papers have lobbied for one or another variety of representation, other papers have argued for various properties a representation should have, while still others have focused on properties that are important to the notion of representation in general. [continue reading]

Other than that, the scope of the workshop will remain deliberately unspecified so that we are allowed to decide session after session what topics should be discussed. I’ll be posting the slides and research produced in the context of the workshop on this blog, so maybe also others will be interested in taking part in this (either physically or electronically!). if you do, please get in touch 🙂

The slides from our first meeting can be found online on slideshare:

Screen shot 2010-10-13 at 14.59.30.png


Among the TOPICS that emerged as needing more reflection:

  • the ontoclean methodology: need more examples and rationale for each of the meta-principles
  • top level ontologies: is it sensible to aim for having only one? If not, what does a ‘relativist’ position entail?
  • the cyc project: why didn’t it conquer the world? where were its flaws?
  • ontologizing ‘humanities’ data: is the subject domain posing specific challenges, or not?
  • implementing an ontology: what are the languages/frameworks available? (we mentioned the possibility of inviting an external speaker on this topic, some time in the future)
  • Finally, some useful bibliography:

  • Doug. Ontologies: State of the Art, Business Potential, and Grand Challenges. Ontology Management: Semantic Web, Semantic Web Services, and Business Applications (2007) pp. 1-20
  • Sowa. Knowledge Representation: Logical, Philosophical and Computational Foundations. Course Technology (1999)
  • Niles and Pease. Towards a Standard Upper Ontology. FOIS’01 (2001)
  • Doerr. The CIDOC conceptual reference module: an ontological approach to semantic interoperability of metadata. AI Magazine archive (2003) vol. 24 (3) pp. 75-92
  • Gangemi et al. Sweetening Ontologies with DOLCE. 13th International Conference on Knowledge Engineering and Knowledge Management (EKAW02) (2002)
  • Smith,. Beyond Concepts: Ontology as Reality Representation . Proceedings of FOIS 2004. International Conference on Formal Ontology and Information Systems (2004)
  • Guha and Lenat. Cyc: A Midterm Report. AI Magazine (1990) pp. 1-28
  • Gruber. It Is What It Does: The Pragmatics of Ontology. Invited presentation to the meeting of the CIDOC Conceptual Reference Model committee (2003)
  • Doerr. The CIDOC conceptual reference module: an ontological approach to semantic interoperability of metadata. AI Magazine archive (2003) vol. 24 (3) pp. 75-92
  • Guarino and Welty. Evaluating ontological decisions with OntoClean. Commun. ACM (2002) vol. 45 (2) pp. 61-65
  • Stay tuned for the future reports!

    Mixing and matching SVG and Text

    One of the happier side-effects of the recent Apple vs. Adobe fracas is that it has led to the widespread rediscovery of Scalable Vector Graphics as a means of displaying illustrations and animations on the web. Long the poster-child of standards nerds, SVG was a spec I’d heard of before – but only in contexts that suggested its sole raison d’etre was to be yet another standard with which to beat IE6 over the head for not implementing. I’d looked into it, briefly, back in 2003 or so – but the syntax was forbidding (XML isn’t offhand the format you’d think best suited for describing graphics) and the documentation unfriendly to the point of absurdity. I didn’t think of looking at it again until I started thinking a bit about visualisations for humanities data, and needed a cross-platform iDevice-compatible animation medium.

    And what a happy rediscovery that was: clearly, I owe the standards nerds an apology. There are now a couple of good Javascript libraries available for SVG (Raphael and a JQuery plug-in) that fix all the x-browser problems for you and help smooth away SVG’s awkward XML-ness – which is, furthermore, nowhere near as difficult as I’d concluded it was all those years ago. The spec is (reasonably) small, supple, and does what you want it to with a bare minimum of muss and fuss. All that and SVG elements exist within the DOM – meaning that, unlike children of the <canvas> element, you can access them using standard JS traversal methods, trigger events affecting the rest of the page with them, etc.

    In fact, SVG would be pretty much perfect for creating highly interactive, data-intensive pages – were it not for the way it handles text. There is a text element in the SVG spec – but it doesn’t do what you want it to: i.e., style or wrap like HTML text does. And the workarounds are horrendous.

    After a bit of Googling I discovered what seemed like a solution: the svg:foreignObject element can wrap non-SVG objects, and I was assured that in this way I could simply drop HTML content into the middle of my SVG code and all would be well.

    Except, of course, that it wasn’t. In place of the lovingly-prepared HTML content I’d been expecting to appear in the middle of my screen, I got nothing. Nada. Nyet. Zip. Zilch. Nothing. And upon tracking the foreignObject examples back to their lair, I saw the reason why: while Raphael and JQuery assume that what you’re trying to do is drop SVG elements into the middle of a standard HTML page, foreignObject code only renders properly in all browsers tested if the page is served with MIME-type svg. Which of course then banjaxes every standard HTML element you’ve got on your page, i.e., most of it.

    It seemed, for an embarrassingly long time, like this was a show-stopper, before the key to the solution occurred to me – that there’s absolutely no reason why the HTML elements ‘within’ an SVG graphic need to be children of the SVG element itself. Using Raphael (and presumably JQuery, though I haven’t tested this), your first step is to define the area that will hold your SVG graphic by specifying its coordinates (x and y) and dimensions (width and height). After that, you’re probably going to spend some time positioning graphical objects within this area, using the same metrics. And at that point you’ve got all the information you need simply to append your HTML elements after the SVG outer element and position them absolutely ‘inside’ it.

    It’s so ridiculously easy I’ll repeat that again: don’t bother with the workarounds in SVG. Just position your HTML absolutely and on top of it.

    This is, admittedly, a kludge – but it works, it’s easy – and it lets you spend all the time you would have wasted trying to get the svg:text and svg:tspan elements working across different data actually working on the visualisation.