No source: created in electronic format.
By
Hermeneutic markup in its full form does not presently exist. XML,
and especially TEI XML, provides a foundation for this work. But due
to limitations both in currently dominant approaches to XML, and in
XML itself, a number of important desiderata remain before truly
sophisticated means can be made available for scholars to exploit the
full potentials of markup for literary study, as implied, for example,
by ideas such as Steven Ramsay's Algorithmic Criticism or what I
described in 2001 (following Geoffrey Rockwell and John Bradley) as
Prototype user interfaces designed to enable one or another kind of
ad hoc textual annotation or markup have been
developed, for the most part independently of one another. (Several
are cited.) This shows that the idea of hermeneutic markup, or
something like it, is not new; but none of these have yet made the
breakthrough. An important reason is that hermeneutic markup in its
full sense will not be possible on the basis simply of a standard tag
set or capable user interface, because it will mean not just that we
can describe a data set using markup (we can already do that), but
that we can actively develop, for a particular
text or family of texts, an appropriate, and possibly highly
customized, means and methodology for doing so.
A demonstration of a prototype markup application helps to show the
potentials and challenges, in a very rudimentary form. [Screenshots
appear in Figure 1.] This graphical and interactive rendering of
markup in the source files presents an interpretation of the
grammatical/rhetorical structure (sentences and phrases) as well as
verse structure (lines and stanzas) in the text. Unfortunately, while
the encoding for the sonnets here is not inordinately difficult
–
But overlap is only part of the problem. Consider Alfred Lord
Tennyson's Now Sleeps the Crimson Petal, Now
the White (the third example). This too is a sonnet, after a
fashion, although it does not have a conventional sonnet's
octave/sestet structure. Since this application does not work with a
schema for sonnets that enforces this structure, this works well
enough. Yet as texts or collections grow in scale and complexity,
having a schema is essential to enforcing consistency and helping to
ensure that like things are marked up alike. A framework for this
application must not only find a way to work around the overlap; it
must also deploy a schema (or at any rate some sort of validation
technology) flexible enough – at least if this instance is to be
valid to it – that such outliers from regular form are
permissible, even while attention is drawn to them (see Birnbaum
1997).
Currently, XML developers generally (setting aside the problem of
overlap) do not consider this to be problematic in itself; indeed,
part of the fun and interest of markup is in devising and applying a
schema that fits the data, however strange and interesting it may be.
What is not so fun is to have to repeat this process endlessly, being
caught in a cycle of amending and adjusting a schema constantly (and
sooner or later, scripts and stylesheets) in order to account for
newly discovered anomalies. Sooner or later, when exhaustion sets in
or the limits of technical knowhow are reached, one ends up either
faking it with tags meant for other purposes (thereby diluting markup
semantics in order to pretend to represent the
data), or just giving up.
Extending a schema is found to be a problem not only because
validating and processing any model more complex than a single
hierarchy is a headache even for technical experts, but also, more
generally, because current practices assume a top-down schema
development process. Despite XML's support for processing markup
even without a schema, both XML tools and dominant development
methodologies assume that schema design and development occurs prior
to the markup and processing of actual texts. This priority is both
temporal and logical, reflecting a conception of the schema as a
declaration of constraints over a set of instances (a
sui generis – the starting point for
hermeneutic markup. In hermeneutic markup, a schema should be, first
and last, an apparatus and a support, not a Procrustean bed.
All these problems together indicate the outline of a general
solution:
ad hoc elements
and properties (attributes) on the fly.
A system with all these features would support an iterative and
Such a system would not only be an interesting and potentially ground-breaking approach to collaborative literary study; it would also be a platform for learning about markup technologies, an increasingly important topic in itself. Moreover, hermeneutic markup represents an opportunity to capitalize on investments already made, as texts encoded in well-understood formats like TEI are readily adaptable for this kind of work.
Many of these capabilities have already been demonstrated or sketched
in different applications or proposals for applications, including W3C
XML Schema (partial validation); James Clark's Trang (schema
inferencing for XML); LMNL/CREOLE (overlap, structured annotations,
validation of overlap); JITTs (XML
The presentation will conclude with a demonstration of various
outputs from the data sources used in the demo, which provide building
blocks towards the kind of system sketched here. A range-analysis
transformation can show which types of structures in a markup instance
overlap with other structures, and conversely which structures nest
cleanly. Complementary to this, an
A final version of this paper, with the demonstrations, is available
at