[tei-council] More on choice and app / rdg

[Daniel O'Donnell]

I've been thinking all morning about the choice/rdg issue and think I
may see both what the problem is and a solution.

First of all, for choice, I think the problem is that our description
represents one view of choice (a view that agrees with my view, in fact)
as a generic indicator of simultaneity, while the content model
represents a different model--basically of something that we might call
"Janus Tag Container" (which makes sense, of course, because that's how
it came about). 

I agree with Syd now that changing the model to match the description is
too big a job for P5. Since the same thing can be handled more or less
using @exclude (although I'd prefer @alternate or @choice as the name),
and expanding choice would involve the issues of divs in segs and such
not, I'm not sure that a post P5 change would be good, since it would be
quite a major change and I think we should be aiming at long term
stability.

So given that, perhaps what we need to do is change the description to
match the content model and perhaps modify the content model very
slightly. Rather than "groups a number of alternative encodings for the
same point in a text" I think we should change the description to
something like "groups original and editorial states of text where these
can be seen as alternates" (not perfect, but the point is to indicate
that choice is specifically associated with TC elements, not alternate
encodings of any kind). And given that this is really an "editorial
choice" tag rather, I wonder if we shouldn't look into including all or
most of the elements in §3.4. I.e. currently model.choicePart contains
<sic>, <corr>, <reg>, <orig>, <unclear>, <add>, <del> and <seg>. It
seems to me it should also contain <supplied> (since that is also an
editorial intervention that can have a corresponding "original" state)
and probably <damage>, <gap>, and <restore>. So in other words,
everything in model.pPart.edit except <app> (which is odd there anyway,
since unlike all other members of this class, it doesn't describe a text
or an editorial intervention, but collects lists of readings).

If we do this, BTW, it also partially solves what seemed to me to be
Syd's worrying point that choice/option1|option2 is the same as
option1 at exclude="option2" vs. option2 at exclude="option1": given that why
create the choice element at all. I think the answer is that it exists
because it is marking a discrete structure in an electronic text:
*editorial/transcriptional* alternation rather than simple alterity.

So a reversal of my earlier position.

This does return us to app and rdg though. Here I think two things.
First of all, that the rdg content model simply is inadequate and does
not represent obvious and common use cases. Textual variation commonly
involves addition, omission, or variation in the order of chunk-level
elements and rdg must be able to accommodate that. So its content model
should have at least model.divPart. But as the Anne Frank example
suggests, variants can be even bigger than that: you can add/omit/alter
entire sections of texts: diary entries, chapters, front and back matter
elements. Especially if you are using the Parallel Segmentation method,
it is important to be able to capture these as well, so I'd say you
might even want to include front, body, and back or at least
model.divLike.

The second thing is the location of app in
pPartEditorial/pPartTranscriptional. I don't see why it is included in
phrase level elements like this. It seems pretty clearly different from
the other members of pPartTranscriptional in that <add>  <corr>
<damage>  <del>  <orig>  <reg>  <restore>  <sic>  <supplied>  <unclear>
all say something about the text, whereas app simply lists examples of
text. Also, apparatus traditionally stand on their own on the page,
making them chunk- or inter-like in my book. It seems to me app belongs
in model.listLike alongside list and listBibl.

My final point involves our claim that app is a specialised form of
choice. I've always held this to be true, and, if it has a lem, I
suppose you could maintain that it still fits the proposal I make above
for describing choice as really being a container for grouping editorial
interventions with the original form. But if we do go with the more
specialised definition of choice, I'd argue that app actually isn't a
specialised form of choice after all, since there is no editorial
intervention in a text encoding using the parallel segmentation method
without a base text. If we restrict choice to "editorial/transcriptional
alternates," then I think I reluctantly have to conclude that app isn't
a form of choice, but just a type of list.

-dan

> <choice>
> <div type="option1">
> <p>The text encoding initiative is an organisation devoted to the
> development and maintenance of standards for the encoding of texts. It
> is built on a consortium model, with four hosts and an elected board
> and
> council</p>
> </div>
> <div type="option2">
> <p>The text encoding initiative is an organisation devoted to the
> development and maintenance of standards for the encoding of
> texts.</p>
> <p>It is built on a consortium model, with four hosts and an elected
> board and council</p>
> </div>
> </choice>

Should be


-- 
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/