[Humanist] 24.275 getting involved

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Mon Aug 23 21:58:33 CEST 2010


                 Humanist Discussion Group, Vol. 24, No. 275.
         Centre for Computing in the Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Alan Galey <galey.lists at gmail.com>                       (241)
        Subject: Re: [Humanist] 24.270 getting involved

  [2]   From:    "Martin Mueller" <martinmueller at northwestern.edu>        (265)
        Subject: Re: [Humanist] 24.273 getting involved

  [3]   From:    James Rovira <jamesrovira at gmail.com>                      (24)
        Subject: Re: [Humanist] 24.273 getting involved

  [4]   From:    Doug Reside <dougreside at gmail.com>                        (71)
        Subject: Re: [Humanist] 24.273 getting involved

  [5]   From:    Patrick Durusau <patrick at durusau.net>                    (102)
        Subject: Re: [Humanist] 24.273 getting involved

  [6]   From:    Elijah Meeks <emeeks at stanford.edu>                         (8)
        Subject: Re: [Humanist] 24.273 getting involved


--[1]------------------------------------------------------------------------
        Date: Sun, 22 Aug 2010 17:16:59 -0400
        From: Alan Galey <galey.lists at gmail.com>
        Subject: Re: [Humanist] 24.270 getting involved
        In-Reply-To: <20100821210601.E900364B81 at woodward.joyent.us>

Dear Willard,

Like many questions about outreach, this one comes down to matters of
tone as much as matters of content.

The programming question has a parallel we could learn from in
literary studies and bibliography. Fredson Bowers famously crusaded
for bibliographical literacy amongst literary critics in books like
Textual and Literary Criticism (1959). That book is full of examples
that should make any literary scholar nervous about what he or she
doesn't know about editing. Bowers slays interpretational errors, and
the literary critics who made them, with with the zeal of a
Reformation polemicist. One could imagine a similar book today that
substitutes programming for bibliography, and media studies for
literary studies.

The trouble is, Bowers failed. Anglo-American literary studies, at
least, didn't experience any great upsurge of interest in textual
matters in the sixties and seventies as far as I'm aware. (Though
there were some brilliant editions and textual studies in that period,
mostly appreciated by other textual scholars.) There are several
reasons why Bowers's message didn't take, but the most pertinent for
us, I think, was his tone. Despite being eloquent and knowledgeable
about his subject -- and, I would argue, being right -- his tone
ranges from chiding to badgering, even verging on moral panic. (Ex:
"One can no more permit 'just a little corruption' to pass unheeded in
the transmission of our literary heritage than 'just a little sin' was
possible in Eden" [p. 8].) It's clear, also, that staking his argument
to the future of his own discipline limited his ability to understand
the other side. The resulting polemic is about as appealing as a Bill
O'Reilly marathon, only smarter.

If we want to persuade more mainstream scholars of the value of
programming, we need to do what McKenzie, McGann, McLeod (and many
whose names don't begin with "Mc") did for bibliography in the
eighties and nineties, when the upsurge of interest finally happened.
Mainstream literary scholars became interested in bibliography and
textual transmission because they saw good reasons to, not because
they were hectored into it. I'll bet that at the time, they didn't
feel they were simply living up to a professional competency; they
probably felt they were doing something new and exciting.

Humanities programming could follow the same pattern. If we can show
mainstream humanists how to do simple but cool things with programming
skills, and how to pick up those skills  inexpensively, the force of
natural humanistic curiosity should kick in. As Steve Ramsay said on a
Digital Campus podcast a while back, programming is just good for your
brain. We learn it not because we should, but because we want to. That
podcast, along with Matthew Kirschenbaum's Chronicle piece (linked
below), are two examples of getting the tone just right.

http://digitalcampus.tv/2008/04/21/episode-25-get-with-the-program/
http://chronicle.com/article/Hello-Worlds/5476

Of course, there are plenty of other barriers to "natural humanistic
curiosity" kicking in, but that's another thread.

All the best,
Alan

-- 
Alan Galey
Assistant Professor
University of Toronto
individual.utoronto.ca/alangaley/



--[2]------------------------------------------------------------------------
        Date: Sun, 22 Aug 2010 16:17:04 -0500 (CDT)
        From: "Martin Mueller" <martinmueller at northwestern.edu>
        Subject: Re: [Humanist] 24.273 getting involved
        In-Reply-To: <20100822200027.4290B664E0 at woodward.joyent.us>

I think the following is useful advice in any research project, whether digital or not:

1. Know your data
2. Know what it is possible to do with your data
3. Know what somebody else does with your data in your project

Turn those propositions into questions. If in the context of a digital project you
cannot answer the three questions with a reasonably firm 'Yes', stay away from that
project.

MM



--[3]------------------------------------------------------------------------
        Date: Sun, 22 Aug 2010 18:34:17 -0400
        From: James Rovira <jamesrovira at gmail.com>
        Subject: Re: [Humanist] 24.273 getting involved
        In-Reply-To: <20100822200027.4290B664E0 at woodward.joyent.us>

I find it amusing that the following two paragraphs appeared in the
same digest...

Jim R

1. The major reason digital humanities scholars need to understand the
programs that provide them with analyses is that those programs can be
operating incorrectly and the programmers may not know to check for
the types of errors that can occur when processing humanities data;
data which may be outside the scope of the types of programs they
normally use for text.

2. The authority the scholars of that time gathered through
meticulous, slow and inefficient work has been diluted by electronic
tools that allowed a broad range of less meticulous contemporaries (in
the best sense of that word) to achieve roughly equivalent results,
exact bibliographies, appropriate and complete quotations and neatly
formatted papers.

I agree with the first comment, by the way.  I think that every
scholar using a digital tool in any field needs to know something
about how the tool works and how it can go wrong.  I don't think that
this means every scholar using a digital tool needs to know
programming, though.

I think that some humanities scholars need to know programming and
that their knowledge is valuable for the rest of us.  I just don't
think that all humanities scholars need to know programming.

Jim R



--[4]------------------------------------------------------------------------
        Date: Sun, 22 Aug 2010 21:09:03 -0400
        From: Doug Reside <dougreside at gmail.com>
        Subject: Re: [Humanist] 24.273 getting involved
        In-Reply-To: <20100822200027.4290B664E0 at woodward.joyent.us>

I have trouble understanding the resistance some digital humanists
exhibit towards learning programming.

The humanities are big and broad enough that, as Jim points out, not
everyone need call themselves a digital humanist (just as not every
literature scholar must be a new historicist), but when someone takes
on the label, then why, for goodness sake, do we as a community have
patience with him when he not only does not know, but actually refuses
to learn anything about the technologies he is studying?  A radio
producer does not need to know the precise mechanics of the technology
she uses because she is using it as a tool, but a scholar of radio
technology should probably know about transistors and electromagnetic
spectra.

"Collaboration" is regularly thrown out as a common excuse for this
sort of willful ignorance, but it has become anathema to me when used
in the sense Parrish describes:
-----
"to ask programmers to do for you what they know how to do and what
would be costly and painful for you to learn--to learn to talk their
language but not to get involved in programming research or machine
research."
----
This is not collaboration; this is a master-servant relationship.
"Learn how to talk their language" (because of course, programmers do
not speak the genteel tounges of the humanities scholar) and "ask
programmers to do for you..."?  And what is the humanist doing for the
programmer?  Pumping data or contextual information into a database?
The work load in such an arrangement hardly seems balanced and is, at
least, unsustainable.  When the funding ends and the incentive for the
programmer to work with the humanist fades, such collaborations often
dissolve.  If the programmer really likes the project, she could
probably keep adding new data now that she knows the disciplinary
shibboleth's to feed to Google or WorldCat as search terms, but
without the programmer the humanist is left like the Celts with Roman
aqueducts they do not know how to extend or repair.

I find Peter's conclusion especially interesting and I think it
suggests a new model for digital humanities:
---
I have great hopes that the Google people and text miners in general,
who not only program but think in terms of Markhov chains (and about
20-30 other techniques) for extracting information from text,
(unimaginably vast quantities of text), can be brought to literature
easier than the current active cohorts of literature people can be
brought to mathematical modeling.
-----

When I reflect on the amount of time I had to devote to my major in
Computer Science as compared to my major (or even Ph.D.) in English I
think this is absolutely true.  Getting an interested computer
scientist situated in a humanities discipline would likely take much
less time than getting a humanist trained in advanced math (I say this
provocatively in the hopes that someone challenges my assumption and
experience).

The future of digital humanities may lie with technological
disciplines rather than humanities ones.  Digital humanists have
usually situated themselves in the humanities disciplines because
their passion lies with the humanities content area.  The result is
our DH culture of hacking:  usually amateurish work done without much
care for sustainability, extensibility, even code review/testing (and
in all of this I am the chief of sinners).  Useful work has been done
in spite of (or perhaps because of) this playful, informal, approach,
but if computer scientists could make digital humanities work
acceptable in their own communities (either through social change or
by finding the right research angle), we might it much easier to
answer the perennial challenge to point to significant new knowledge
our field has produced.

-- 
Doug Reside, Associate Director
Maryland Institute for Technology in the Humanities (MITH)
University of Maryland
b0131 McKeldin Library
College Park, MD  20742
(301) 405-5897



--[5]------------------------------------------------------------------------
        Date: Mon, 23 Aug 2010 06:17:37 -0400
        From: Patrick Durusau <patrick at durusau.net>
        Subject: Re: [Humanist] 24.273 getting involved
        In-Reply-To: <20100822200027.4290B664E0 at woodward.joyent.us>

Willard,

> Two comments on the discussion in Humanist 24.270,
> about getting involved.
> 
> First, understanding the algorithmic process step by step. This is 
> possible and possibly enlightening for simple programs but, I'd think, 
> not always, and for complex systems not at all. When a system becomes so 
> large and intricate that its behaviour cannot be predicted, what's the 
> point? I can see that understanding fundamentals of digital 
> decision-making from simple examples has great benefits for a scholar 
> who has never before translated some human task into software. 
> Understanding how these fundamentals apply to his or her scholarly 
> objects brings the lesson to life. But how about the situation, now 
> commonplace, when one simply cannot follow what the software system 
> does? 
> 

Translation into a programming language (or markup for that matter) may
result in greater precision in thinking about an issue, but then so
would translation into formal logic or even a classical language. That
claim is not exclusive to digital computing.

I am less certain what to make of your point that "...one simply cannot
follow what the software system does?" 

Do you mean as a lay person? 

There are situations where under-specified systems have unexpected
results but I am not sure why you would think that is relevant to the
current discussion? 

> Second, demonstrating (as we say) "evidence of value" to our colleagues. 
> Here I am especially interested in getting help with thinking through 
> the problem. It is a complicated one. And I wonder, after six decades 
> why do we have this problem? Isn't it worth asking why we ask a question 
> as well as immediately falling to answer it? 
> 

A worthy question but not what provoked my response. In your original
post you were objecting to our colleagues seeing computing as a
mechanical activity and said:

> *our objectives* in using it aren't limited by getting from A to B.
> *We* want both the "B" and the "getting" to be dynamical, evolving
> processes. 

With emphasis added, it illustrates the problem rather neatly.

Our colleagues have their own goals, methodologies, customs, etc., for
their various disciplines.

Unless digital computing can be shown to either advance some goal they
already seek or to offer some advantage (that they recognize as an
advantage) they presently lack, one can hardly blame them for their lack
of interest. 

On what other basis would you interest someone in digital computing?
That we think it is important? That hardly seems like a compelling case.
Even though I have spent a couple of decades in its pursuit and feel no
reason to rue the time spent. If anything, I think the best times for
digital humanities lie ahead of us. 

> I wonder what demos are for, especially why they don't work 
> particularly well in the research setting, why hands-on is so crucial.
> 
> Of course we need to be better explainers. We in the humanities aren't 
> practiced in the arts of explanation to non-specialists. Until recently, 
> I think, we didn't see it as a priority at all (unlike the natural 
> scientists, who have poured enormous and intelligent efforts into 
> popularisations). But in addition to assembling an array of success 
> stories to back up our claims, experience suggests to me that people 
> don't get it until they can internalise the demonstrated process and 
> re-imagine it in terms of their own materials. The question is not 
> simply relevance but relevance to what? It often isn't sufficient to 
> show, say, a concordance to a Latin text when the person to be persuaded 
> works with German ones -- German, after all, works differently. I 
> wouldn't assume that the Germanist is being stupid, only that his or her 
> imagination hasn't been contacted. Or suppose the Germanist does see the 
> point of concording. If that sort of process doesn't fit into how the 
> research has been conceived, then concording might not seem relevant. 
> Indeed, it might not be at all. But thinking about the project 
> algorithmically from the get-go, imagining it in those terms, then 
> implementing it should (I think we want to argue) be one possibility the 
> Germanist has to hand. If our objective is to increase the range of 
> human possibility well beyond what we individuals know how to do, then 
> don't we need the help of people who think other thoughts in other ways? 
> Even a demonstration of how to drive a car or ride a bicycle doesn't get 
> the novice very far.
> 

I certainly agree that learning from others who think differently than
we do is always a good thing. Whether than leads us towards or away from
digital techniques in the humanities. It is simply an enriching
experience.

Where I disagree is with the apparent presumption that every humanities
project should begin with algorithmic design. If it involves digital
computing it had better but I suspect that is a fairly small percentage
of all humanities projects. Depends on which discipline and tradition. 

Do you know of any surveys by discipline, political science, sociology,
English, etc. of the use of digital computing? Just curious.

Thinking looking at where digital computing is or is not used might make
our discussions more specific.

Hope you are at the start of a great week!

Patrick
-- 
--
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau



--[6]------------------------------------------------------------------------
        Date: Mon, 23 Aug 2010 09:44:16 -0700 (PDT)
        From: Elijah Meeks <emeeks at stanford.edu>
        Subject: Re: [Humanist] 24.273 getting involved
        In-Reply-To: <20100822200027.4290B664E0 at woodward.joyent.us>

Willard, I'm curious as to which large software you're speaking of that becomes so complex as to be unpredictable.  I'm not sure that scholars should be using tools that are black boxes, where they throw in their works and let some strange algorithm play with it to produce interesting reinterpretations.  I'm also not sure that there are such systems.  While I cannot, as Jim can, perform my work with a pad of paper, a library and a writing utensil, I do understand that when I plot a hundred points on a historic map and have ArcGIS rectify that map, that it is creating a spline, based on the variety of differences between the historic map and the modern map.  I would be incapable of doing this math by hand and then applying the results to the re-creation of an artistic representation of geography (much less have the artistic ability to paint the new map--something that some folks still can do with a pad of paper and a pen but most of which cannot if divested of their Photoshop).  However, I do understand the process.  I understand the manner in which the software is aggregating the points and calculating the results.  I understand the vagaries of political geography and the problems of historical change versus evidenciary gap.  I could not write the software that does this, and when it comes to the higher level mathematical functions I doubt I could even write an effective script of any complexity, but I comprehend the tool.  I don't simply wait for the box to return it's interpretation.  Likewise, I know that data models have inherent claims, that XML and JSON, while convenient, are also rigid.  That does not mean that I do not use them, but it does mean when I do use them I understand how they function, even if I, myself, may be incapable of creating a new standard.

To return to my foreign language analogy, while a student of the classics is expected to read Aristotle, they are not expected to write Aristotle.  I agree with Jim that there are still areas of the humanities that do not require algorithmic media and therefore do not require algorithmic literacy, but in the areas where the former is true, the latter is also true.

Elijah Meeks
Digital Humanities Specialist
Academic Computing Services
Stanford University
emeeks at stanford.edu
(650)387-6170





More information about the Humanist mailing list