[tei-council] genetic draft -- from Brett, pt. 5
bbarney2 at unlnotes.unl.edu
Wed Aug 31 11:36:29 EDT 2011
Here's another small handful of comments about the draft at
> target="#ib1" [in the encoding of the bit shown in Fig. 8]
Should read target="#ib01"
> <transpose> describes a single textual transposition as an ordered list
> least two pointers specifying the order in which the elements indicated
> should be re-combined.
Well, I don't think "re-combined" conveys the right meaning. But much more
important, I'm concerned that the whole concept of transposition might be
flawed. Put less alarmistly: the proposal looks to me at least
as it doesn't seem equipped to treat transpositions that involve the
of *one* chunk of text (rather than the swapping of two or more chunks). I
suspect that such cases are actually much more common; they certainly are
my own writing (and in the Whitman-centric transcription world I know).
> When (as in the following example) the whole of line is to be transposed,
Should read "When (as in the following example) the whole of *a* line is to
> <line xml:id="ib3">
> <metaMark function="transposition" place="margin-left">2.
One thing that I noticed that I'm just going to try to think through: In
two example encodings for <transpose>, the <metamark>s are placed in
different relationships to the textual bits that are marked for
transposition. That is, in the first example the <metamark>s are outside of
the <seg>s; in the second example the <metamark>s are inside the <line>s.
placement significant? Or does the fact that <metamark> is thought to be
non-textual take it outside the textual flow? If that's so, what does an
attribute value like place="above" mean? (In the second exapmle, the
attribute value is place="margin-left," but it's inside the <line>,
so . . .
.). Also, I see that there are no @target or @spanTo attributes in the
example--makes sense, on one level, as it's nested in the relevant element,
but that logic sort of raises the same set of issues, then.
> 1.3.6 Alternative Readings
One of my problems with using <alt> for word stacks has to do with the
values, "excl" and "incl." At the beginning of 16.8 the Guidelines explain
these thus: "We say that two or more elements are in exclusive alternation
any of those elements could be present in a text, but one and only one of
them is; in addition, we say that those elements are mutually exclusive. We
say that the elements are in inclusive alternation if at least one (and
possibly more) of them is present." When the alternation occurs not in the
mind of the editor but in the text itself, this distinction makes no sense.
In the Lalla Rookh example, both "before" and "beside" not only could be
manifestly *are* present in the text (though maybe not simultaneously,
depending on what is meant by "text"), so shouldn't the value be "incl"?
Wouldn't it *always* be incl for word stacks?
@weights presents a similar problem. In the example we have "0 1"--meaning
that the probability that "before" occurs is 0% and the probability that
"before" occurs is 100%. To my mind, that's clearly inaccurate. Assuming
the problem is just that "excl" should be "incl," I read this explanation
about the meaning of the @weights: "If mode is incl each weight states the
probability that the corresponding alternative occurs given that at least
of the other alternatives occurs." Well, that would mean weights="1 1." But
then there's this, a bit farther on in section 16.8: "The sum of the
for <alt mode="incl"> tags ranges from 0% to (100 × k)%, where k is the
number of targets. If the sum is 0%, then the alternation is equivalent to
exclusive alternation; *if the sum is (100 x k)%, then all of the
must appear, and the situation is better encoded without an alt tag*"
Miscellaneous notes: 1) I admit to having never been able to get my mind
around the We/Lee/fun/sun example of mode="incl"; I have given an honest
effort sever times. 2) I'm reasonably confident that in the second of the
following sentences (from section 16.8) "0%" should read "100%": "The sum
the weights for <alt mode="incl"> tags ranges from 0% to (100 × k)%, where
is the number of targets. If the sum is 0%, then the alternation is
equivalent to exclusive alternation". I'm not sure what this is trying to
convey, though. How can inclusive alternation be equivalent to exclusive
alternation mathematically while retaining any meaningful distinction?
Research Associate Professor
Center for Digital Research in the Humanities, University of
More information about the tei-council