[Humanist] 23.258 saying everything
Humanist Discussion Group
willard.mccarty at mccarty.org.uk
Wed Sep 2 07:02:06 CEST 2009
Humanist Discussion Group, Vol. 23, No. 258.
Centre for Computing in the Humanities, King's College London
Submit to: humanist at lists.digitalhumanities.org
Date: Tue, 1 Sep 2009 18:34:43 -0400 (EDT)
From: Francois Lachance <lachance at chass.utoronto.ca>
Subject: Re: [Humanist] 23.249 saying everything that needs to be said?
Inspired by John von Neumann you invite us to meditate on the activity of marking up as a path towards a theory of textual computing:
<? resituate ?>
When you drive the problem of markup to its breaking point, isn't a similar realisation to be had -- that
the real question is being missed. What do you suppose is that question?
<!-- attempt at uncovering or marking that question-->
In approaching this question, would we benefit from a history of the types
of markup and the ways document instances are validated. [COCOA Markup, SGML
and DTDs, XML and schema]? The succession of types of markup represent
different ways of reading. They also make different demands on memory. It
would be interesting to trace the succession of various types of markup with
the technical advances in available memory to process text.
However, I am suggesting a different tack that need not lead us into the
shoals of techno-determinism. I am suggesting that markup prepares the way
for an emulation of human reading with all its contingencies and vagaries.
The time of reading has, in narratological studies, been approached as a
difference between narrating time and narrated time. The narrating time has
been measured in pages and lines. Other measurements are possible based on
other ways of segmenting a document instance. Markup provides the
segmenting. The machine can then be instructed to process the segments in
the context of a uniform unfolding of time. However as theorists have
recognized, the Lesetempo of actual readers does not unfold uniformly.
Reading time is composed of starts and halting and variable speeds.
It is possible through markup to incorporate processing instructions into a
document instance. Through such processing instructions one can cause the
appropriate program to select a variable that affects the speed of traversal
for a given set of segments. Consider this if you will as a design for trip
wires. Of course such behaviour can be achieved as part of the processing
software and not through markup or in the document instance.
The advantage of using the processing instruction in the markup is that we
are given a human-readable trace -- the markup acts like pseudo-code.
I raise this example because markup is usually considered as a description
of a textual instance. The resources for embedding processing instructions
provide an opportunity for commenting upon the traversal of a given
description. In a sense then any markup whether it is an explicit
processing instruction or not is about a hoped for processing.
The question then becomes can we align the markup and the machine to create
surprise. The aim of markup is not simply to create a description and invoke
a predictable processing. It can be used to model the contingent.
For more on machines, emulation and how instructions and descriptions are
isomorphic , see Linkname: Sense: Emulations URL:
-- Francois Lachance, Scholar-at-largehttp://www.chass.utoronto.ca/~lachance
More information about the Humanist