[tei-council] persName question

[Lou Burnard]

James Cummings wrote:
> 'persName' picks up a @key, @ref, and @nymRef from att.naming.
>
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-att.naming.html
>
> @key is defined as data.key = any unicode string
> @ref is defined as a single data.pointer = any URI
> @nymRef is defined as 1–∞ data.pointer = any number of URIs.
>
> I'm in a situation where a project wants to point from something like:
>
> <persName>Mr and Mrs Smith</persName>
> or
> <persName>The Smiths</persName>
> or
> <persName>The Smiths and little johnny</persName>
> or
> <persName>The Smiths and little johnny and his 3 sisters</persName>
>
> well, though maybe those last two are stretching it.
>
> What I'm wondering is why @ref and maybe @key are also one to infinity like 
> nymRef?
>
>   

I assume there is a "not" missing here. On that assumption, my answer is 
"Homer nods".
We already permit e.g. <sp who="#X #Y"><speaker>X and 
Y</speaker><stage>speaking together</stage><p>gadzooks</p></sp> so I 
cannot for the life of me see why we shouldn't permit exactly what you 
want<persName key="#X #Y">The Smiths</persName>



>
> I'm just trying to remember what the logic was in allowing nymRef to have 
> more than one URI but having ref only allowed to have one?  

@nymRef clearly has multiple referents because the same name may have 
more than one underlying nym e.g. <persName nymRef="#JAS #CWM">James 
Cummings</persName>


>
> Wouldn't it be a lot better to allow:
>
> <persName ref="#SMI01 #SMI02">The Smiths</persName>
>
>   
I think this is correct.
> Other options open to me as I see it:
> a) abuse the whitespace allowed in @key (oops maybe not)
>   
@key is a different question however. The current state of affairs says 
you can put anything you like in there, so I would not want to change 
it. You might have a local system which wants you to say e.g. "A&B" 
rather than "A B" or "A;B" and we shouldn't mess with that.

> b) add an entire new attribute (good but I wanted to avoid extra namespaces)
>   

unnecessary and inconsistent

> c) use some abusive local encoding format that I then canonicalise to a 
> pure TEI solution at a later date.
>
>   
abominable