Blake-Proj email

The long view (really long: get a cup of coffee)
John Unsworth (
Wed, 22 Jan 1997 00:09:09 -0500 


First, some news flashes, then a couple of questions and a matter for your

[material omitted]

OK, now we're past the news and the questions, and on to the matter for
contemplation. This has to do with EBT presentation, the Blake DTD, and the
dreaded concurrency problem. In fact, it comes down to a choice that you
Eds. have to make, between the physical and the logical (thanks Daniel...). 
Here's the problem, in simplest form, and I realize that this expression of 
the problem doesn't correspond to your current use of the <plate> tag.

<plate 1> 
<poem 1>
<plate 2>
<poem 2>

The problem is that a logical structure--a poem--can overrun a plate
division. The solution currently in force is to make <plate> an empty tag,
which means it doesn't contain anything, it just functions as a kind of
milestone (here's a plate beginning, here's another plate beginning). It
looks like this:

<plate 1>
<poem 1>
<plate 2>
<poem 2>

This solution begs the question of concurrency by making plate something
that can be contained within the kind of div that is poem. In effect, what
that means is that, in your markup, you have privileged the logical
structure over the physical structure, the poem over the plate. Now, up to
the point that we began to deal with EBT, the implications of this decision
could be hidden from view by virtue of the fact that we were a) doing no
searching on these structures, and b) writing custom perl programs--programs
that really understood nothing about SGML structures--to convert this markup
to HTML, and c) doing a certain amount of hand-made markup on top of the
perl output, to make it look the way you wanted. With your plate-oriented
display, for browsing, you were choosing to privilege the plate over the
poem, or the physical structure over the logical one. In short, having your
cake and eating it too.

So, why not continue that way? Well, a couple of reasons. The handmade
solution is not scalable--it can't apply across the whole archive, without
lots of mucking around every time a new work presents new problems. Thel,
for example, has only eight plates and can be treated one way, but Jerusalem
can't be run through the same script; we'll need a new one. Why not just
write those scripts for every work? Well, you still need to be able to
search the whole damn thing, and as soon as you want to do that, you need a
program (perl or EBT) to be able to navigate these SGML structures and
present them in a programmatic, archive-wide way. So forget searching,
let's just browse: still, it sucks: the problem doesn't go away, it just
gets swept under the rug, at great expense of effort and sacrifice of utility. 

I want to stress that the problem is not raised, but rather uncovered, by
EBT: although concurrence is theoretically allowable in SGML, nobody (to my
knowledge) has ever written any software to search or browse SGML that could
deal with it: it's a nice idea, but when you try to write code that deals
with concurrence systematically, rather than ad hoc, the complexity of the
problem is impossible. 

OK: back up and look at it this way. In order to make programmatic SGML
software (EBT) present your material the way the perl-generated SGML
appears, we have had to adjust the markup of the test copy of Thel to allow
only one plate per div: this is to say, we have systematized the privileging
of the physical over the logical. Might work OK with Thel, but what happens
when you want to see a poem that contains 20 plates in a work of 100 plates,
rather than seeing the whole work as a list of 100 plates? Well, in order
to do that, you'll need to go the other way, and systematize the privileging
of the logical over the physical: you'll need an SGML structure that looks
something like this:

<poem 1>
<plate 1>
<plate 2>
<poem 2>
<plate 2>

This means that if a poem begins on plate one and crosses over to plate two,
and a new poem begins on plate two, the information about plate two would
need to be repeated, in its entirety, within poem 1 and within poem 2. If
this were done, then you could see the logical structure, and the physical
structure, something like this:

poem 1
plate 1
plate header
plate transcription
plate image
plate 2
plate header
plate transcription
plate image
poem 2
plate 2
plate header
plate transcription
plate image

That's one choice, and it would entail a relatively major intervention into 
the current markup--nothing that couldn't be revised by a computer program.
The point is that it's a major editorial decision, not that it's a major
revision to existing markup. The latter we can handle; the former is a
decision you have to make, on editorial principle.

The other choice is to go further in the direction your display output has
already gone, and privilege the physical over the logical. In that case, a
work consists of plates, and all plates are equal in the hierarchy, and
logical structures (poems) are subordinate to plates:

plate 1
poem 1
plate 2
poem 1
poem 2

So, it comes down to this. Is the plate more important than the poem, or is
the poem more important than the plate? I have nothing invested in either
answer, but it's time to fish or cut bait on this question. I realize that
you didn't mean to finesse the issue--the decision was made, and then worked
around, out of your sight and probably without having the issues explained.
But please believe me: this is not an EBT problem; it is an SGML problem.
It's time now to make this decision, once and for all, because if you don't
make it, it will come back and bite you in the ass at some point, probably
in the not very distant future.

Tradeoffs: If you like, more or less, the current EBT display, then you
want to privilege the plate over the poem. If you can't imagine looking at
a longer, more complex work without being able to see the work divided into
its constituent poems, rather than its constituent plates, then you want to
systematically privilege the oogical structure over the physical structure.
The thing to grasp here is that you have to choose: physical, or logical.
Whichever you choose, we can represent; we mahy even be able to fudge a bit
here and there. But whichever you choose, you will be faced with certain
consequences, plus and minus, that attend that choice. And finally, there
will come a point at which I say: nope, we can't do that, because you made
this foundational choice. 

It's not, repeat not, EBT that's the problem: it's a logical and editorial

Have at....

John Unsworth / Director, IATH / Dept. of English