[tei-council] 13 Names, Dates, People, and Places

[Lou's Laptop]

Brett Zamir wrote:
>
> One general question first if I may... Is there a means at present to 
> indicate the value for a <date> which is not W3C or ISO standard? 
> Under which attribute could some normalized (but non-W3C/ISO-standard) 
> form be placed? I don't see any @value attribute anymore... I forget 
> where you all are with this one...

No. There is enough confusion in the world as it is... you can make the 
*content* of your date element whatever format you please, but the 
consensus was in favour of restricting the normalized attribute values 
to forms which there was at least a chance that generic XML schema 
processors (etc) would be able to validate. Some felt that we should 
choose *either* W3C *or* ISO formats but not both. The current state of 
affairs is a bit of a halfway house in that direction. Of course if you 
want to add an attribute to supply a value normalised according to some 
other scheme you can do so, but the TEI isn't going to.

>
> How about renaming the chapter to Names, People, Places, and Dates to 
> keep the People-Place-Thing sequence together?
You mean because dates is the last thing discussed in the chapter? well, 
possibly. but the council chose this title after much debate, so I am a 
bit reluctant to change it.

>
> *13.1.1 Linking Names and their Referents
> *
> For this line, "These attributes are designed to support two different 
> ways of associating a name, of any kind, with its referent, and with 
> its canonical form.", there seems to be no explanation of what these 
> two ways are (and the introduction of 3 attributes previous to this 
> might suggest that there are three ways instead of two.
>
The rest of this section discusses this. There are 2 different ways of 
linking name and referent, and one way of linking name and canonical 
form, hence 3 attributes. I tinkered with the sentence a little to see 
if I could make it a bit clearer.

> *13.2.1 Personal Names
> *
> Middle names and names containing references to a city/town/village of 
> origin would seem to me to call for their own tags given their 
> frequency. Are there are plans for this?
>
Not currently, but you can certainly propose such additions.

> *13.2.3 Place Names
> *
> Since, as indicated by footnote 40, it seems "figurative" may be 
> implied by use of <rs>, how about adding that to the definition of 
> <rs>? Otherwise, it is not immediately clear how <rs> may differ from 
> <name>.
The distinction between rs and name is discussed in the core chapter. 
I'm not sure that either this example or the footnote is really helpful 
or utterly reliable... an <rs> is not necessarily figurative.

>
> *13.2.3.1 Geo-political Place Names
> *
> For <bloc>'s definition (not in source), how about adding a hyphen 
> within "nation state"?
>
Wikipedia doesnt use one.
> *13.2.3.2 Geographic Names
> *
> 1) Is there a specific place in the head for the policy on name tag 
> choices (e.g., geogName over placeName)?
I assume by "head" here you mean "header" -- and no, there isn't. Is the 
distinction between <geogName> and <placeName> not adequately defined? 
it's rarely a policy decision which to use I would have thought!

>
> 2) Add a comma to the definition for <geogFeat> (not in source), after 
> "mount" and before "etc.".
>
OK

> 3) Are there special tags for things like a famous residence/mansion?
>
These would be types of placeName, I suggest, since they are geo-political.

> 4) Both in this line, "The most efficient way of including this 
> information in the above encoding would be to create a separate 
> <gi>nym</gi> element for this component of the name and then point to 
> it using the <att>nymRef</att> attribute, as further discussed in <ptr 
> target="#NDNYM"/>." and in the Nym section to which it points, there 
> is no indication as to where <nym> should be placed...
>
A <nym> can only appear within a <listNym> (or another <nym>), as the 
specification states. It is exactly analogous to <person> and <place>.

> *13.3.1 Basic Principles*
>
> 1) For the line, "Characteristics</soCalled> or 
> <soCalled>traits</soCalled> are typically independent of an 
> individual's volition or action and can be either physical, such as 
> sex or hair and eye colour, or cultural, such as ethnicity, caste, or 
> faith." I really disagree with including "faith" as something which is 
> independent of an individual's volition or action.
But many people are born into a faith, are they not? they cannot be said 
to choose that any more than they choose their parents? Of course they 
may go on to choose a different faith, but even when they do, they will 
often say they are an "ex-muslim" or "ex-jew" or whatever.
> While people do often imitate their parents and treat faith (or lack 
> of it) as a matter of inheritance, it makes little sense as such 
> (granted, in some cases, for historical reasons, it has become 
> associated with race, but there is always a means of distinction). If 
> the description stayed with the idea that these features tend not to 
> change very much over time (like political party affiliation or lack 
> of affiliation or the <affilitation> element which is a "state"), I 
> think this would be fairly reasonable, though it may be just as 
> changeable as a place of residence or occupation.
>
We will probably have to agree to disagree on this one!

> 2) Also, the definition of <state> (not in source), says that it 
> refers to some "ongoing status or quality", which would seem to 
> contradict the sense that it is more of a less-fixed quality than 
> <trait>, for example; should it be changed to "potentially alterable 
> status or quality"?. And for the definition of <trait>, did you want 
> to indicate in the definition that it was "relatively fixed" as well 
> as "culturally-determined"?
>
I've tried to improve the descriptions for both state and trait to make 
clearer that the fundamental distinction between them is to do with 
changeability

> *13.3.2.2 Personal States*
>
> 1) Again on some of the "changeable" characteristics, I find it 
> inconsistent that <education> is a state, but <langKnown> is a 
> characteristic.
>
Yes, I see that this does look a bit odd, and maybe langKnowledge is a 
boundary case. But education is definitely a state, surely?

> 2) The example beginning, "<person xml:id="simon_son_of_richard2">" 
> seems it ought to have an introduction before it...
>
OK, added a sentence

> *13.3.2.3 Personal Events
> *
> "It [event] is used to describe any event in the life of an 
> individual.". Since the definition at 
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-event.html 
> mentions it can also refer to an organization, might this be amended 
> to say "individual or individuals"?
>
OK, yes.


> *13.3.2.4 Personal Relationships*
>
> 1) Can <relation/> elements be placed in their own dedicated document?
yes, since they are linked to by pointer and a TEI pointer can now go 
across documents. However, I think we need a lot more description about 
where these elements are best placed.
>
> 2) Also, might this section mention where <relationGrp> and <relation> 
> can be placed? While this kind of information could be found in the 
> manual, DTD, etc., I think it helps to have an anchor to know where 
> these items are going.
Yes, I agree. In most of the examples, they are included along with one 
or other of the things being related, but I am not sure that this will 
always be the best solution. Some more thought is needed on this topic.

>
> 3) Might also some mention be made here of ontologies (since this 
> section's topic seems to impinge on the issue)? (I think it might also 
> be nice to allow <relation> for any item, concept, dates, etc...)
>

We were hoping to keep this chapter comparatively modest in scope...
> *13.3.4.1 Varieties of Location*
>
> The definition of <geo> at 
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-geo.html 
> states, "If no such element is supplied, the assumption is that the 
> content of each geo element will be a pair of numbers to be 
> interpreted as latitude followed by longitude according to the World 
> Geodetic System." Especially since no example is provided there, maybe 
> the end could be emended to state "interpreted as latitude, followed 
> by whitespace and then longitude"? And perhaps also mention could be 
> made of the intervening whitespace for the line which is in the 
> chapter, "The default recommended by these Guidelines is to supply a 
> string containing two real numbers which indicate latitude and 
> longitude according to the 1984 World Geodetic System (WGS84)"?
>
OK, have added reference to white space in both places and an example in 
the tagdoc. There is an example in the text, btw.

> *13.3.5 Names and Nyms*
>
> For the examples with a @nymRef leading to a <nym> with a <form> (in 
> this case "Antony" for "Tony"), I think it might be helpful to 
> indicate whether this construct implies that the individual in 
> question actually had this name (as on a birth certificate) or not, 
> and if not, a reminder of where that information should be placed.
>
No, the <nym> has *nothing* to do with any individual who happens to use 
one of its forms. That information would be implicit by the <persName> 
attached to the <person>. I've added a sentence to try to make that clearer.



> *13.3.6.3 More Expressive Normalizations*
>
> Might you add a footnote to 
> http://www.iso.org/iso/catalogue_detail?csnumber=40874 for the 
> reference to the ISO "Data elements and interchange formats – 
> Information interchange – Representation of dates and times" standard?
>
Well, it is not our general policy when citing ISO or other standards to 
point to places you can buy them from. But I agree there should probably 
be a better bibliographic reference for this as for the other ISO 
standards cited in the text.