Print

Print


First: the EETS experiment is a nice site.  Since I am pulling my hair
out about design at the moment, I noticed that it has two potential
problems that might want to be considered in general for the production
version of the standard stylesheets, however: the banner contains unique
information (though not very much other than the title) that won't show
up in a screen reader or text-only browser; and the use of a fixed width
banner image stops the text fitting screens smaller than 640x780 (e.g.
PDAs or reduced-sized windows). Are you thinking of separate stylesheets
for aural, handheld, print contexts?

Secondly, turning to my question: Lou and Sebastian's solution is the
method I'd been thinking of going with if I change my document
structure, even though it will produce a fairly large file even in the
case of Caedmon's Hymn. Because I'm encoded in SGML and am not using XSL
to throw out different HTML documents, going this way would make the
connection between my SGML and HTML slightly less obvious, but it would
be a good archive method, I suppose, and it does seem to be what the TEI
wants.

At the same time however, it seems to me that there should be a
mechanism for attaching a single TEI compliant bibliographic header to a
system of files rather than a single file, and also a method of building
original electronic books that doesn't depend on print organisational
structure. There are two reasons for this.  This first is that this is
how many if not most of us actually work: best-practice in HTML document
design seems to me to encourage the use of multiple files and directory
structures--far beyond even the chapters of print media (I'm thinking
for example of the recommendations for breaking up 'chapters' in Jakob
Nielen's Usability); in fact some might argue that electronic documents
should be written as non-linear islands of information (again I'm
thinking of Nielsen; personally, I don't see how this is useful for
anything other than the commercial PR and news sites he is mostly
talking about). Many of us work in a similar fashion in building our
SGML/XML.

The second reason for having a system TEI header for a system rather
than a single document is that core electronic document structure can be
amorphous and non-linear in a way that is perhaps difficult to capture
with a <frontmatter>, <body>, <backmatter> structure. Whereas in print
bits of material need to be assigned a specific place in a linear
structure (e.g. glossaries and appendices go in the back matter),
electronic documents can place this material in several spots at the
same time or generate it dynamically: e.g. lines from the glossary
showing up in the text; quotations from the text showing up in the
introduction; fragments of appendices showing up in chapters). An
example from the EETS ancrene wisse site, I think, is the appearance of
translations: if I understand things correctly, these show up in a
couple of different places depending on the links followed. Since Lou
and Sebastian encoded this document using linear print structure, this
can obviously be covered by the recommended format; but it does seem
like an artificial imposition. Indeed one might argue that assigning a
place in a linear structure to material that is actually found
throughout is in fact misleading: if notes or glossary entries can show
up in various places in the realised document, they are not really
"backmatter"; they are data that can be realised as backmatter in one
particular presentation scheme.

I can think of a more serious potential problem, however: what if
apparently "structural" elements of a document like texts,
transcriptions, and apparatus are in fact dynamically generated rather
than directly encoded in TEI? Given the ability of XSL to transform and
throw off new documents, it seems to me perfectly reasonable to encode a
text that consists of several distinct units whose structural
relationship to each other only becomes clear in specific realisations.
In other words, you could reasonably encode a TEI deck like this:

<database of narrative units such as introductions, prefaces (i.e.
material for which their is likely to be only one representation in the
"deck")>
<database of non-narrative material such as manuscript readings,
glossary entries, notes, images, etc. (i.e. material which is likely to
reappear at various places in the edition, including within the
narrative units)>

This material could then be transformed and styled to produce a
traditional linear book structure (<Front Matter + Body + Back Matter>)
if desired.  Other realisations are also possible, however: a single
chapter could be reproduced as an article; readings from specific
witnesses could be formatted and outputted for inclusion in a corpus;
glossary entries could be combined with other texts for a series-wide
glossary; texts could be made up and exported for use in an anthology. I
realise this is structural markup 101: the point, however, is that the
recommended structure is only one possible realisation of the data and
as such should perhaps not be enforced as a required format; it may
indeed actually be a subtle conflation of style and content.

Or perhaps I've gone insane. Anyway, to return to my original point:
should there be / is there a way of writing a legal tei header for a
system of TEI files? How do multi-text projects and series do it?  Do
they really combine all their material into a single teicorpus entity,
for example, or is there a top-level header that applies to all
subsequent levels?
-dan

Burnard Towers wrote:

>Sebastian and I had to deal with a very similar problem with respect to a
>pilot edition of the Ancrene Wisse which we recently completed for the Early
>English Text Society (you can see the results at
>http://www.tei-c.org.uk/Projects/EETS/)
>
>We took the view that the whole website was best treated as a single TEI.2.
>I quote from the brief tagging guide prepared for the project:
>
>The entire edition is tagged as a single <TEI.2> element, containing (as
>usual) <teiHeader> followed by a <text> element. The <teiHeader> contains
>descriptive metadata for the entire edition, (including details of any codes
>used in more than one of its components such as manuscript hand
>identifiers). The <text> element groups together, at the top level, the
>following:
>* front matter for the whole edition, tagged <front>, containing all the
>introductory material.
>* one or more <text> elements, each containing a distinct version of the
>text in question, possibly with its own front and back matter. If more than
>one text is present in an e-edition, as will normally be the case, then they
>should be grouped together within a <group> element. Groups may also be
>nested hierarchically.
>* back matter for the whole edition, tagged <back>, containing sections of
>bibliography, analytic notes, glossary, and index.
>Attributes ID and TYPE are used to identify and clarify the functions of
>each <text> element.
>
>The XML source is also on the above website, but not explicitly linked to
>yet, because (as usual) we haven't quite tidied it up properly. But those
>keen to see the inner workings are welcome to snoop around: try
>http://www.tei-c.org.uk/Projects/EETS/driver.xml for starters.
>
>
>
>
>
>>-----Original Message-----
>>From: TEI (Text Encoding Initiative) public discussion list
>>[mailto:[log in to unmask]]On Behalf Of Daniel O'Donnell
>>Sent: 12 July 2003 07:24
>>To: [log in to unmask]
>>Subject: Question about project structure
>>
>>
>>I'm proofing a final draft of an edition of an Old English poem. I'm
>>working now on the header(s). My question involves how others have
>>treated original electronic compositions: as a single book or a
>>collection of files?
>>
>>This edition has the usual sections you'd expect to find in any print
>>edition: preface, TOC, introductory chapters, texts, glossary,
>>bibliography, appendices, etc.. In compiling the project, I've worked
>>with each discrete chapter, text or front/back matter unit as a separate
>>file, with its own minimal header. Sections are also grouped into
>>distinct directories. In designing the text, the "book" has really
>>consisted of the collection of directories and files rather than any
>>single file.
>>
>>Now that I come to describe the work as I whole, I'm not quite sure how
>>to proceed.  On the one hand it isn't a corpus or a composite text as
>>these seem to be explained in P4; on the other it is not clear to me
>>where I would describe the project as a whole.  Would people recommend
>>for archival purposes collapsing the whole project into a single file
>>with multiple divs; treating it as a group with multiple texts; a corpus
>>with multiple tei.2s? Or is there a way of supplying a global teiheader
>>for the "document" as it actually exists right now: as a series of
>>discrete files in various subdirectories of a single deck? Two apparent
>>solutions, adding a project-oriented headers to the top file in the
>>project or composing an independent header for the project as a whole
>>don't seem quite right, since the former solution would involve
>>misrepresenting the file to which the header is actually attached and
>>independent headers as I understand them are supposed to mirror real
>>document headers.
>>
>>-dan
>>
>>--
>>Daniel Paul O'Donnell, PhD
>>Associate Professor of English
>>University of Lethbridge
>>Lethbridge AB T1K 3M4
>>Tel. (403) 329-2377
>>Fax. (403) 382-7191
>>E-mail <[log in to unmask]>
>>Home Page <http://people.uleth.ca/~daniel.odonnell/>
>>
>>
>>
>>
>
>
>

--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge
Lethbridge AB T1K 3M4
Tel. (403) 329-2377
Fax. (403) 382-7191
E-mail <[log in to unmask]>
Home Page <http://people.uleth.ca/~daniel.odonnell/>