Hello all,

This is mostly a re-hash of the thread with minimal extras.

It appears to me that the implicit model here has, minimally, a domain 
(e.g., an episode) and a set of characters with some kind of 
"prominence" feature, which is active either within the domain, or which 
holds of domain+character pairings. The entire thread suggests to me 
that a more universal approach would involve a hierarchy of domains (an 
episode consists of interactions, and "prominence" may change between 
one and the other, and there may be flashbacks to episodes/interactions 
with their own "prominence" values that nevertheless do not affect the 
prominence at the level of the entire episode).

(I'm sure I would be inclined to pick on, if not to gnaw at, the 
definitions of "primary" vs. "secondary", so I'm conveniently putting 
that aside and using Michael's "prominence".)

In terms of serialization, this could be done by taking Lou's idea to 
encode the primaries and secondaries in attributes with multiple pointer 
values within the serialization of each potential domain, where relevant 
or applicable. This could extend to what Ondine has remarked on, namely 
to situations in which you want to point outside the current cast. If a 
new class of such two attributes would be too much to ask for, some of 
Michael's proposals would offer a ready alternative (an extension of the 
cast list to also mention the "absent ones" could probably be disputed, 
but both the particDesc and standoff approaches would I think handle 
that easily). I have to say, though, that I am not sure how Michael's 
suggestion would handle the relative hierarchy of prominence... in the 
sense that I mentioned above, where you have flashbacks or 
scenes/interactions with different prominence that do not affect the 
current episode's overall prominence structure -- that might be 
difficult to express in the particDesc.

I've tried to push this towards generality, but I HTH in this particular 
case as well.

Best wishes,


On 03/16/18 18:15, C. M. Sperberg-McQueen wrote:
>> On Mar 15, 2018, at 6:56 PM, Elisa Beshero-Bondar <[log in to unmask]> wrote:
>> ...
>> We were working on the ODD schema for their project today, and I was finding myself stumped to determine the best way to indicate that a given character in a script is primary or secondary. Their files do not begin with a cast list, but instead are simply encoded thus:
>> <sp who="#speakerID"><speaker>name</speaker><p>talking here.</p></sp>
>> ... My student (who's a pretty sharp Lit major) asked, "Surely people who code TEI projects have some way of indicating primary vs. secondary characters?" and my answer was, "Hmmm. I'm not sure...I wonder if other people I know do that?" So I'm turning to the list to inquire--if any of you have encoded literary projects in TEI (say of plays, novels, verse narratives, etc) with interpretive markup to distinguish primary vs. secondary characters, and if so, how you've done it?
> The answers so far seem focused not on how to encode the analysis you
> describe, but on commenting on that analysis, suggesting ways to make
> it better, asking whether it makes sense in the first place, and
> wondering whether you could do without it.  So perhaps there is room
> for a response that tries to answer the question as asked.
> As you describe it, the primary/secondary distinction is not a
> property of characters per se but of a character in an episode, or
> equivalently of (character, episode) pairs.  (For that reason,
> encoding it as an attribute on the first speaker element for the
> character, or on the first speech element for that character, feels
> wrong-headed to me: it is not a property of that particular speech, or
> that particular speaker attribution, as opposed to others.  But the
> mechanism you describe does achieve the goal of ensuring that the
> information is encoded once for each (character, episode) pair.  Full
> marks to your students for seeing that necessity.)
> One natural place to encode information about a character in a
> particular script is in the cast list.  The project’s decision not to
> include cast lists thus makes this problem look harder than it needs
> to be; if that decision is not firmly grounded, perhaps it could be
> revisited.
> Another natural place would be particDesc.
> A third place, which will feel natural to some observers and probably
> not to others, would be in a separate free-standing document, which
> one could regard as offering a kind of stand-off annotation.  (Those
> with experience in relational modeling will recognize an analogy to
> the relational tables used to model n:m relations among entities.)
> And of course you could also add a structure to the personography
> entry for each character specifying (a) which episodes the character
> appears in and (b) their prominence in the episode.
> I hope this helps.
> ********************************************
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> [log in to unmask]
> ********************************************