Introduce a way to set stage directions prior to speech prefixes

[jjokisch]

I have noticed repeatedly that stage directions do not just form structures with speech prefixes by following them but quite frequently precede them or simply have one word in the stage direction appear typographically marked as the speech prefix. There are countless examples really:

John Home's Douglas (1757)

Jean-Baptiste Legouvé's Attilie (1775)

The problem with that being that <speaker> can only occur as the first child of <sp> and neither can <speaker> be nested in <stage> nor <stage> in <speaker>. Thus, while I can encode, for example, "GLENALVON solus" as <sp><speaker>GLENALVON</speaker><stage>solus</stage>[...]</sp> a construction like "Manet GLENALVON" or even "Manet GLENALVON solus" only allows for rather questionable encodings, i.e., (1) by disassembling the entire structure:

<stage>Manet</stage>
<sp>
<speaker>GLENALVON</speaker><stage>solus</stage>
</sp>

or (2) by giving up on the nuance between speech prefix and stage direction:

<sp>
<stage>Manet <persName>GLENALVON</persName> solus</stage>
</sp>

@DanilSko actually had made me aware that the DraCor group had also run into this issue before: dracor-org/udracor#11

(2) seems the less favorable as it opens the door to all kinds of terminologically unsound arguments. After all, if "Manet GLENALVON solus" is merely a stage direction, why wouldn't "GLENALVON" not be one as well? And if it were a stage direction with a <persName> in it, why would we ever use <speaker> for a speech prefix and not consider all speech prefixes merely as names?

(1) could probably be remedied with @part. However, there is nothing in the structure itself that would prohibit it from being encoded consistently in a well-formed manner. We would be sticking a band-aid constructed to overcome nesting problems on an issue that does not arise from a problem with hierarchy but from the schema limitations. Thus, I wonder if it would be feasible to change the definition for <speaker> or <stage> to either allow <stage> to precede <speaker> in <sp> or to allow one to be nested inside the other. Thus, one of the following options:

<sp>
<stage>Manet</stage><speaker>GLENALVON</speaker><stage>solus</stage>
</sp>

<sp>
<speaker><stage>Manet</stage> GLENALVON <stage>solus</stage></speaker>
</sp>

<sp>
<stage>Manet <speaker>GLENALVON</speaker> solus</stage>
</sp>

There probably are other options and hopefully better ones, as I find none of the three overly compelling. The last one seems to me the least egregious one, however.

[ebeshero]

@jjokisch Sorry for the late reply, I was distracted by the end-of-year holidays but puzzling over this earlier I remember.

If I understand the problem correctly, it's about encoding the stage direction in its literal position on the page as it relates to a speech. Since "Manet" in your first example is indicating that Glenalvon is staying behind for delivering a soliloquy, it does definitely make sense to include that as a <stage> in the <sp> element to characterize the speech.

In our description and as it seems, regular encoding practice (you, me, DraCor, etc) we think of the <speaker> element as representing consistently the way the name of the speaker is represented in the text: The Guidelines define this element as containing a "form of heading or label" which helps to convey that intention. As I see it, working with the current TEI-All schema:

• We could "fudge" the layout a bit and give the <speaker> name first and follow it with the <stage>Manet</stage>, but that's not satisfying because it changes the order we see in the source text.
• We could set the <stage> ahead of the speech and use a <name> element inside, but that's not satisfying because it separates the stage direction from what it's intended to describe, the speech.

I'm not sure that there's any good reason we don't permit <stage> as a first child of <sp>, and I think that's my recommended solution to this problem is to allow it in the TEI. There are a number of ways we could do that. Since <sp> currently allows zero or more of any element in model.global before <speaker>, it seems that an easy and flexible way might be to give model.stageLike membership in model.global. (model.stageLike contains <camera>, <caption>, <move>, <sound>, <stage>, <tech>, and <view>). Looking at model.global some of that is likely relevant to interesting and unusual text events, but it seems odd we don't get the stage directions here while we do get the contents of model.global.spoken.

Thoughts?

[ebeshero]

If you and Council agree with this resolution, we might be able to fit this into the 4.9 release, but we should discuss it first...holding off on setting a milestone until we do.

[joeytakeda]

The question —"And if it were a stage direction with a <persName> in it, why would we ever use <speaker> for a speech prefix and not consider all speech prefixes merely as names?"—is an excellent one, especially given that the definition of speaker is as follows:

<speaker> contains a specialized form of heading or label, giving the name of one or more speakers in a dramatic text or fragment

One (somewhat unsatisfying) answer to that question is that <sp> does not allow either <label> or <head> in its content model, so <speaker> has become the only way in which to denote the label/speech prefix in a speech. But I think the problem here is that there has been a bit of a slippage between using <speaker> as a "specialized form of heading or label" versus using <speaker> as a specialized form of <persName>.

Following that definition, I think @jjokisch 's option (2) is close to what I'd suggest except using <speaker> as a wrapping label/heading and then encode the name of the speaker using something like <persName>:

<sp>
    <speaker>Manet <persName role="speaker">GLENALVON</persName> solus</speaker>
</sp>

While this abides by the theoretical definition of the element, I think this would be "questionable" for precisely the reasons that @jjokisch argues.

So I agree with @ebeshero that <stage> should be allowed before <speaker>, but I want to forward some further questions for discussion:

1. Should we also allow <head> (to align with <spGrp>?) as a child of <sp> (and allow stage before it, too)?
2. Given the way <speaker> has tended to be used (as a kind of shortcut for a head[persName]), should <speaker> be allowed as a child of <head>? That would require updating the definition of <speaker> slightly, but would also allow for more consistent encoding practices (e.g. so that one didn't need to decide between using sp/head[persName] or sp/speaker)

So I think the encoding could look something like so:

<sp>
<head>Manet <speaker>GLENALVON</speaker> solus</head>
</sp>

<sp>
  <stage>(Elle s'eloigne de quelques pas &amp; s'arrete)</stage>
 <head>Pendant ce temps, <speaker>ADRIEN</speaker></head>
 <p>Je la perds! ...</p>
</sp>

<sp>
   <stage>(Hesitantly)</stage>
   <head><speaker>JOHN</speaker></head>
</sp>

<!-- Which would be semantically equivalent to -->

<sp>
   <stage>(Hesitantly)</stage>
   <speaker>JOHN</speaker>
</sp>

<head><speaker>JOHN</speaker> <stage>(Whispering)</stage></head>

While this introduces the problem of many ways to say the same thing, I think it better allows for accurately representing a wider range of dramatic practices.

[ebeshero]

@joeytakeda If you take a look at the content model for <sp>, see if you agree with me about adding model.stageLike to model.global as a way to resolve this and make the content model more flexible, too?

[lb42]

Sorry, but I think this change would introduce needless ambiguity and confusion. The definition of <speaker> is quite clear: it is a specialised kind of heading, which serves to indicate the speaker of the sibling element, and it is always contained by an <sp>, currently as its first child. Speaker names may indeed appear in any number of other places, notably within stage directions; and the speaker of a particular speech may have to be inferred, rather than being explicitly given by a preceding speaker element. That's life in the big (print) city. I think there is a tendency amongst some encoders to try to make <speaker> do the job of @who . It's not meant for that, imffho.

To answer Joey's questions:

1. No. <head> has different semantics from <speaker> and should not be permitted within <sp>. It is however permitted within< spGrp> where it introduces a different kind of heading from a speaker such as "Trio: (Tom Dick Harry) Air : Loch Lomond" . I shall try to raise a separate ticket about that sort of thing.

2. "Given the way has tended to be used" (as a kind of shortcut for a head[persName]) is not really a good reason for recognising or validating this foolishness.

[lb42]

p.s.
FWIW, here are my proposals for those encodings

<stage>Manet GLENALVON> solus</stage>
<sp>.... </sp>

<!-- or if you are sure of it -->

<sp who="#glealvon"> ... </sp>

  <stage>(Elle s'eloigne de quelques pas &amp; s'arrete)</stage>
   <sp>
 <stage>Pendant ce temps,</stage>
<speaker>ADRIEN</speaker>
 <p>Je la perds! ...</p>
</sp>

<sp>
   <stage>(Hesitantly)</stage>
   <speaker>JOHN</speaker>
   <p>... </p>
</sp>

<!-- or, equivalently, -->

<sp>
   <speaker>JOHN</speaker>
   <stage>(Hesitantly)</stage>
   <p>... </p>
</sp>

[ebeshero]

@lb42 We're already permitting a different content model for <sp> that allows for zero or more of any element in model.global as its first child, before <speaker>. See for yourself: https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-sp.html

Surely we should recognize that "Manet" describes Glenarvon's being alone on stage in delivering this soliloquy, so the <stage>Manet</stage> adds information about the conditions of the speech that follows, doesn't it? Separating the <stage> element so it is not a child of the <sp> is only necessary in the current TEI P5 because <stage> (and its ilk in model.stageLike) are not members of the group of elements that we decided should be permitted as an optional first child of <sp>.

Looking at model.global I see no reason why we should not include model.stageLike here when the other elements present include elements that describe a speech act (in model.global.spoken) and members of model.noteLike.

And members of model.stageLike are allowed elsewhere in the contents of <stage>. It's strange that we did not conceive of them as potentially appearing before the <speaker> label. To me the most meaningful encoding of Glenarvon's soliloquy is simply:

<sp>
   <stage>Manet.</stage>
   <speaker>GLENARVON</speaker>
   <l>...</l>
   ...
   
</sp>

I suppose a lot depends on how you see stage directions, but it is common to see them qualifying how speeches are delivered. In this case, allowing model.stageLike as a first child satisfies the order of its appearance in relation to the label of the speaker and the contents of the speech without separating it from the speech act and complicating how we encode Glenarvon's name.

[ebeshero]

@joeytakeda It's interesting to consider the role of a <head>element as basically labeling the contents of a speech, but it does add more encoding. It would potentially help to relate the stage direction to the speaker by pairing them as children of the head element, so I like that example of yours. But I am not sure we need it, since <stage> elements can appear elsewhere in <sp> and serve as a kind of metadiscourse already.

I think when we decided to allow model.global optionally as a first or last child of <sp> we should just also have allowed for <model.stageLike> in those positions, too.

[joeytakeda]

The definition of <speaker> is quite clear: it is a specialised kind of heading, which serves to indicate the speaker of the sibling element, and it is always contained by an <sp>, currently as its first child. Speaker names may indeed appear in any number of other places, notably within stage directions; and the speaker of a particular speech may have to be inferred, rather than being explicitly given by a preceding speaker element. That's life in the big (print) city. I think there is a tendency amongst some encoders to try to make <speaker> do the job of @who . It's not meant for that, imffho.

I think we're arguing a similar point, though with different conclusions. It's not that I think <speaker> should be like <persName> or some such (I agree that <speaker> has frequently been used to do the work of @who), but rather that the <speaker> element should be used as a heading, which may contain all sorts of stuff (including stage directions and a speaker's name). In other words, if it is a specialized heading, then we should recognize that there may be things outside of the speaker's name within that heading; my goal in suggesting <head> was for the sake of making that kind of equivalence explicit and for grouping things together, but I agree it may add confusion.

Regardless, I do still think we should allow for a variety of structures that allow <speaker> to function as a heading, allowing <stage> before, after, and within the <speaker>, so that encoders can — if they choose — capture the structure as they see it.

In other words, I don't see why this encoding:

<sp who="#adrien">
    <stage>Pendant ce temps,</stage>
   <speaker>ADRIEN</speaker>
</sp>

where the entire heading structure is "disassembled" (to use @jjokisch excellent phrasing) into a stage and speaker is necessarily preferable to something like so:

<sp who="#adrien">
   <speaker>Pendant ce temps, ADRIEN</speaker>
</sp>

or

<sp who="#adrien">
<speaker><stage>Pendant ce temps</stage>, Adrien</speaker>
</sp>

or

<sp who="#adrien">
<speaker>Pendant ce temps, <name rend="uppercase" ref="#adrien">Adrien</name></speaker>
</sp>

I think all four of the above should be valid (1 and 3 are not at the moment) — meaning that I agree we should add model.stageLike alongside model.global as Elisa suggests as well as expand the content of <speaker> so that it can contain <stage> as well.

[ebeshero]

@joeytakeda Ah, I see your idea more clearly now, thank you! Yes, and I especially like the precision of being able to encode meta-information about the speaker in the <speaker> element itself if one wishes. Of these examples you now provide, I think I’d apply the second or third, because in my drama projects I tend to want to pull and analyze all the stage directions separately from the contents of speeches.

These encodings, with <stage> optionally allowed in <speaker>, would let us easily retrieve with XPath, etc) the stage directions closely associated (with character movements and expressive behaviors as distinct from those to do with general scene setting. I think this idea of building what we can optionally do with <speaker> would add expressive capacity currently lacking in our drama encoding. What do you think, @jjokisch ?