[tei-council] genetic draft -- responses to responses, pt. 2

[Brett Barney]

On 08/30/2011 11:58, Lou Burnard wrote:

> >> when dealing with authorial manuscripts,
> >
> > Is this supposed to mean (and should it therefore read) "literary
> > manuscripts"?
>
> No, it is supposed to mean "authorial" in the sense that the person who
> wrote the manuscript is responsible for its intellectual content in a
> different way from say a scribe copying a manuscript which someone else
> has "authored". Would you prefer the word "holograph"?

Well, yes, I guess I would, as it's more exact. Your explanation,
though, makes me think that my confusion probably arose more from
"historical" as the contrasting term; what about "scribal" instead?

On 08/30/2011 12:17, Lou Burnard wrote:

> > I honestly don't know what to suggest here, since I do think it
extremely
> > fishy to make a fuss about the part played by an editor's interpretive
> > faculty in the determination of how a bit of text functions while
> > ignoring it in the determination of when it was written.
>
> Saying something is a <mod>  says something about its "when", but not
> about its "what". That seems quite useful to me.

OK, I grant that it's a useful, pragmatic distinction. But I think we
should talk about it *as* a pragmatic distinction in the guidelines, too,
rather than seeming to pretend that there's a theoretically pure way to
decide things like when something was written (or even, more generally
what's on the page) absent interpretation.

On 08/30/2011 13:06, Lou Burnard wrote:

> "contains or describes any kind of graphic or written signal
> within a document intended to signal how it should be read but not
> forming part of the text itself"

I like this, but I do have a further revision to suggest: ". . . graphic or
written signal of how the text or a part of it should be read . . . ."
(Avoids "document" and the repetition of "signal.")

> > Two things: 1) I don't see how one can claim that "additions to the
text"
> > don't "indicate a deliberate alteration of the writing itself"; 2)
plenty
> > of
> > marginal notes say things like "move this passage over there," so I
don't
> > understand what distinction this bit is trying to shed light on.
>
> Well, the idea is to distinguish a metamark from a marginal note. So are
> you saying that they are indistinguishable?

Objection retracted, now that I see that my own assumptions were the cause
of my confusion. (A bit of explanation, for the record: When I first saw
<metamark> I immediately thought I knew what is was for--namely,
*non-character* marks that signal how to read the text--based on my
experiences encoding a bunch of manuscripts and not having any satisfactory
way to treat them. It was easy enough to handle *textual* signals with
<note>, but how to encode those non-textual things like arrows, swoopy
lines, etc. has always been a puzzle.)

> > I'm a *tiny* bit bothered by the lack of parallelism in the list of
sample
> > values for @function. Namely, "used" is not like the others.
>
> Not sure what your point is here. Should it be a different attribute
then?

My point is that "reorder," "flag," "delete," and "insert" are all
plain-form verbs. To make "used" parallel you could call it "markUsed"
maybe (can't come up with a one-word synonym).

> > Without some sort of indication that the two methods cover different
cases,
> > I
> > don't like having two ways of doing the same thing. I can see that
@spanTo
> > couldn't accommodate teh example, but I'm not sure why @target couldn't
> > work
> > for everything. If indeed both are needed for different cases, I think
> > readers will appreciate something explicit about what the differences
are.
>
> @target can only work if it's possible to indicate the element/s
> concerned -- so the passages being metamarked have to be discrete
> elements. @spanTo works by just saying "everything from here to there".

Right. I obviously wasn't thinking very clearly when I first brought this
up. Now, thinking a little more clearly, I'm wordering about scenarios in
which <metamark> has character content and the targeted passage isn't
coterminous with an element (and so must use @spanTo). If, for example, a
sentence from the middle of a long paragraph is circled and "delete?" is
written in the margin, I imagine I'd end up with something like:

<line>This is a keeper sentence. And</line>
<line>this is another one.
<metamark spanTo="#a1">delete?</metamark>
This one</line>
<line>I'm not sure about.<anchor xml:id="a1"/> But this one</line>
<line>is absolutely golden.</line>

A couple of things about this feel odd. For one thing, I'm uneasy about
putting textual content of metamark inside <line> if it isn't there on the
document. For another, I'm not sure what to do with the circling mark.

I think I've wandered away from critique of the guidelines here, so I'll
stop. I would, though, be interested in having someone like Elena set me
straight about this.

> > Further against @spanTo here, I'm uneasy that it means something
different
> > on
> > this element than it did on<mod>; here, it's not indicating the end of
the
> > current element but the end of the current element's referent.
>
> @spanTo means exactly the same here as on <mod> -- I don't understand
> why you think is different. What is "the current element's referent" ?

The referent of <metamark> is, in the words of the draft, "the passage to
which the metamark applies." With <mod>, the value of @spanTo points to
place where the  modification (i.e., the <mod> itself) ends. With
<metamark>, the value of @spanTo points to the place where the targeted
passage (rather than the metamark) ends. In my fake example above, it's the
difference between marking "delete?" and marking "This one I'm not sure
about."

On 08/31/2011 18:36, Lou Burnard wrote:

> >> <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).
>
> Isn't a transposition that involves
> just one chunk of text the same as a deletion and an addition?

Well, no. It's a chunk that's marked for transposition, written in one
place but marked to be moved somewhere else. I might just as well say that
a transposition involving the swap of two chunks of text is the same as two
deletions and two additions.

> 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!)

If that seems like the best way to get to a model that allows <transpose>
for single chunks, yeah, let's send it back to the workgroup. If someone
here sees a way to rejigger the thing ourselves, we could do that, too. I
myself am having a hard time to fix it without a major overhaul, but I'd
love to be wrong because <transpose> is one of the things I'd actually use
in my own work.

On 09/04/2011 18:17, Lou Burnard wrote:

> > In both of these places, the conception of<notLayer>  is narrower than
the
> > one that emerged from our discussions in Chicago. There, it was
explained
> > to me that the element/attribute could be used to corral not only
revisions
> > that were made during a particular stint but also edits that had some
sort
> > of other commonality (e.g., proofreading as opposed to substantive
> > revisions).
>
> well, but you could regard all proof reading as a single stint, surely?

What I'm imagining is a draft in which the author has, in a single stint,
done two kinds of changes, proofreading corrections (marked in, say, red)
and substantive rewrites (blue). As I understood what was said in Chicago,
this element would allow me to group all of the corrections separate from
all of the rewrites.

> >> once from a documentary perspective, and once from a textual one
> >
> > I paused over this way of naming the two views, as it seems that
elsewhere
> > in this draft you've tried to get away from shorthand terms that invoke
> > whole schools of thought. For example, I don't recall seeing reference
here
> > to diplomatic transcription or genetic editing. And the heads to
sections
> > to 1.2 and 1.3 don't use that kind of cue, either. Of course, just
after
> > the example that the above phrase introduces is a paragraph that
outlines
> > the two "perspectives" in a straightforward way, so maybe the issue is
> > placement? The more I think about it, the more generalized anxiety I
feel
> > about that last paragraph. If I were reading all of this for the first
> > time, I think I would find it strange that such a fundamental
assumption,
> > one that would seem to have implications for everything else in this
draft,
> > isn't revealed until the end, leaving me to go back and try to puzzle
out
> > what sorts of implications it has for those earlier sections.
>
> Is your recommendation to strike this para (plus the example
> presumably), or to move the para to the place earlier where we try to
> explain what this is all about -- the section headed "Transcribing the
> process"?

What I'd most like, I think, is for some other folks to weigh in. But if
forced to make the decision--unilaterally and right now--I think I'd move
to strike. Given more time, I'd probably opt to try to rewrite so as to
avoid the problematic terms.

On 09/05/2011 11:36, Lou Burnard wrote:

> Maybe "prioritize" would be better than "do no more than"?

Nice.

> thinking again, have now modified this to
>
> ... is intended to prioritize representation of the process by which the
> document came to take its present form over representation of the final
text

That's elegant. I am hereby not going to worry about the shift from
diplomatic transcription to genetic editing, trusting that Elena, et al.
will speak
up if some sort of boundary has been crossed.