[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