[tei-council] rdg and the phrase

[Daniel O'Donnell]

On Tue, 2007-07-17 at 15:43 +0100, Lou Burnard wrote:
> But a traditional apparatus never *does* include whole chapters does it?
> 
> I think it's really distorting the meaning of "rdg" to say it can 
> contain a whole chapter!

First of all, let's deal with the simple intermediate problem rather
than the tough case: apparatus frequently include chunks and the TEI's
doesn't. I've given a number of use cases in the last months and they
are not at all hard to find. Print apparatus have always found this hard
to deal with, because of layout issues. The TEI's structural markup
allows us to be explicit about something print could not.

Secondly, the TEI apparatus is not a traditional apparatus, though it
can encode them. Parallel segmentation is not a traditional approach to
apparatus, though it is a brilliant electronic form (of course collation
lists are a kind of parallel segmentation, but they are not intended for
reading in the way a TEI parallel seg. apparatus is according to the
narrative description). So we can use the apparatus to encode existing
print apparatus, but we can also go much farther and deal with things
print has an extremely hard time dealing with.

And this leads us to the issue of divs. First of all, they actually do
show up in print apparatus: I don't have an example at my hand right
now, but I've seen them and I believe there are examples in Greetham's
textual scholarship. The normal print approach when a variant involves
the addition of an entire chapter or equivalent is to use an ellipsis
after the first couple of words and then close with an excipit. Often a
note or text in square brackets is use to indicate that the text in the
elipsis is a chapter. Other times, as in the Critical Edition of the
Diary of Anne Frank, they try to use pointers and codes to indicate what
they mean--the DAF critical ed has a normal textual apparatus that
collates at the chunk, phrase, and word level, and then a kind of
combination parallel-text/collation system that tries to compare
div-level elements. It is not very successful.

So div level elements do appear in print apparatus, but not very well.
In electronic form, once again, we can do much better.  Apps are in my
view very much like dictionaries: something that print did but we can
improve on.

> 
> You could perhaps more plausibly argue for allowing a pointer element of 
> some kind to stand in for a <rdg>.

This wouldn't solve the problem of the chunk and divs in rdg and lem,
since any attempt to use the pointers to extract an apparatus would
break rdg if the target was a chunk or div. So I could build a kind of
link group telling you where the collation units are, but I couldn't
perform one of the functions of a textual apparatus, which is extracting
the readings and placing them beside each other for comparison.

> 
> 
> Daniel O'Donnell wrote:
> > Just a quick follow up to our conversation re: rdg.  Lous and I have had
> > a brief correspondence on it since:
> > 
> >>> Hi Lou,
> >>>
> >>> Following up: can you tell me again what it is I should be looking
> >> at
> >>> regarding rdg and chunks? Did you say rdgSpan (in which case
> >> what/where
> >>> is that?) or is it an attribute? I've quickly gone through the
> >> chapter
> >>> again but am not seeing anything that sounds like what I thought you
> >>> said.
> >>>
> >>> Thanks!
> >>>
> >>> -dan
> >> Sorry, I was misremembering something else. addSpan and delSpan are 
> >> provided by the PH chapter to support additions and deletions of
> >> items 
> >> that don't necessarily fit into the document hierarchy, for example
> >> an 
> >> additiom that starts at the end of one chapter and continues into the 
> >> next: I was proposing that something analogous might exist for rdgs
> >> and 
> >> lems. But I see we already have it in the shape of the double end
> >> point 
> >> attachment method.
> >>
> > 
> > The double-endpoint-attachment method is not quite sufficient, however.
> > It is good for overlapping variants and lemmas of the type in 117 of the
> > Wife of Bath's Tale (collation units indicated by [ and { respectively):
> > 
> > Hg
> >         And [of so parfit {wys] a wight} ywroght
> > El
> >         And for what profit {was a wight} ywroght
> > Ha4
> >         And [in what wise] {was a wight} ywroght
> > 
> > <l xml:id="WBP.117" n="117"> And <anchor xml:id="WBP-A117.1"/> of so
> > parfit
> >   <anchor xml:id="WBP-A117.2"/> wys
> >   <anchor xml:id="WBP-A117.3"/> a wight
> >   <anchor xml:id="WBP-A117.4"/> ywroght
> >   <app from="#WBP-A117.1" to="#WBP-A117.3">
> >    <lem wit="#Hg">of so parfit wys</lem>
> >    <rdg wit="#Ha4">in what wise was</rdg>
> >   </app>
> >   <app from="#WBP-A117.2" to="#WBP-A117.4">
> >    <lem wit="#Hg">wys a wight</lem>
> >    <rdg wit="#El #Ha4">was a wight</rdg>
> >   </app>
> >  </l>
> > 
> > It won't solve the problem of extra, missing, or reordered chunks (as in
> > the case of lines of poetry or paragraphs) or divs (as in the case of
> > diary entries in something like the Diary of Anne Frank), since you
> > still can't reproduce chunks or divs marked up as such in lem or rdg.
> > This would work if app and/or lem|rdg was really something like
> > linkGroup and did not reproduce the actual text, since you could use the
> > milestones to mark off arbitrary sections of text regardless of their
> > encoding. But it breaks the moment you try to include the text you mean
> > with its structural markup in your lem or rdg if this markup is larger
> > than the phrase.
> > 
> > I'll propose concrete model and language changes this week as promised
> > at the meeting (in case you didn't hear during the meeting ;Þ ).
> > 
> > -d
> 
-- 
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/

Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/