[tei-council] regularizing names

[Lou Burnard]

The main problem I have with this is that all the examples cited seem to 
be about linking the name to a PERSON not to a NAME, in which case the 
existing key attribute would surely be more appropriate? (That's not to 
say that having a <regName> child within <person> wouldn't be a good 
idea). But the only use for having both a reg attribute and a key 
attribute on a name ought to be for one to regularize the name, and the 
other to regularize the thing-named. In which case, we have to be able 
to support the reg attribute on components of names, e.g.
<name key="JF">
<forename reg="JULIA">Juley</forename>
<surname reg="FLANDERS">Flanderes</surname>
</name>

<person ident="JF">
<regName>
<forename ident="JULIA">Julia</forename>
<surname ident="FLANDERS">Flanders</surname>
</regName>
<!-- other demographic info here -->
</person>

[I've used co-labelling here rather than ID/IDREF but the same principle 
applies]

in haste

Lou
Julia Flanders wrote:

> Here's what Perry and I have come up with concerning the 
> regularization of names.
>
> We propose, tentatively, that in P5 we handle the regularization of 
> names as follows:
>
> Name elements (<name> and the other "primary" name elements including 
> <persName>, <placeName>, <orgName>, <geogName>) may carry a reg= 
> attribute, which points to a <regName> element which contains 
> information on regularization. This element might live in the TEI 
> header or in some other convenient place. The datatype for reg= would 
> be tei.data.code. The element name (<regName> as against <reg>) is 
> chosen to help distinguish the function of this regularization 
> structure from other kinds of regularization in the document.
>
> The nested naming elements such as <foreName>, <surname>, etc.--i.e. 
> those which cannot occur on their own but must be nested inside a 
> primary naming element--would not carry the reg= attribute and cannot 
> be regularized independently. We considered a mechanism for doing this 
> and if any Council members think it would be a good idea we can add 
> this bit.
>
> The <regName> element may either contain a regularized version of the 
> name as its content, or it may carry a pointer to an external resource 
> (either locally maintained or an authority file external to the 
> project, such as Library of Congress Name Authority files). It could 
> also do both, and we don't see a need to police this choice (e.g. by 
> making these options exclusive).
>
> The <regName> element would carry three attributes:
> --authority= indicates what authority, if any, is being used as the 
> source of the regularization, with values such as "NACO", other 
> possibilities
> --url= (or target=) points to an external resource
> --xml:id= allows the element to be pointed to from the naming element 
> in the text.
>
> Example:
>
> <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
> <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, 
> Jr.</regName>
>
> <!-- above <regName> elements may be somewhere in <teiHeader> or 
> <hyperDiv>,
> and may be part of a new prosopographic element -->
> <!-- ... -->
> <name reg="#rn17">Bill Clinton</name>
> <persName reg="#rn18">Buzz Aldrin</persName>
>
> We are still concerned about how this use of reg= and <regName> will 
> fit in with other forms of regularization (e.g. spelling). However, 
> since all other uses of reg= will probably now be addressed as child 
> elements, the possibility of confusion is diminished.
>
> Comments welcome--
>
> Julia
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>