16.393 thinking with tools

From: Humanist Discussion Group (by way of Willard McCarty willard.mccarty@kcl.ac.uk)
Date: Mon Dec 30 2002 - 02:12:30 EST

  • Next message: Humanist Discussion Group (by way of Willard McCarty

                   Humanist Discussion Group, Vol. 16, No. 393.
           Centre for Computing in the Humanities, King's College London
                         Submit to: humanist@princeton.edu

       [1] From: Wendell Piez <wapiez@mulberrytech.com> (48)
             Subject: Re: 16.390 thinking with the technologies / XML vs.

       [2] From: lachance@chass.utoronto.ca (Francois Lachance) (67)
             Subject: Re: 16.387 thinking with tools

             Date: Mon, 30 Dec 2002 07:05:22 +0000
             From: Wendell Piez <wapiez@mulberrytech.com>
             Subject: Re: 16.390 thinking with the technologies / XML vs. RDM

    Willard and HUMANISTS --

    Manfred's deeply-considered post prompted me to think of only one
    qualification to add to this important thread--

    05:49 AM 12/26/2002, he wrote:
    >(6) Ceterum censeo: This will change only, if Humanities' practitioners
    >think less about the SURFACE of an IT application - relational table v.
    >XML encoding, which software product to use - and more about the
    >underlying data model / data type / knowlegde representation of
    >Humanities' information in a Comp.Sc. definition. Let us see first, what
    >a FORMAL representation of a "Humanities Text" means, before we write a
    >DTD for it or throw it at an innocent and naive RDBMS engine.

    Yes, verily. This proves to be particularly difficult in practice due to
    the confusion between this task -- identifying what a formal representation
    of a "Humanities text" would be, building a system instantiating such a
    representation in a useful way -- and a different task, which (though
    closely related at many levels) is quite separable: the (further)
    development of *text itself* as a technology of representation. I think one
    reason markup technologies such as XML have proven so tantalizing to many
    of us is that they involve us not only in the first project mentioned, but
    also in the second, whereas the application of DBMS technologies or even
    object technologies tend to elide the second project in favor of the first.
    Both projects are deeply interesting, worth pursuing, and of the essence of
    humanities computing; but it is probably also worth keeping in mind
    (Manfred's and Patrick's points) that just because XML (or markup
    generally) is itself "textual" in a way that (arguably) database
    applications are not, does not necessarily make it the best available means
    to *model* one kind of thing or another. "Build a resource that can provide
    X and Y and Z", and "develop an XML-based approach to X, Y and Z" are goals
    that may be in accord, or at odds, depending on the fit between XML and
    XYZ; nonetheless either might be a worthy goal even if they *are* at odds.
    (And it can be a research goal to determine how much in accord, or at odds,
    they are, and why.)

    In a way, this is merely to come full circle (though hopefully at a higher
    level of understanding): the fact that markup (or a particular kind of
    markup, such as XML) may be poorly suited to certain kinds of problems or
    tasks, is very much of interest to the student of text and text-based

    Warm regards,

    Wendell Piez mailto:wapiez@mulberrytech.com
    Mulberry Technologies, Inc. http://www.mulberrytech.com
    17 West Jefferson Street Direct Phone: 301/315-9635
    Suite 207 Phone: 301/315-9631
    Rockville, MD 20850 Fax: 301/315-8285
        Mulberry Technologies: A Consultancy Specializing in SGML and XML

             Date: Mon, 30 Dec 2002 07:07:10 +0000
             From: lachance@chass.utoronto.ca (Francois Lachance)
             Subject: Re: 16.387 thinking with tools


    Would it not be fair to infer from your gloss on Michael
    Sperberg-McQueen's posting (Humanist 16.384) that the shift to "domains"
    implies multiple participants and/or multiple perceptions embodied
    through a single participant?

    > >By formulating the research problem in terms of the entities in the
    > >research domain, and without reference to the entities of the tool
    > >domain.
    > I think the metaphor of "domains" here is (though conventional in
    > discussing such things) seriously misleading. Thought about something is
    > sometimes usefully conceptualized as a space, but not in this case.

    Space can be represented as reticulinated. Representations of space do not
    necessarily lead to a uniform flatness. I'm intrigued as to how the subtle
    move to the plural "domains" is underwritten (undermined?) by the
    suggestion that useful conceptualization is sometimes a function of
    thinking of something in terms of a [single] space. Domains suggest rules.
    Space too is represented by rules. A rule is a tool and hence your
    suggestion that one cannot avoid the perceptual effects of technology:

    > It
    > seems to me that the "entities" of research cannot always (often? ever?) be
    > defined independently of the tools one has to deal with them. Tools, even
    > chisels, aren't free from designed intentionality and perceptual effect;
    > one "sees" wood differently, treats it differently depending on the tools
    > one has and knows about.

    Now then. If I may. Harp. Intentionalities. Percpetual Effects. Different
    parsing. Punctuation and grain. How is a humanist and a computing humanist
    to account for resistences in the reading (i.e. application of tools)?

    Sometimes ax in hand the wood is to burn. Sometimes chisel in hand the
    wood is to burn. There is a lore of dendrology that precedes a technology
    of woodwork. Both lore and technology inhabit the spaces of conversations.

    It is archeologically accurate to assume purposiveness of design in the
    tools and texts one inherits. It is folly to assume that the tools and
    cultural artefacts will be used in the same way by every one who inherits
    them. And likewise retroactively to assume that the purposes of the past
    are transparent, always, to the present.

    Yes there is a mystery and because it points in several temporal
    directions it may be a set of mysteries. The uniformity of the phenomenon
    can not be assumed or ruled out. Just how the holders of the single
    mystery approach the releasers of multiple mysteries is fascinating; the
    one, a sieve separates, for the others, operates a series of

    Why the chisel and the sometimes ubiquitous hammer? I suspect it is not
    the mere gendered history of the certain tools and arts that leads to
    certain comparisons between computing machines and hand tools of the
    carpenter or mason. There is a further metaphor of building at work. What
    would computing filtered througn an alchemical metaphor of distillation
    and abstraction be like?

    Back in 1997, a text by Katheryn Sutherland was read at the thirty-third
    conference on editorial problems in Toronto. If I recall correctly, the
    discussion wend its way through two metaphors (text as architecture; text
    as vehicle) to reach a certain rather commonplace assertion that
    both synthetic and analytic moments are necessary for thinking through a
    research problematic. Perhaps that particular assertion can be inscribed
    in the current context to pause and consider that the application of a
    tool does not in itself lead either to synthetic or analytic moments (a
    easiest to make the case with a distillation however a building can be
    approached as an analysis of space as well as synthesis of a structure).
    In which case, there can be little done to factor out the human element,
    those mediating instances where the memory of participants reaches out not
    only intertextually across domains of cultural production but also
    ingenuously hacks.

    Francois Lachance, Scholar-at-large,
    knows no "no exit" in a hypertext
    every cul-de-sac is an invitation to turn

    This archive was generated by hypermail 2b30 : Mon Dec 30 2002 - 02:15:50 EST