[tei-council] Comments on Place proposals from TEI

[Lou Burnard]

Dear Tom

Many thanks for your timely comments. I've alerted the Council to your 
wiki page and also I think we have a link to it from the relevant trac 
item for our own agenda.

Here are my personal reactions to your comments, not to pre-empt the 
further discussion I expect to take place next week :

1. If accepted, the testplace proposals  will probably be integrated 
into the existing  chapter on Names of Places and Persons which has also 
undergone quite a lot of revision as you note. You might like therefore 
to point to the current state of that chapter which is (as of this 
morning) at 
http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=ND 
rather than the unrevised last stable version -- this is dynamically 
generated from the svn repository in which changes are being made at a 
great rate of knots

2. Thank you for the nice remarks about what distinguishes the TEI from 
the rest. You're right that we need to be clear about why the TEI goes 
down this particular muddy well trodden track at all, and certainly to 
alert readers of the Guidelines to other possibilities where they exist.

3. Named time periods. The treatment of dates and times has just 
undergone major surgery in order to support various kinds of automatic 
processing and validation, mappings to both ISO and W3C date formats 
etc. When the patient is mobile again, I agree that we need to start 
thinking about "named" dates. It should not be too difficult.

4. Linking assertions with responsibility statements is a recurrent 
thread. We have discussed a generic <assert> element, to combine an 
assertion with an indication of responsibility and certainty, but backed 
away from it as being too complex, and not adding much beyond what the 
existing @resp and @cert attributes provide; also there is an existing 
method for marking certainty 
(http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=CE) 
which should be taken into consideration.

5. Adding GeoRSS is definitely an option. We only specified GML because 
that was the one we found on the web... no intention of being exclusive.

6. <relation> vs containment. It always makes me uneasy to have too many 
ways of doing exactly the same thing, but it's hard to see what 
containment could mean for <place>s within <place>s other than what is 
proposed, nor to argue against allowing for relationships other than 
containment, so we wound up with both. Contrast this with the discussion 
of what <nym> within <nym> means -- something quite different.

7. <locale> was a pre-existing TEI element which we pressganged into 
service here. It does seem a bit problematic as to name, and its overlap 
with other ways of characterizing a place.

8. Ethnica sounds interesting. But I think it's a kind of placeName 
still, not a new kind of name, even though its location may be hard to 
pin down. After all whether we think of  Bristol as "the place with a 
bridge" or "the place where the Bristolians hang out", it's still a place.

9. Absolutely no intention or need for TEI to re-invent detailed 
geographic metadata already done better by GML and similar. We could do 
with some real examples though, as you note.

10. SpatialML is an interesting one which I have glanced at but not 
studied in detail: it comes from the very different world of "named 
entity recognition" .  Certainly we ought to review it and the others 
you mention, before rushing ahead, if only as a fruitful source of examples.

best wishes

Lou