> 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

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]