It's an interesting problem. On the one hand, the <castList>, <castItem>
etc. are clearly intended for use when encoding an existing dramatis
personae, found in the front matter of a source edition, warts,
inaccuracies, and all. They're not meant to be used to record
descriptive metadata about the source provided by a modern transcriber,
for which (as SPQR has noted) <particDesc> seems more appropriate. It's
the same distinction as that between <docAuthor>, <docTitle> etc. and
<author> <titleStmt> etc.
If you *do* use them for that purpose, you seem to risk confusion (there
are after all a few plays of Shakespeare which have their own cast
lists: wouldn't you want to keep these quite distinct from the modern
editorial cast list?
Is the answer to permit <castList> as a component of or alternative to
And while we're there: what element should the attribute @who be used to
On 07/05/15 04:11, Martin Holmes wrote:
> Actually, we're working on exactly the same problem for the Internet
> Shakespeare Editions project: cast lists which are the work of modern
> editors rather than forming part of the source text.
> I like the idea of making the content model of <role> similar to that
> of <person>. That's a rich selection of elements, but those from
> namesdates especially would be very useful in providing richer
> information about <role>s. <role> itself already has a strange
> assortment of items from namesdates, but lacks some of the most useful
> such as <age>, <birth>, <death>, or <faith>.
> On 2015-05-06 10:48 AM, Martin Mueller wrote:
>> I have been thinking about ways of classifying characters in early
>> modern plays in terms of sex, age, social status, and relations to other
>> characters so that a corpus-wide view of the literature would give you
>> some sense of change over time by just looking at cast lists or their
>> equivalents. There doesn’t seem to be any obvious way of putting that
>> information into the <castList> elements. The Folger Digital Editions of
>> Shakespeare’s text have used <particDesc> in the header to convey some
>> of that data. The <person> element that is the key to <particDesc> would
>> do a lot of the work.
>> Would it make sense to allow the child elements of <person> as child
>> elements of <role>? Have others wrestled with similar problems and found
>> good solutions? Graph databases (about which I know next to nothing)
>> seem a promising avenue for storing and analyzing that kind of data. But
>> they are a very different animal from TEI.