EEBO Hackfest and One Markup Geek in the Corner

On March 9th, to celebrate the release of over 25,000 texts from the Early English Books on-line project into the public domain, the Bodleian libraries hosted a one-day Hackfest at the Weston Library to bring together a wide range of scholars and developers interested in using the newly released corpus. Participants ranged from a pair of computer science majors seeking to improve the corpus’s search functionality to medievalists wanting to consider the use of the original document artifacts with a host of interests and project ideas in between. After a brief welcome and an introduction to the methodolgy behind EEBO’s encoding, we all moved into Blackwell, the central space of the Weston Library, for project “speed dating”: an opportunity to briefly pitch ideas and/or skill sets to other interested participants. From this, clusters of like-minded hackers coallesced into working groups, cooperating and collaborating to compete for door prizes for best project idea. (Our own Daniel Powell won a copy of the Bodleian’s Marks of Genius for his contributions to investigating user expectations of the corpus.)

And then there I was, sitting alone in the middle of it all, trying to figure out what an abstraction layer-ed stand-off markup would look like at home.

Which isn’t to say I didn’t enjoy the hackfest or that it wasn’t worthwhile for me personally. Far from it. The event was lavishly prepared and ably run, and the opportunity to discuss projects was invaluable. But, in the end, I wound up spending eight hours using a suite of Python scripts to format plain-text transcriptions into bracketed markup pseudo-code and manually relating that tagging the output of UVic’s Image Markup Tool. I didn’t even manage to get into using the repository being celebrated, as I had too much invested, at that point, in a single page scane from a late 19th century “Alice’s Adventures in Wonderland.” Strangely, none of the other participants considered this to be a fun or interesting way to spend their hackfest.

Hackfest Screencap

My view… All. Day.

Even working alone in a crowded room, though, I was able to get a working model (if a rough and fantastically ugly one) on its feet by the end of the day. Given it’s hybrid nature – and that a single page took over 2000 lines to encode – I’ll spare you, gentle reader, by not posting it here.  However, my goal for the day was less about having a finished product (finishing a product was simply the constraint I was imposing on myself) and more about the questions that racing towards such a product would raise. And while I intend to similarly spare you the full force of my dozen pages of scrawled notes, I would like to highlight a few of the more interesting tidbits here.

1 – There are more [interconnections in texts], Horatio, than are dreamt of in your philosophy. As I mentioned before, I was working on a page from an illustrated Alice’s Adventures in Wonderland, and I chose this particular page specifically because of it’s nested image.  I had anticipated it being fairly straightforward: The page facsimile would be the base layer, in the second layer would be the regioning defining text lines and graphic blocks, and in the third layer would be two seperate, parallel layers, one defining the illustrated contents of the graphic block, another defining the textual content (transcription) of the text lines. However, the image on this particular page had… a caption.  On the one hand, the caption Image and Caption croppedwas obviously a commentary on the image and thus needed to be in the Graphic sub-layer. On the other hand, the caption was equally obviously an example of print on the page, and thus needed to be in the Transcription sub-layer. Suddenly, my two parallel (but distinctly seperate) sub-layers were referencing each other in a way I had not expected. I suspect a more thorough attempt to create parallel “analytical” layers would face similar issues.

2 – Internal Referencing and IDing multiplies the number of potential ordering principles. In standard TEI practice, there are effectively two ordering principles: nesting and linearity. So, for instance, if Element B is is contained within Element A (or, similarly, if Property B is encoded within Element A), we know something about the relationship of B and A. Meanwhile, less obvious but more powerful, since XML is composed of a linear data stream, if Element B comes before (or after) Element A, we know something about the relationship of B and A. However, the introduction of IDing and referencing (already used in TEI, but necessarily common in stand-off) introduces new potential ordering principles. First, ordering by reference (if B is the target of a reference by A, we know something about the relationship of B and A) and second, ordering by ID structure (if B and A both have ID’s beginning “@id=foo.bar.x001”, we know something about the relationship of B to A). In fact, I’m wondering if it might be worthwhile to propose an ID naming scheme in which the ID of the target of an element’s reference is encoded into the referer’s own ID, thus ensuring the uniqueness of the referer’s ID and obviating the need for a seperate “@target=” property.

3 – Not all tags are created equal. Consider the TEI [hi] tag. It’s usually paired with a @rend property to show that given word or phrase is highlighted and HOW that highlighting is accomplished on the page. For instance, “[hi rend=’bold’]the dog[/hi]” would indicate that the phrase “the dog” is highlighted in the document by being bolded. However, there are two operations in play. There is a recognition of a change in the typeface on the page (the characters are printed with more ink and are thefore “bold”), and that typographic change is ascribed to a structural meaning (this phrase is intended to be highlighted). In TEI, these two operations are conflated in the hi/rend construction (as well as in the foreign/rend, q/rend, gloss/rend… really anything that can take the @rend property), and thus subordinates the description of artifact to its textual analysis. But in my own scheme, which forces a seperation of the appearace of the document (Layers 1-3) from commentary on that appearance (Level 4+), they must be seperated. The appearance of bold characters, being a description of the document appearance, belong on Layer 3 (with the transcription) while their explanation belong on Layer 4 (with explication and commentary). By seperating these two, however, new questions arise: namely, what, exactly, is the target of the assertion of “highlight”. On the one hand, it would seem that both the [highlight] (analytical) and [bold] (descriptive) assertions should have the same target in the transcription (in this case, “the dog”), as the PHRASE is being highlighted and bolded.  This would seem to suggest, though, that the phrase “the dog” just happens to be both bolded and highlighted, without showing any relation between the two. On the other hand, the assertion of highlighting COULD take as its target the assertion of bolding. In this case, the [bold] assertion would be tagged as an instance of a highlighting marker, explicating the “proof” of highlighting that the editor is asserting is there. I’m in favor of the latter, both because of its explication of the tags’ relationship, and because I suspect it would ease potential parsing difficulties.

4 – Paragraphs and blocks just got a WHOLE lot messier. Paragraphs are arcane enough in TEI already. There is little hard-and-fast guidance in the TEI guidelines on how to identify a paragraph. While I’ve heard this attributed to an offer towards editorial freedom (i.e. allowing for individual editorial discretion in the identification of paragraphs), I suspect it is at least partially due to the fact that paragraph boundaries are most commonly denoted with white space, a page feature that is pretty difficult to handle in MOST markup languages. However, in my own scheme… it gets even more tricky. Is [paragraph] a description or an explication?  If, as I think, it’s the latter, what is the descriptive feature that justifies the assertion of a [paragraph]? And if that descriptive feature is actually white space (either between lines, preceding the first line of the paragraph or proceding from the end of the paragraph)… how do you markup white space? And, for that matter, will the inclusion of this white space in layer 3 require a reconsideration of how to mark regions in Layer 2?


Leave a Reply

Your email address will not be published. Required fields are marked *