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 ?

[lb42]

I have just noticed the following note in the current spec for <sp>: " The who attribute on this element may be used either in addition to the <speaker> element or as an alternative."
I humbly suggest that this possibility lends weight to my reluctance to extend the content model of <speaker> to include other things such as <stage> : is "Hesitantly John" a different entity from "John" ? if not, it can't really be a @who value can it?

[lb42]

@ebeshero : what's wrong with using @type to "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." ?

[lb42]

P.S. For the avoidance of doubt, I have no quarrel with the proposal to permit model.stageLike elements at the start of the content of a <sp> : I just don't want them cluttering up my <speaker> elements

[ebeshero]

@lb42 What if I'd like to trace a clear connection between specific characters and their stage directions? A matter of interest might be to quickly pull which characters are associated with the most speeches that have embedded stage directions. Does Glenarvon get lots more stage prompting in this script than other characters?

So the ability to position <stage> in a speech or even a <speaker> as @joeytakeda proposes would be helpful for XPath-ing to collect info. I can't do all that I'd like with @type and @subtype, and maybe I shouldn't have to set a lot more attributes if I can nest the elements in a way that demonstrates their relationship.

[joeytakeda]

Thanks, @lb42 — your noticing of that remark inspired me to take a quick look through the prose to see what else is said about <speaker> and @who. And indeed 7.2.2 Speeches and Speakers offers what seems to be another interpretation of what a <speaker> is:

The @who attribute and the speaker element are both used to indicate the speaker or speakers of a speech, but in rather different ways. The speaker element is used to encode the word or phrase actually used within the source text to indicate the speaker: it may contain any string or prefix, and may be thought of as a highly specialized form of stage direction.

There's nothing (as far as I can tell) in the Guidelines that maintains that there must be any clear alignment between what is put in @who and what is encoded as the <speaker> or that variations of a <speaker> constitute separate entities. Later on in that section, the GL's note that @who can be used if attributions are "completely regular" or what appears in the text isn't of interest:

If the speaker attributions are completely regular (and may thus be reconstructed mechanically from the values given for the who attribute), or are of no interest for the encoder of the text (as might be the case with editorially supplied attributions in older texts), then the speaker element need not be used

But in the case where neither are true, then I think it makes sense to be able to encode your understanding of the structure of the text, especially since the <speaker> is neither a substitute for the @who nor is it meant to serve as a reference to an entity, but simply as a heading/direction that indicates, in whatever way, one or more names of the characters giving the speech. I'll also note that, for better or worse,<speaker> can contain a whole host of other clutter (including notes, notated music, a graphic, time, dates, etc), much of which could not (as far as my imagination can conceive of, at least) correspond to a @who. So I see no issue in recognizing that, in some texts and in some cases and for some encoders, <speaker> contains both the who and the how of a speech.

If my interpretation is wrong, though, or if others disagree, then I think it would be good to specify both in the prose and in the element specification what the TEI understands a <speaker> to be (a specialized heading, a specialized stage direction, or something else), what the element should include, and what it shouldn't.

[lb42]

Thanks for the reminder @joeytakeda ! the prose of the GLs often resolves and reminds very effectively, as you point out. The comments on <spGrp> (and associated examples) are a case in point. As regards the subject of this thread however, it does provide examples of speaker assignations which might perhaps contain a stage, but don't -- the stage precedes or follows the <speaker> within the same <sp>. This being a long established and documented convention, I don't see any good reason to change it. Yes it's true that <speaker> contains much clutter (because its model references model.global) but the same applies to many other elements, and is no justification for adding more! I like the phrase "the who and the how" btw, but it's because the two are distinct that we have two different elements to encode them.

[lb42]

@ebeshero I find your example a little tenuous, not least because the concept "embedded stage directions" is not a very robust one. Stage directions (of any kind) can appear directly within an <sp>, or within a <p> or an <l> contained by an <sp>, or between <sp>s ... and it may be entirely arbitrary whether the encoder decides to put a <stage> as the final content fragment of an <sp> or as a sibling of it. Sometimes the typography of the source can help -- a stage direction set as a new block is probably not a nested <stage> but a sibling -- but what about phrasal stage directions set flushed to the right hand margin (a common enough convention in 19th c printed play scripts) ? But relying overmuch on the typography always makes me feel uneasy: there are so many inconsistencies!

Here's just one example I found by searching for <stage> elements which begin with a lower case letter:

<sp>
 <speaker>Caps.</speaker>
 <p><stage>impatiently.</stage> Now, my dear! Good morning, Mr. Terence O'Grady!
 <stage>sneeringly.</stage> </p>
 </sp>
  <stage> [Exit Capsicomb, Mrs. Capsicomb, and Mary, D. R. F. </stage>

What advice should the GLs offer as to how to choose amongst the following equally plausible encodings?

<sp>
 <speaker>Caps.</speaker>
 <stage>impatiently.</stage> <p>Now, my dear!  ....

or even (if you go for the Takeda proposal)

<sp>
 <speaker>Caps. <stage>impatiently </stage></speaker><p>Now, my dear!  ....

(note the, yuk, mixed content)

Note also that the "impatiently" direction clearly refers to the way the first part of the paragraph is to be delivered, hence it precedes it; whereas the "sneeringly" clearly refers to the second part of the paragraph , which it err, follows.

And note that the third <stage> "[Exit..." is placed outside the <sp> but could equally well be within it -- if for example it were not an exit but some piece of business.

All of which is really just to say that the position of a <stage> element is fairly unpredictable, and hence not a good criterion for categorising it!

[lb42]

HOWEVER, just to show fair play, here's an example of something I really do not know how to encode, without abandoning the principles I have been defending!

"(R.C.)" etc is a stage direction indicating where the speaker stands. So we could handle this with stage inside speaker:

<sp><speaker>Philip. <stage>(R.C.)</stage> and Kitty. <stage>(R.)</stage></speaker>
  <p>I hope your honour will not take away our bread.</p></sp>
 <sp><speaker>Lovel.</speaker><stage>(L.C.)</stage> 
   <p>Five hundred pounds will set you up in ...</p></sp>

It works, more or less, but I hate it. :-(

[martindholmes]

I tend to agree with @lb42 here, and I don't really think that <speaker> and <persName> are in any way the same thing; a speaker label may be many things other than a personal name (Chorus, for instance), and the element is capturing the functional role of the label rather than its lexical category.

So I think if simply allowing <stage> to precede <speaker> in the content model of <sp> will solve the immediate problems (ignoring for the moment @lb42's rather unusual example), I would suggest we simply do that, rather than anything more dramatic (forgive the pun).

[JanelleJenstad]

Without getting into the many facets of the debate unfolding in the comments on this ticket, I'd like to suggest one easy immediate tweak that @jjokisch can make: Add a @who attribute to the <stage> element so that you aren't relying on the XML tree to imply who is remaining.

Here's how we would encode this particular case at Linked Early Modern Drama Online, using our custom values for the @type attribute. In a transcription, we'd omit the <speaker> because there isn't a speech prefix in the source. In a modernized text, we'd supply the speech prefix and collate it to indicate that the speech prefix was our interpolation.

<stage type="remain" who="#glenalvon">Manet GLENALVON</stage>
<sp who="#glenalvon">
<l>Child that I was, to start at my own shadow,</l>
<!-- more lines -->
</sp>

(And if you ever want to track who is coming, going, and staying, I strongly suggest putting a @who attribute on all <stage> elements with @type values of entrance, exit, and remain. This information allows you to track characters through the play and create charts of possible doublings.)