[tei-council] Anyone for roles?

Lou Burnard lou.burnard at oucs.ox.ac.uk
Wed Jan 14 08:02:05 EST 2009


In what may turn out to be the first of a series, I'd like to canvas the 
Council's views on one of the knottier problems in the current selection 
of feature requests, which has also since turned up in other contexts.

SF #195420 proposes that @role should be added/reinstated for all 
elements which are members of att.naming (in fact, I don't think it ever 
was available on names, though this may have been proposed before)

Discounting its use to indicate the function of a cell in a table, or to 
name a character in a drama, at present @role is available only on 
<org>, <person>, <personGrp>, and (rather strangely) <editor>, where it 
can be used to specify "a primary role or classification for the x" 
(where x is person or org) or "the role of this group of participants in 
the interaction" (<personGrp>), or (perhaps rather strangely) "the 
nature of the intellectual responsibility" (<editor>)

Leaving aside for now the last case, the thinking behind this is the 
usual distinction between a NAME and a NAMED ENTITY. The NAMED ENTITY 
can have a role, but a NAME cannot. The role attribute answers the 
question "what is the function of this person in this context" not 
"what is this name doing in this context". A similar topic popped up 
with reference to geographical information on TEI-L recently -- <geo> 
belongs to <place> not to <placeName>. That's the current orthodoxy.

However, all orthodoxies have to be challenged occasionally, and there 
are two disadvantages with this one

a) one man in his time plays many roles (SHAKSPR) -- but @role is 
unitary. We have ways of recording that someone has been at various 
times a butcher, a baker, a candlestick maker etc. but no obvious way of 
saying that in the context where he's being named, it's as a ferret-wangler.

b) the additional baggage of a <person> record is not so easy to 
maintain, especially where we just want to say "this person name refers 
to some binder or other" without going to look up all the gory details 
in Wikipedia

It's not hard to think of use-cases -- quite a few pop up in manuscript 
description. Maybe we should subvert @key for the purpose, but I can see 
the merit of the SF proposal before us as simpler and possibly more 
intuitive.

What do you think?

And, if you agree that this proposal should be implemented, what do you 
think we should do with the existing @role attributes? There's obvious 
scope for confusion if we retain them. Should they be removed? Maybe 
their function would be better served by using @type? (That certainly 
seems to be the case for the @role on <editor> -- which seems to have 
got itself confused with <respStmt>, but that's another story.)


More information about the tei-council mailing list