15.050 obstacles to humanities computing

From: by way of Willard McCarty (willard@lists.village.Virginia.EDU)
Date: Sat May 26 2001 - 01:39:05 EDT

  • Next message: by way of Willard McCarty: "15.051 "internet researcher""

                    Humanist Discussion Group, Vol. 15, No. 50.
           Centre for Computing in the Humanities, King's College London

       [1] From: Patrick Durusau <pdurusau@emory.edu> (67)
             Subject: Re: 15.044 obstacles to humanities computing

       [2] From: Adrian Miles <adrian.miles@bowerbird.rmit.edu.au> (47)
             Subject: Re: 15.045 obstacles (and propellers) to humanities

       [3] From: lachance@chass.utoronto.ca (Francois Lachance) (46)
             Subject: Words in the Mouth

       [4] From: Igor Kramberger <kramberger@uni-mb.si> (60)
             Subject: use of software

             Date: Sat, 26 May 2001 06:30:10 +0100
             From: Patrick Durusau <pdurusau@emory.edu>
             Subject: Re: 15.044 obstacles to humanities computing


    Charles Faulhaber's response to the comments so far:

    > The comments below all miss the obvious. Humanities computing has been a
    > tiny sub-discipline for going on forty years. It will probably continue to
    > be a tiny sub-discipline for a long, long time. But it could have an
    > _enormous_ impact on main-stream scholarship if its devotees could find
    > some way to harness their considerable expertise and make it available to
    > the _much_ larger world of scholars who regard computers as necessary
    > evils but are quite willing to make use of them if it makes what they
    > _really_ want to do easier and faster and allows them to answer more
    > interesting questions.

    raises an important issue about the work of computing humanists.

    Yes, let's call a plague down on the heads of the computer scientists
    who practice master/disciple relationships, but also on the humanities
    where they stole the idea. But criticizing someone for acting like
    ourselves does not answer Faulhaber's request.

    Nor am I persuaded by Kirk Lowery's suggestion that new Ph.D students
    should know things like Perl (a programming language) and regular
    expressions (crudely put a syntax for searching texts). Both of those
    are things that I have and continue to devote time to but that does not
    mean that they are essential components for a PhD in the humanities. (I
    note that Glendon Schubert, _The judicial mind revisited : psychometric
    analysis of Supreme Court ideology_, Oxford, 1974, taught himself
    multivariant factor analysis on a Friden rotary calculator. I don't
    think anyone would contend that mastery of the rotary calculator is
    relevant for humanities computing today.)

    Humanities computing is still a very young discipline and many of us
    work very "close to the metal" as it were in developing tools and
    applications. I hear Faulhaber's request as a call to create tools that
    allow humanities scholars to use the results of our labors without
    serving as apprentices in areas removed from their main subject matter
    interests. I don't have to be able to create a text editor to use one,
    why should I be able to create a heavily encoded text to use the fruits
    of such an effort?
    Understanding the markup will make me a better user, but shouldn't that
    come after I have found the tool a useful one?

    For example (this does not exist, yet!), consider an electronic version
    of the Hebrew bible that displays a standard base text. By choosing menu
    options, scholars can display other versions (read manuscript witnesses)
    either as the main text or as a critical apparatus. On choosing other
    menu options, scholars can record structures they see in the text, which
    is immediately formatted to display that structure (menu driven display
    options) and after marking several such structures, they can be compared
    against each other or sent to other scholars. Morphological, syntactic
    information and comparative materials are available through other menu
    options. The program dynamically updates the information that can be the
    subject of searches or analysis based upon the information provided by
    the scholar. Statistical analysis is also available through a set of
    menu options.

    Working very close to the metal to build such an application, one would
    need to know all manner of technology not strictly relevant to mastery
    of the subject matter material. But the non-computing humanist Hebrew
    scholar should not have to care whether I can used SGML's concur,
    TexMECS or some other markup technology to encode the textual variants.
    That knowledge is useful to help add to the construction of such tools
    but it should not be a green card to access the fruits of our labors.

    I think Faulhaber is correct in thinking that spreading the use (and
    perceived relevance) of computers in the humanities depends upon us
    making applications that are easy to use by non-computing humanists.
    (Witness the spread of the PC if you require a historical demonstration
    of this strategy.)


    Patrick Durusau
    Director of Research and Development
    Society of Biblical Literature

    --[2]------------------------------------------------------------------ Date: Sat, 26 May 2001 06:31:41 +0100 From: Adrian Miles <adrian.miles@bowerbird.rmit.edu.au> Subject: Re: 15.045 obstacles (and propellers) to humanities computing

    At 6:15 +0100 25/5/2001, Humanist Discussion Group wrote: >Ideally, then, a brand, spanking new humanities PhD *minimally* ought to: > >1. Be able to write programs to manipulate text, and to be able to create > and manage databases. This implies knowledge of: > a. the Perl programming language > b. Regular expressions > c. How programs can be "hacked" together from pieces of code lying > about the net >2. Be able to collaborate with others. This implies knowledge of: > a. Web authoring (and HTML/XML) and markup > c. "Groupware" allowing networked collaboration

    to enter into the spirit of Charles' comments and what the above, for me, completely assumes:

    that computing humanities apparently has little or nothing that it wants to say about: painting sound still image moving image digital images the cinematic the televisual new media

    i think my very general question, as someone in cinema studies with computers, is why are these major cultural forms of the last 100 years largely invisible *to* computing humanities? Is computing humanities primary concern with the static and stable textual object (manuscript, etc)? Why doesn't it seem to have much to say about these things?

    how does this relate to Charles' comments? I'm not actually sure :-) except I think i do humanities computing because i use computers to do things in the humanities that can't be done without computers. but i don't see how that statement implies I *must* know Perl or even a formal programming language.

    I think what you all do and describe is a pragmatics of computing where you know how to pragmatically assemble what you need to get to where you need or want to try and get to. (emacs or not, who cares?). this is the skill that humanists (great creative lateral thinkers all) bring to computers (great think linear dumb machines) to apply to their object of study. its about this is a process, not what brands have to fit in that process.

    just .05 cents worth (we got rid of the 1's and 2's in our currency here a few years back....)

    cheers adrian miles --

    lecturer in new media and cinema studies + media studies. rmit [http://hypertext.rmit.edu.au] + institutt for medievitenskap. university of bergen [http://media.uib.no]

    --[3]------------------------------------------------------------------ Date: Sat, 26 May 2001 06:32:04 +0100 From: lachance@chass.utoronto.ca (Francois Lachance) Subject: Words in the Mouth


    Nice to see your request for gift (a propeller-enhanced beanie) sandwiched between other messages. Very astute placement --- not too forward by being the first and a nice break with tradition of moderator privilege of last spot in the list of messages. It is by chance that I had read of Merrilee Proffitt's success in locating a supplier of the soon to be cherished item before I read the bundle of messages containing your request and so it probably influenced how I read Dr. Donald J. Weinshank's anecdote of the Unix MAN search.

    > > Example: I was trying to number pages printed from > a file on a UNIX operating system. After trying > every source of help on UNIX (the syntax is > MAN (whatever) where MAN is short for "manual"), > I asked a colleague how to do this. Without > breaking stride, he replied, "MAN enscript," where > "enscript" is the name of the utility I needed. > > Computer scientists say, "UNIX is the only > operating system taught by word-of-mouth."

    Is that "taught" in the present tense? or the past?

    The anecdote doesn't say if at any point the searcher considered to eavesdrop on the conversational traces offered by the World Wide Web.

    A simple Boolean search on the string "Unix NEAR printing NEAR page" matches a number of pages which then can provide the vocabulary for a MAN search or for further refined searches of the WWW.

    I am very grateful for the anecdote since I have done some work on the pedagogy of reiterative searching

    Reading and Searching: Tools and Skills http://www.chass.utoronto.ca/~lachance/tcon2000.htm

    but never quite made the connection of usings the search results from one domain (e.g. the WWW) to glean keywords for the search of another domain (a manual, a library catalogue). I have had students share and comment on each other's search strings. I am also aware that document management systems such as PCDocs (recently bought by Hummingbird) allow users to save queries and use them to (re)search repositories and to swap queries with other users. The informing metaphor is moving away from a folder system to a constellation or kniting one's own utterance (a question) form the bits and pieces of stardust conversation one has collected. Is it now wonder that pollination and cross-pollination follow from browsing or as, I believe, has been pointed out on Humanist before, what the French call "butiner".

    Hum with your MAN -- wonder the Web.

    -- Francois Lachance, Scholar-at-large http://www.chass.utoronto.ca/~lachance 20th : Machine Age :: 21st : Era of Reparation

    --[4]------------------------------------------------------------------ Date: Sat, 26 May 2001 06:32:53 +0100 From: Igor Kramberger <kramberger@uni-mb.si> Subject: use of software

    Hi to all:

    Willard McCarty wrot on May 9th: > I would be most grateful for pointers to articles and books on software > design that focus on analysis of pre-existing artefacts.

    and Kirk Lowery wrote on May 25th: > Ideally, then, a brand, spanking new humanities PhD *minimally* ought to: > > 1. Be able to write programs to manipulate text, and to be able to create > and manage databases. This implies knowledge of: > a. the Perl programming language > b. Regular expressions > c. How programs can be "hacked" together from pieces of code lying > about the net > 2. Be able to collaborate with others. This implies knowledge of: > a. Web authoring (and HTML/XML) and markup > c. "Groupware" allowing networked collaboration I think that we should narrow what a humanist should be doing with his/her computer -- computer is a tool and I do not produce first a hammer to be able to use it later.

    Comments: 1.a. I think that Perl is fine, but that general implication could be that we need some knowledge about scripting languages: Python, UserTalk (for Frontier), Tcl (look at Alpha and AlphaTk editors) -- which is not comparable with the C/C++ programming.

    1.b. Yes, GREP is fine -- but only as long as you have to deal with texts in English. Or: how would you use GREP for a document written in Hebrew?

    1.c. I do not think that there is a real difference between 1.a and 1.c -- as every (La)TeX user knows, who is editing the configuration files.

    What is more important, is, how to use all the options in an application you use every day. Here is my story.

    For the bibliography of the first 50 issues of the review "Otrok in knjiga " (Child and book) we used Nisus Writer as a word processor. This allowed us to use very free form for every bibliographical entry which is divided into three parts. Later we added at the end of each entry the number variable. We marked every entry for several indices -- for a short time we turned every entry into a page, so we had the same number as the last number variable and as pages. We produced indices which relate to the entry number and returned to the full page of entries (entries divided by two returns).

    Using GREP and some markup we could transform the huge source file, in which all articles were described from the first issue until the last, in 12 minutes into a bibliography with different sections according to the markup.

    Bibliography is now printed -- but every interested person could get a file for find / search purposes using strings of literal characters or GREP.

    Finally, some years ago two persons in Australia developed Palimpsest -- an application which supports creation of hyperlinked documents from an array of text pieces. The user defines the windows for the text input. Every window can be hyperlinked with every other window -- in one direction or in both directions. Links can be annotated -- and you can browse through this annotations. The initial idea came from experience with the law and procedures at court.

    After the second version the development was more or less abandoned, because there were not enough users, who would be prepared to use such approach for their research (collecting pieces of text) and writing which would start from the hyperlinks.



    -- Igor ----- kramberger@uni-mb.si

    This archive was generated by hypermail 2b30 : Sat May 26 2001 - 01:54:58 EDT