[tei-council] genetic draft -- from Brett, pt. 5

[Lou Burnard]

On 31/08/11 16:36, Brett Barney wrote:
>> target="#ib1" [in the encoding of the bit shown in Fig. 8]
>
> Should read target="#ib01"

indeed it should. and now does.


>> <transpose>  describes a single textual transposition as an ordered list
> of at
>> 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
> insufficient,
> as it doesn't seem equipped to treat transpositions that involve the
> movement
> 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
> in
> my own writing (and in the Whitman-centric transcription world I know).
>
> <privateExclamation>Yawp</privateExclamation>

Not sure what to say about this one. Isn't a transposition that involves 
just one chunk of text the same as a deletion and an addition?

Are you saying that the current transposition concept is so fatally 
flawed we should not include it in P5, but refer it back to the 
workgroup? (Fine by me -- it;'s always less work not to put something in!)


>
>> 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
> be transposed,"

fixed

>
>> <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
> the
> 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.
> Is
> 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
> second
> 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.

Yes, I agree that the rules about placement of metamarks are none too 
clear, if they exist at all.  I think that a metamark with textual 
content (which both of these are) can appear anywhere. In both examples, 
it's inside the <line> because the transcriber thinks the whole thing 
(text and metamark) is on the same "line", even if it's above or to the 
left of the rest of the writing. The absence of @target is more 
worrying: there seems to be a tacit rule that the target of a metamark 
is its parent if no @target or @spanto is supplied.


>
>> 1.3.6 Alternative Readings
>
> One of my problems with using<alt>  for word stacks has to do with the
> @mode
> 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
> if
> 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
> but
> 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
> that
> 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
> one
> 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
> weights
> 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
> alternants
> must appear, and the situation is better encoded without an alt tag*"
> [emphasis added].
>
> 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
> of
> the weights 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". 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?
>

This is making my head hurt too. Maybe <alt> is not such a good choice 
after all? maybe we need another value for its @mode attribute?
What do others think?