TEI Personography WG: Place Meeting at CCH 29 May 2007
Contents
- Nesting of places
- State/Trait
- Locale
- Latitude and Longitude
- Sources, assertions, responsibilities, uncertainty
- Dates and Periods
- Organizations (cf TRAC 159)
- Need for listPlace as well as place (Trac 307)
As agreed at the Berlin Council meeting, Arianna Ciula convened a meeting of a small group to progress the work on encoding of geographical information initiated by the Personography meeting held in January in Vilnius. This meeting was kindly hosted by CCH at Kings College London on 29 May 2007 from 1000 to 1700. The meeting was chaired by Matthew Driscoll, and attended by Gabriel Bodard, Lou Burnard, Arianna Ciula, James Cummings, Stuart Dunn, Leif Isaksen, and Sebastian Rahtz. Tom Elliott joined the second half of the meeting by skype.
Matthew reported that he had presented the work done so far on names and persons at a recent ESF Exploratory Workshop on Prosopography organized by Harold Short and Donald Broadie in Uppsala, and that his presentation had been very well received; he commented that the notion of treating persons and places in the same way had been welcomed.
It was agreed to organize the day around revising the current draft making reference to issues raised so far and tabulated by AC in Reference for meeting on place names, a document circulated immediately prior to the meeting.
Nesting of places
We agreed that containment of one <place> within another <place> was a usefully simple means of indicating the "part of" relation between one place of another, although more complex inter-place relationships would need to be addressed. Examples of non-nesting relations mentioned included the Ile de la Reunion which is both one of the Mascareigne Islands and part of France and the island of Cyprus which is part of both Greece and Turkey.
State/Trait
Noting that the current set of examples persistently confused *State and *Trait elements, we questioned the need for both, and tried to come up with a firm distinction.
Lou described an alternative feature structure based solution, which was politely listened to but unpersuasive.
The basic distinction is that a ‘state’ has no meaning unless it is dated. For example: "age" or "population" are meaningless unless dated; whereas eye-colour and geographical location are not. The former are "state"s, while the latter are "traits"s. Traits can change over time, but typically do not. States change over time of necessity.
This seemed a good way of handling the census-type data mentioned by DOD. We considered, but rejected, using a special *Grp (or generic <grp> ) element for this purpose.
Note however that different attributes in the above example behave differently: values for the @type attribute are to be understood as cumulatively inherited; those for @date must be mutually consistent; those for @resp and @cert however always override their parent, if any is specified. This kind of "cumulative inheritance" is used elsewhere in the TEI, e.g. on <category> , <linkGrp> etc.
We veered off into a discussion about whether or how groups of assertions might be interpreted as implying causality by wrapping them in an <assertion> element as had previously been suggested, but again decided against doing so.
Locale
We agreed that this element was confusingly named, and should be removed from the part of the Guidelines under discussion (but not from its original usage in documenting transcription settings). An element <placeTrait> would do the same job for places.
Latitude and Longitude
We agreed that <location> might be supplied in several ways, using element content to specify it as a set of <measure> s of some kind, or as a named path or address, as in existing examples. In the simplest case however, where <location> contains just text, then its value is to be interpreted according to the value of the @scheme attribute. Values for this attribute defined so far (in a closed list) are "latlong" which indicates that the value contains a pair of numbers to be interpreted as latitude followed by longitude, and an optional flag for the co-ordinate system datum, defaulting to WGS84, and "local" which means that a private string is used. Locations defined in terms of e.g. Ptolomaic co-ordinate system might be defined in this way, or by using <measure> with appropriate values.
(Subsequent discussion confirmed that WGS84 was probably the most appropriate datum, since it was that used by most kinds of GPS applications TEI users were likely to encounter e.g. Google maps)
Sources, assertions, responsibilities, uncertainty
Agreed to make att.naming inherit @resp and @cert from att.editLike.
Sources for assertions about locations etc. should be given as a <bibl> within the assertion.
Dates and Periods
We proposed @when as a suitable replacement for both @date and @value attributes inherited from the dating classes; we also wondered if work on tidying up the dating attributes was finished yet, and whether the two classes att.dateTime and att.datable could be merged.
We also identified a need for another dating attribute, to identify a named ‘period’ e.g. "hellenistic", "troy2", "troy4". Periods might have many different and varyingly precise datings; it would be convenient to be able to define a name for a period once for all, and then reference it by a pointer. The target of this @whenRef pointer (maybe @period would be a better name) should be some element containing a period definition, possibly including date elements, possibly formalized as a <taxonomy> or a <timeline> element. Or it might simply be a URI for the Wikipedia entry for "Hellenistic".
Organizations (cf TRAC 159)
We discussed how to represent groups of people with some ontological standing independent of their status as individuals, for example ‘ethnica’ such as "the Scythians". We felt that these were similar to businesses, organizations etc. and tried to find a suitable name for the corresponding element ( <org> , <collective> , <gang> ?) before settling on <com> , short for community, company, commune... (But after the meeting a consensus emerged that perhaps <org> would be a name less open to misunderstanding).
The existing <orgXxxx> elements need major surgery. Probably most of them, except for <orgName> , should be redefined as <orgTrait> or <orgState> of some kind.
This led to discussion about reducing the number of element names: could we replace xxxState by <state> or <pState> , xxxTrait by <trait> or <pTrait> and xxxEvent by <event> or <pEvent> ? This seemed much better than having to invent another three elements for each new value of xxx. We didn't like the pState etc. option much, and not only because we had not thought of a viable name for <org> beginning with P. The alternative would mean that the existing <state> and <event> elements would have to be renamed to something more specific. Existing classes such as model.persStateLike and model.placeStateLike would remain, but the generic <state> would be a member of both; likewise for <trait> . This issue was further discussed after the meeting, with a clear consensus in favour of renaming the existing <state> and <event> elements rather than trying to find alternative names for the proposed new generic ones.
Need for listPlace as well as place (Trac 307)
We agreed that in addition to the hierarchic structures discussed so far, it might be useful to support sublists of places within <place> s, for example to list the villages within a country distinct from a list of the rivers. Making <listPlace> a member of the model.placeLike class would be an easy way of doing this. <placeList> s could also then nest.