Blake-Proj email
The long view (really long: get a cup of coffee) John Unsworth (jmu2m@virginia.edu) Wed, 22 Jan 1997 00:09:09 -0500 Boyz, First, some news flashes, then a couple of questions and a matter for your contemplation. [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> <plate 2> </poem> <poem 2> </plate> 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> <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: <work> <poem 1> <plate 1> </plate> <plate 2> </plate> </poem> <poem 2> <plate 2> </plate> </poem> </work> 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: Thel 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: Thel 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 problem. Have at.... John Unsworth / Director, IATH / Dept. of English ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://jefferson.village.virginia.edu/~jmu2m/
| Next--> |