13 Names, Dates, People, and Places

Table of contents

This chapter describes a module which may be used for the encoding of names and other phrases descriptive of persons, places, or organizations, in a manner more detailed than that possible using the elements already provided for these purposes in the Core module. In section 3.5 Names, Numbers, Dates, Abbreviations, and Addresses it was noted that the elements provided in the core module allow an encoder to specify that a given text segment is a proper noun, or a referring string, and to specify the kind of object named or referred to only by supplying a value for the type attribute. The elements provided by the present module allow the encoder to supply a detailed sub-structure for such referring strings, and to distinguish explicitly between names of persons, places, and organizations.

This module also provides elements for the representation of information about the person, place, or organization to which a given name is understood to refer and to represent the name itself, independently of its application. In simple terms, where the core module allows one simply to represent that a given piece of text is a name, this module allows one further to represent a personal name, to represent the person being named, and to represent the canonical name being used. A similar range is provided for names of places and organizations. The main intended applications for this module are in biographical, historical, or geographical data systems such as gazetteers and biographical databases, where these are to be integrated with encoded texts.

The chapter begins by discussing attributes common to many of the elements discussed in the remaining parts of the chapter (13.1 Attribute Classes Defined by this Module) before discussing specifically the elements provided for the encoding of component parts of personal names (section 13.2.1 Personal Names), place names (section 13.2.3 Place Names) and organizational names (section 13.2.2 Organizational Names). Elements for encoding personal and organizational data are discussed in section 13.3 Biographical and Prosopographical Data. Elements for the encoding of geographical data are discussed in section 13.3.4 Places. Finally, elements for encoding onomastic data are discussed in 13.3.5 Names and Nyms, and the detailed encoding of dates and times is described in section 13.3.6 Dates and Times.

13.1 Attribute Classes Defined by this Module

Most of the elements made available by this chapter share some important characteristics which are expressed by their membership in specific attribute classes. Members of the class att.naming have specialized attributes which support linkage of a naming element with the entity (person, place, organization) being named; members of the class att.datable have specialized attributes which support a number of ways of normalizing the date or time of the data encoded by the element concerned.

13.1.1 Linking Names and their Referents

The class att.naming is a subclass of the class att.canonical, from which it inherits the following attributes:
  • att.canonical provides attributes which can be used to associate a representation such as a name or title with canonical information about the object being named or referenced.
    keyprovides an externally-defined means of identifying the entity (or entities) being named, using a coded value of some kind.
    ref (reference) provides an explicit means of locating a full definition for the entity being named by means of one or more URIs.
. As discussed elsewhere, these attributes provide two different ways of associating any sort of name with its referent. In addition, the att.naming class provides an additional attribute, which allows the name itself to be associated with a base or canonical form:
  • att.naming provides attributes common to elements which refer to named persons, places, organizations etc.
    nymRef(reference to the canonical name) provides a means of locating the canonical form (nym) of the names associated with the object named by the element bearing it.
The encoder may use these attributes in combination as appropriate. The ref attribute should be used wherever it is possible to supply a direct link such as a URI to indicate the location of canonical information about the referent. For example:
That silly man
<name ref="#DPB1" type="person">David Paul Brown</name> has suffered ...
This encoding requires that there exist somewhere a person element with the identifier DPB1, which will contain canonical information about this particular person, marked up using the elements discussed in 13.3 Biographical and Prosopographical Data below. The same element might alternatively be provided by some other document, of course, which the same attribute could refer to by means of a URI, as explained in 16.2 Pointing Mechanisms:
That silly man
<name
  ref="http://www.example.com/personography.xml#DPB1"
  type="person">David Paul Brown</name> has suffered
...
More than one URI may be supplied if the name refers to more than one person. For example, assuming the existence of another person element for Mrs Brown, with identifier EBB1, a reference to ‘the Browns’ might be encoded
That wretched pair
<name ref="#DPB1 #EBB1" type="person">the Browns</name> came to dine
...
The key attribute is provided for cases where no such direct link is required: for example because resolution of the reference is carried out by some local convention, or because the encoder judges that no such resolution is necessary. As an example of the first case, a project might maintain its own local database system containing canonical information about persons and places, each entry in which is accessed by means of some system-specific identifier constructed in a project-specific way from the value supplied for the key attribute.39 As an example of the second case, consider the use of well-established codifications such as country or airport codes, which it is probably unnecessary for an encoder to expand further:
I never fly from <name key="LHR" type="place">Heathrow Airport</name>
to
<name key="FR" type="place">France</name>

The nymRef attribute has a more specialised use, where it is the name itself which is of interest rather than the person, place, or organization being named. See section 13.3.5 Names and Nyms for further discussion.

Some members of the att.naming class are also members of the att.editLike class, from which they inherit the following attributes:
  • att.editLike provides attributes describing the nature of a encoded scholarly intervention or interpretation of any kind.
    resp(responsible party) indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber.
    cert(certainty) signifies the degree of certainty associated with the intervention or interpretation.
This enables an encoder to record the agency responsible for a given assertion (for example, the name) and the confidence placed in that assertion by the encoder. Examples are given below.

13.1.2 Dating Attributes

Members of the att.datable class share the following attributes:
  • att.datable.w3c provides attributes for normalization of elements that contain datable events using the W3C datatypes.
    periodsupplies a pointer to some location defining a named period of time within which the datable item is understood to have occurred.
    whensupplies the value of the date or time in a standard form, e.g. yyyy-mm-dd.
    notBeforespecifies the earliest possible date for the event in standard form, e.g. yyyy-mm-dd.
    notAfterspecifies the latest possible date for the event in standard form, e.g. yyyy-mm-dd.
    fromindicates the starting point of the period in standard form, e.g. yyyy-mm-dd.
    toindicates the ending point of the period in standard form, e.g. yyyy-mm-dd.
The period attribute provides a convenient way of associating an event or date with a named period. Its value is a pointer which should indicate some other element where the period concerned is more precisely defined. A convenient location for such definitions is the taxonomy element in the classDecl (classification declaration) in the encodingDesc of a TEI Header. A taxonomy may contain simply a bibliographic reference to an external definition for it. More usefully, it may also contain a series of category elements, each with an identifier and a description. The identifier can then be used as the target for a period attribute. For example, a taxonomy of named periods might be defined as follows:
<taxonomy xml:id="greekperiods">
 <category xml:id="tyranny">
  <catDesc>Before 510 BC</catDesc>
 </category>
 <category xml:id="classical">
  <catDesc>Between 510 and 323 BC</catDesc>
 </category>
 <category xml:id="hellenistic">
  <catDesc>
   <ref
     target="http://www.wikipedia.com/wiki/Hellenistic">Hellenistic</ref>. Commonly treated as <date notBefore="-0323" notAfter="-0031">from the death of Alexander to the Roman conquest.</date>
  </catDesc>
 </category>
 <category xml:id="roman">
  <catDesc>
   <ref
     target="http://www.wikipedia.com/wiki/Roman_Empire">Roman</ref>
  </catDesc>
 </category>
 <category xml:id="christian">
  <catDesc> The Christian period technically starts at the
     birth of Jesus, but in
     practice is considered to date from the conversion of Constantine
     in <date when="0312">312 AD</date>. </catDesc>
 </category>
</taxonomy>
With these definitions in place, any datable event may be associated with a specific period:
<placeName period="#christian">Stauropolis</placeName>
The other dating attributes provided by this class support a wide range of methods of specifying temporal information in a normalized form. Some simple examples follow:
<birth when="1857-03-15">15 March 1857.</birth>
<birth notBefore="1857-03-01" notAfter="1857-04-30">Some time
in March or April of 1857.</birth>
<residence from="1857-03-01" to="1857-04-30">In March and April of 1857.</residence>
<residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to
some time in April of 1857.</residence>

Normalisation of date and time values permits the efficient processing of data (for example, to determine whether one event precedes or follows another). These examples all use the W3C standard format for representation of dates and times. Further examples, and discussion of some alternative approaches to normalization are given in section 13.3.6.3 More Expressive Normalizations below.

13.2 Names

13.2.1 Personal Names

The core rs and name elements can distinguish names in a text but are insufficiently powerful to mark their internal components or structure. To conduct nominal record linkage or even to create an alphabetically sorted list of personal names, it is important to distinguish between a family name, a forename and an honorary title. Similarly, when confronted with a referencing string such as ‘John, by the grace of God, king of England, lord of Ireland, duke of Normandy and Aquitaine, and count of Anjou’, the analyst will often wish to distinguish amongst the various constituent elements present, since they provide additional information about the status, occupation, or residence of the person to whom the name belongs. The following elements are provided for these and related purposes:
  • persName (personal name) contains a proper noun or proper-noun phrase referring to a person, possibly including any or all of the person's forenames, surnames, honorifics, added names, etc.
  • surname contains a family (inherited) name, as opposed to a given, baptismal, or nick name.
  • forename contains a forename, given or baptismal name.
  • roleName contains a name component which indicates that the referent has a particular role or position in society, such as an official title or rank.
  • addName (additional name) contains an additional name component, such as a nickname, epithet, or alias, or any other descriptive phrase used within a personal name.
  • nameLink contains a connecting phrase or link used within a name but not regarded as part of it, such as van der or of.
  • genName (generational name component) contains a name component used to distinguish otherwise similar names on the basis of the relative ages or generations of the persons named.
In addition to the att.naming attributes mentioned above, all of the above elements are members of the class att.personal, and thus share the following attributes:
  • att.personal (attributes for components of personal names) common attributes for those elements which form part of a personal name.
    fullindicates whether the name component is given in full, as an abbreviation or simply as an initial.
    sortspecifies the sort order of the name component in relation to others within the personal name.
The persName element may be used in preference to the general name element irrespective of whether or not the components of the personal name are also to be marked. The element persName is synonymous with the element <name type="person">, except that its type attribute allows for further subcategorization of the personal name itself, for example as a married, maiden, pen, pseudo, or religious name. Consequently the following examples are equivalent:
That silly man
<rs key="DPB1" type="person">David Paul Brown</rs> has suffered the
furniture of his office to be seized
the third time for rent.
That silly man
<rs key="DPB1" type="person">
 <name>David Paul Brown</name>
</rs> has suffered ...
That silly man
<name key="DPB1" type="person">David Paul Brown</name> has suffered ...
That silly man
<persName key="DPB1">David Paul Brown</persName> has suffered ...

The persName element is more powerful than the rs and name elements because distinctive name components occurring within it can be marked as such.

Many cultures distinguish between a family or inherited surname and additional personal names, often known as given names. These should be tagged using the surname and forename elements respectively and may occur in any order:
<persName>
 <surname>Roosevelt</surname>,
<forename>Franklin</forename>
 <forename>Delano</forename>
</persName>
<persName>
 <forename>Franklin</forename>
 <forename>Delano</forename>
 <surname>Roosevelt</surname>
</persName>
The type attribute may be used with both forename and surname elements to provide further culture- or project- specific detail about the name component, for example:
<persName>
 <forename type="first">Franklin</forename>
 <forename type="middle">Delano</forename>
 <surname>Roosevelt</surname>
</persName>
<persName>
 <forename type="given">Margaret</forename>
 <forename type="unused">Hilda</forename>
 <surname type="maiden">Roberts</surname>
 <surname type="married">Thatcher</surname>
</persName>
<persName type="religious">Muhammad Ali</persName>
<persName>
 <forename>Norman</forename>
 <surname type="complex">St John Stevas</surname>
</persName>
Values for the type attribute are not constrained, and may be chosen as appropriate to the encoding needs of the project. They may be used to distinguish different kinds of forename or surname, as well as to indicate the function a name component fills within the whole. In this example, we indicate that a surname is toponymic, and also point to the specific place name from which it is derived:
<persName>
 <forename>Johan</forename>
 <surname type="toponymic" ref="#dystvold">Dystvold</surname>
</persName>
<!-- ... -->
<placeName xml:id="dystvold">Dystvold</placeName>
The value complex was suggested above for the not uncommon case where the whole of a surname is composed of several other surname elements. These nested surnames may be individually tagged as well, together with appropriate type values:
<persName>
 <forename>Kara</forename>
 <surname type="complex">
  <surname type="paternal">Hattersley</surname>-
 <surname type="maternal">Smith</surname>
 </surname>
</persName>
The full attribute may be used to indicate whether a name is an abbreviation, initials, or given in full:
<persName>
 <forename full="abb">Maggie</forename>
 <surname>Thatcher</surname>
</persName>
These elements may be applied as the encoder considers appropriate, including cases where phrases or expressions are used to stand for surnames or forenames, as in the following:
<s>
 <persName>
  <forename>Peter</forename>
  <surname>son of Herbert</surname>
 </persName> gives the king 40 m. for
having custody of the land and heir of <persName>
  <forename>John</forename>
  <surname>son of Hugh</surname>
 </persName>...
</s>
Similarly, patronymics may be treated as forenames, thus:
... but it remained for
<persName>
 <forename>Snorri</forename>
 <forename>Sturluson</forename>
</persName>
to combine the two traditions in cyclic form.
When a patronymic is used as a surname, however (e.g. by an individual who otherwise would have no surname, but lives in a culture which requires surnames), it may be tagged as such:
Even <persName>
 <forename>Finnur</forename>
 <surname>Jonsson</surname>
</persName>
acknowledged the artificiality of the procedure...
Alternatively, it may be felt more appropriate to mark a patronymic as a distinct kind of name, neither a forename nor a surname, using the addName element:
<persName>
 <forename>Egill</forename>
 <addName type="patronym">Skallagrmsson</addName>
</persName>
In the following example, the type attribute is used to distinguish a patronymic from other forenames:
<persName key="pn9">
 <forename sort="2">Sergei</forename>
 <forename sort="3" type="patronym">Mikhailovic</forename>
 <surname sort="1">Uspensky</surname>
</persName>

This example also demonstrates the use of the sort attribute common to all members of the model.persNamePart class; its effect is to state the sequence in which forename and surname elements should be combined when constructing a sort key for the name.

Some names include generational or dynastic information, such as a number, or phrases such as ‘Junior’, or ‘the Elder’; these qualifications may also be used to distinguish similarly named but unrelated people. In either case, the genName element may be used to distinguish such labels from other parts of the name, as in the following examples:
<persName key="HEMA1">
 <surname>Marques</surname>
 <genName>Junior</genName>,
<forename>Henrique</forename>
</persName>
<persName>
 <forename>Charles</forename>
 <genName>II</genName>
</persName>
<persName>
 <forename>Rudolf</forename>
 <genName>II</genName>
 <surname type="dynasty">Hapsburg</surname>
</persName>
<persName>
 <surname>Smith</surname>
 <genName>Minor</genName>
</persName>
It is also often convenient to distinguish phrases (historically similar to the generational labels mentioned above) used to link parts of a name together, such as ‘von’, ‘of’, ‘de’ etc. It is often a matter of arbitrary choice whether such components are regarded as part of the surname or not; the nameLink element is provided as a means of making clear what the correct usage should be in a given case, as in the following examples:
<persName key="DUDO1">
 <roleName type="honorific" full="abb">Mme</roleName>
 <nameLink>de la</nameLink>
 <surname>Rochefoucault</surname>
</persName>
<persName>
 <forename>Walter</forename>
 <surname>de la Mare</surname>
</persName>
Finally, the addName and roleName elements are used to mark all name components other than those already listed. The distinction between them is that a roleName encloses an associated name component such as an aristocratic or official title which exists in some sense independently of its bearer. The distinction is not always a clear one. As elsewhere, the type attribute may be used with either element to supply culture- or application- specific distinctions. Some typical values for this attribute for names in the Western European tradition follow:
nobility
An inherited or life-time title of nobility such as Lord, Viscount, Baron, etc.
honorific
An academic or other honorific prefixed to a name e.g. Doctor, Professor, Mrs., etc.
office
Membership of some elected or appointed organization such as President, Governor, etc.
military
Military rank such as Colonel.
epithet
A traditional descriptive phrase or nick-name such as The Hammer, The Great, etc.
Note, however, that the role a person has in a given context (such as witness, defendant, etc. in a legal document) should not be encoded using the roleName element, since this is intended to describe the role of this part of the name, not the role of the person bearing the name. Information about roles, occupations, etc. of a person are encoded within the person element discussed below in 13.3 Biographical and Prosopographical Data.
Here are some further examples of the usage of these elements:
<persName key="PGK1">
 <roleName type="nobility">Princess</roleName>
 <forename>Grace</forename>
</persName>
<persName key="GRMO1" type="pseudo">
 <addName type="honorific">Grandma</addName>
 <surname>Moses</surname>
</persName>
<persName key="SLWICL1">
 <roleName type="office">President</roleName>
 <forename>Bill</forename>
 <surname>Clinton</surname>
</persName>
<persName key="MOGA1">
 <roleName type="military">Colonel</roleName>
 <surname>Gaddafi</surname>
</persName>
<persName key="FRTG1">
 <forename>Frederick</forename>
 <addName type="epithet">the Great</addName>
</persName>
A name may have any combination of the above elements:
<persName key="EGBR1">
 <roleName type="office">Governor</roleName>
 <forename sort="2">Edmund</forename>
 <forename full="init" sort="3">G.</forename>
 <addName type="nick">Jerry</addName>
 <addName type="epithet">Moonbeam</addName>
 <surname sort="1">Brown</surname>
 <genName full="abb">Jr</genName>.

</persName>

Although highly flexible, these mechanisms for marking personal name components will not cater for every personal name and processing need. Where the internal structure of personal names is highly complex or where name components are particularly ambiguous, feature structures are recommended as the most appropriate mechanism to mark and analyze them, as further discussed in chapter 18 Feature Structures.

13.2.2 Organizational Names

In these Guidelines, we use the term ‘organization’ for any named collection of people regarded as a single unit. Typical examples include businesses or institutions such as ‘Harvard College’ or ‘the BBC’, but also racial or ethnic groupings or political factions where these are regarded as forming a single agency such as ‘the Scythians’ or ‘the Militant Tendency’. Giving a loosely-defined group of individuals a name often serves a particular political or social agenda and an analysis of the way such phrases are constructed and used may therefore be of considerable importance to the social historian, even where the objective existence of an ‘organization’ in this sense is harder to demonstrate than that of (say) a named person. In the case of business or other formally constituted institutions, the component parts of an organizational name may help to characterize the organization in terms of its perceived geographical location, ownership, likely number of employees, management structure, etc.

Like names of persons or places, organizational names can be marked up as referring strings or as proper names with the rs or name elements respectively. The element orgName is provided for use where it is desired to distinguish organizational names more explicitly.
  • orgName (organization name) contains an organizational name.
This element is a member of the same attribute classes as persName, as discussed above in 13.1.1 Linking Names and their Referents.
The orgName element may be used to mark up any form of organizational name:
About a year back, a question of considerable
interest was agitated in the
<orgName type="voluntary" key="PAS1">Pennsyla. Abolition Society</orgName>
This encoding is equivalent to, but more specific than, either of the following representations:
About a year back, a question of considerable
interest was agitated in the <rs key="PAS1" type="org">
 <name>Pennsyla. Abolition Society</name>
</rs>.
About a year back, a question of considerable
interest was agitated in the
<name key="PAS1" type="org">Pennsyla. Abolition
Society</name>.
As shown above, like the rs and name elements, the orgName element has a key attribute with which an external identifier such as a database key can be assigned to the organization name, and also a ref attribute which can be used to point directly to an org element containing information about the organization itself (see further 13.3.3 Organizational Data). Its type attribute should be used to characterize the name (rather than the organization), for example as an acronym:
Mr Frost will be able to earn an extra fee from
<orgName type="acronym">BSkyB</orgName>
rather than the
<orgName type="acronym">BBC</orgName>
as a phrase:
The feeling in <country>Canada</country> is one of
strong aversion to the <orgName type="phrase">United
States Government</orgName>, and of
predilection for self-government under
the
<orgName type="phrase">English Crown</orgName>
<orgName>The Justified Ancients of Mu Mu</orgName>
or as a composite of other kinds of name:
<orgName type="partnerNames">
 <surname>Ernst</surname> &amp; <surname>Young</surname>
</orgName>
The components of an organization's name are not always personal names. They may also include place names:
A spokesman from
<orgName type="regional">
 <orgName>IBM</orgName>
 <country>UK</country>
</orgName> said ...
or role names:
THE TICKET which you will receive herewith has been formed by
the <orgName>Democratic Whig <name type="role">party</name>
</orgName> after the most careful deliberation,
with a reference to all the great objects of NATIONAL, STATE,
COUNTY and CITY concern, and with a single eye to the <hi>Welfare and Best Interests of the Community</hi>.
As indicated above, organizational names may also be specified hierarchically particularly where the named organization is itself a department or a branch of a larger organizational entity. ‘The Department of Modern History, Glasgow University’ is an example:
<orgName>
 <orgName>Department of Modern History</orgName>
 <orgName>
  <name type="city">Glasgow</name>
  <name type="role">University</name>
 </orgName>
</orgName>

13.2.3 Place Names

Like other proper nouns or noun phrases used as names, place names can simply be marked up with the rs element, or with the name element. For cartographers and historical geographers, however, the component parts of a place name provide important information about the relation between the name and some spot in space and time. They also provide important evidence in historical linguistics.

These Guidelines distinguish three ways of referring to places. A place name (represented using the placeName element) may consist of one or more names for hierarchically-organized geo-political or administrative units (see section 13.2.3.1 Geo-political Place Names). A place named simply in terms of geographical features such as mountains or rivers is represented using the geogName element (see section 13.2.3.2 Geographic Names). Finally, an expression consisting of phrases expressing spatial or other kinds of relationship between other kinds of named place may itself be regarded as a way of referring to a place, and hence as a kind of named place (see section 13.2.3.3 Relative Place Names).
  • placeName contains an absolute or relative place name.
  • geogName (geographical name) a name associated with some geographical feature such as Windrush Valley or Mount Sinai.

As members of the att.naming class, all of these elements bear the attributes key, ref, and nymRef mentioned above. These attributes are primarily useful as a means of linking a place name with information about a specific place. Recommendations for the encoding of information about a place, as distinct from its name, are provided in 13.3.4 Places below.

Like the persName element discussed in section 13.2.1 Personal Names, the placeName element may be regarded simply as an abbreviation for the elements <name type="place"> or <rs type="place">. The following encodings are thus equivalent:40
After
spending some time in our <rs key="NY1" type="place">modern <name key="BA1" type="place">Babylon</name>
</rs>, <name key="NY1" type="place">New York</name>, I have proceeded to the <rs key="PH1" type="place">City of Brotherly Love</rs>.
After spending some
time in our <placeName key="NY1">modern <placeName key="BA1">Babylon</placeName>
</placeName>, <placeName key="NY1">New
York</placeName>, I have proceeded to the <placeName key="PH1">City of
Brotherly Love</placeName>.
13.2.3.1 Geo-political Place Names
A place name may contain text with no indication of its internal structure:
<placeName>Rochester,
NY</placeName>
More usually however, a place name of this kind will be further analysed in terms of its constitutive geo-political or administrative units. These may be arranged in ascending sequence according to their size or administrative importance, for example: ‘Rochester, New York’, or as a single such unit, for example ‘Belgium’. These Guidelines provide a hierarchy of generic element names, each of which may be more exactly specified by means of a type attribute:
  • district contains the name of any kind of subdivision of a settlement, such as a parish, ward, or other administrative or geographic unit.
  • settlement contains the name of a settlement such as a city, town, or village identified as a single geo-political or administrative unit.
  • region contains the name of an administrative unit such as a state, province, or county, larger than a settlement, but smaller than a country.
  • country contains the name of a geo-political unit, such as a nation, country, colony, or commonwealth, larger than or administratively superior to a region and smaller than a bloc.
  • bloc contains the name of a geo-political unit consisting of two or more nation states or countries.
These elements are all members of the model.placeNamePart class, members of which may be used anywhere that text is permitted, including within each other as in the following examples:
<placeName>
 <settlement type="city">Rochester</settlement>,
<region type="state">New York</region>
</placeName>
<placeName key="LSEA1">
 <country type="nation">Laos</country>,
<bloc type="sub-continent">Southeast Asia</bloc>
</placeName>
<placeName>
 <district type="arondissement">6ème</district>
 <settlement type="city">Paris, </settlement>
 <country>France</country>
</placeName>
13.2.3.2 Geographic Names
Places may also be named in terms of geographic features such as mountains, lakes, or rivers, independently of geo-political units. The geogName is provided to mark up such names, as an alternative to the placeName element discussed above. For example:
<geogName key="MIRI1" type="river">Mississippi River</geogName>
In addition to the usual phrase level elements, the geogName element may contain the following specialized element:
  • geogFeat (geographical feature name) contains a common noun identifying some geographical feature contained within a geographic name, such as valley, mount, etc.
Where the geogFeat element is used to characterize the kind of geographic feature being named, the name element will generally also be used to mark the associated proper noun or noun phrase:
<geogName key="MIRI1" type="river">
 <name>Mississippi</name>
 <geogFeat>River</geogFeat>
</geogName>
A more complex example, showing a variety of practices, follows:
The isolated ridge
separates two great corridors which run from <name key="GLCO1" type="place">Glencoe</name> into
<geogName key="GLET1" type="glen">
 <geogFeat>Glen</geogFeat>
 <name>Etive</name>
</geogName>, the
<geogName key="LAGA1" type="hill">
 <geogFeat xml:lang="gd">Lairig</geogFeat>
 <name>Gartain</name>
</geogName> and the

<geogName key="LAEI1" type="hill">
 <geogFeat xml:lang="gd">Lairig</geogFeat>
 <name>Eilde</name>
</geogName>

The Gaelic word lairig may be glossed as sloping hill face. The most efficient way of including this information in the above encoding would be to create a separate nym element for this component of the name and then point to it using the nymRef attribute, as further discussed in 13.3.5 Names and Nyms.

13.2.3.3 Relative Place Names

All the place name specifications so far discussed are absolute, in the sense that they define only one place. A place may however be specified in terms of its relationship to another place, for example ‘10 miles northeast of Paris’ or ‘near the top of Mount Sinai’. These relative place names will contain a place name which acts as a referent (e.g. ‘Paris’ and ‘Mount Sinai’). They will also contain a word or phrase indicating the position of the place being named in relation to the referent (e.g. ‘the top of’, ‘north of’). A distance, possibly only vaguely specified, between the referent place and the place being indicated may also be present (e.g. ‘10 miles’, ‘near’).

Relative place names may be encoded using the following elements in combination with either a placeName or a geogName element.
  • offset that part of a relative temporal or spatial expression which indicates the direction of the offset between the two place names, dates, or times involved in the expression.
  • measure contains a word or phrase referring to some quantity of an object or commodity, usually comprising a number, a unit, and a commodity name.
Some examples of relative place names are:
<placeName key="NRPA1">
 <offset>near the top of</offset>
 <geogName>
  <geogFeat>Mount</geogFeat>
  <name>Sinai</name>
 </geogName>
</placeName>
<placeName>
 <measure>20 km</measure>
 <offset>north of</offset>
 <settlement type="city">Paris</settlement>
</placeName>
If desired, the distance specified may be normalized using the unit and quantity attributes of measure:
<placeName key="Duncan">
 <measure unit="km" quantity="17.7">11 miles</measure>
 <offset>Northwest of</offset>
 <settlement type="city">Providence</settlement>, <region type="state">RI</region>
</placeName>

The internal structure of place names is like that of personal names — complex and subject to an enormous amount of variation across time and different cultures. The recommendations in this section should however be adequate for a majority of users and applications; they may be extended using the mechanisms described in chapter 23.2 Personalization and Customization to add new elements to the existing classes. When the focus of interest is on the name components themselves, as in place name studies for example, the elements discussed in 13.3.5 Names and Nyms may also be of use. Alternatively, the meaning structure itself may be represented using feature structures (18 Feature Structures).

13.3 Biographical and Prosopographical Data

This module defines a number of special purpose elements which can be used to markup biographical, historical, and prosopographical data. We envisage three basic types of users and uses for these elements. The first is the person interested in creating or converting an existing set of biographical records, for example of the type found in a Dictionary of National Biography. The second is the person hoping to create or convert a database-like collection of information about a group of people, possibly but not necessarily the people referenced in a marked-up collection of documents or a text-corpus. The third type would be those interested in the creation or conversion of biographical or CV-like structured texts for use in such applications as Human Resource management.

To cater for this diversity, these Guidelines propose a flexible approach, in which encoders may choose for themselves the degree of prescription appropriate to their needs. If one were interested, for example, in converting existing DNB-type records, and wanted to preserve the text as is, the person element (see 13.3.2 The Person Element) could simply contain the text of an article, placed within p elements, possibly using elements such as name or date to mark up features of that text. For a more structured entry, however, one would extract the data and place information contained by the text, and encode it directly using the more specific elements described in this section.

13.3.1 Basic Principles

Information about people, places, and organizations, of whatever type, essentially comprises a series of statements or assertions relating to:
  • characteristics or traits which do not, by and large, change over time
  • characteristics or states which hold true only at a specific time
  • events or incidents which may lead to a change of state or, less frequently, trait.

‘Characteristics’ or ‘traits’ 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. The distinction is not entirely straightforward, however: while sex is fairly obviously a physical trait, gender should rather be regarded as culturally determined, and the division of mankind into different ‘races’, proposed by early (white European) anthropologists on the basis of physical characteristics such as skin colour, hair type and skull measurements, is by many modern cultural anthropologists now considered to be more a social or mental construct than an objective biological fact. Furthermore, while some characteristics will obviously change over time, hair colour for example, none, in principle — not even sex — is immutable.

‘States’ include, for example, marital status, place of residence and position or occupation. Such states have a definite duration, that is, they have a beginning and an end and are typically a consequence of the individual's own action or that of others.

By ‘changes in state’ are meant the events in a person's life such as birth, marriage, or appointment to office; such events will normally be associated with a specific date or a fairly narrow date-range. Changes in states can also cause or be caused by changes in characteristics. Any statement or assertion on any of these aspects of a person's life will be based on some source, possibly multiple sources, possibly contradictory. Taking all this into account it follows that each such statement or assertion needs to be able to be documented, put into a time frame and be relatable to other statements or assertions of the same or any of the other types.

The elements defined by the module described in this chapter may, for the most part, all be regarded as specialisations of one or other of the above three classes. Generic elements for state, trait, and event are also defined:
  • event contains data relating to any kind of significant event associated with a person, place, or organization.
    whereindicates the location of an event by pointing to a place element
  • state contains a description of some status or quality attributed to a person, place, or organization at some specific time.
  • trait contains a description of some culturally-determined and in principle unchanging characteristic attributed to a person or place .

13.3.2 The Person Element

Information about a person, as distinct from references to a person, for example by name, is grouped together within a person element. Information about a group of people regarded as a single entity (for example ‘the audience’ of a performance) may be encoded using the personGrp element. Note however that information about a group of people with a distinct identity (for example a named theatrical troupe) should be recorded using the org element described in section 13.3.3 Organizational Data below.

These elements may appear only within a listPerson element, which groups such descriptions together, and optionally also describes relationships amongst the people listed.
  • person provides information about an identifiable individual, for example a participant in a language interaction, or a person referred to in a historical source.
  • personGrp (personal group) describes a group of individuals treated as a single person for analytic purposes.
  • listPerson (list of persons) contains a list of descriptions, each of which provides information about an identifiable person or a group of people, for example the participants in a language interaction, or the people referred to in a historical source.
  • relationGrp (relation group) provides information about relationships identified amongst people, places, and organizations, either informally as prose or as formally expressed relation links.

One or more listPerson elements may be supplied within the particDesc (participant description) element in the profileDesc element of a TEI Header (see 2.4 The Profile Description). Like other forms of list, however, the listPerson can also appear within the body of a text when the module defined by this chapter is included in a schema.

The type attribute may be used to distinguish lists of people of different kinds where this is considered convenient:
<profileDesc>
 <particDesc>
  <listPerson type="historical">
   <person xml:id="ART1">
    <persName>Arthur</persName>
   </person>
   <person xml:id="BERT1">
    <persName>Bertrand</persName>
   </person>
<!-- ... -->
  </listPerson>
  <listPerson type="mythological">
   <person xml:id="ART2">
    <persName>Arthur</persName>
   </person>
   <person xml:id="BERT2">
    <persName>Bertrand</persName>
   </person>
<!-- ... -->
  </listPerson>
 </particDesc>
</profileDesc>
The person element provides several useful attributes. First, as a member of att.editLike, the person element may carry attributes useful for indicating details about the scholarly interpretations made about the information recorded for the person in question:
  • att.editLike provides attributes describing the nature of a encoded scholarly intervention or interpretation of any kind.
    cert(certainty) signifies the degree of certainty associated with the intervention or interpretation.
    resp(responsible party) indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber.
    evidenceindicates the nature of the evidence supporting the reliability or accuracy of the intervention or interpretation.
    sourcecontains a list of one or more pointers indicating the sources which support the given reading.
Second, attributes specific to person (and personGrp) allow specification of some particular information about the person (or group).
  • person provides information about an identifiable individual, for example a participant in a language interaction, or a person referred to in a historical source.
    rolespecifies a primary role or classification for the person.
    sexspecifies the sex of the person.
    agespecifies an age group for the person.
It is worth noting that the age attribute is not intended to record the person's age expressed in years, months, or other temporal unit. Rather it is intended to record into which age bracket, for the purposes of some analysis, the person falls. A simple (perhaps too simple to be useful) binary classification of age brackets would be child and adult. The actual age brackets useful to various projects are likely to be varied and idosyncratic, and thus these Guidelines make no particular recommendation as to possible values. However, it is likely to be of great value to encoders to have a closed list of possible values and documention of those values. Thus projects will typically declare the values being used in their customization file. For example, the following declaration might be useful.
<elementSpec ident="person" module="namesdates" mode="change">
 <attList>
  <attDef mode="replace" ident="age">
   <datatype>
    <rng:ref name="data.enumerated"/>
   </datatype>
   <valList type="closed">
    <valItem ident="child">
     <desc>less than 18 years of age</desc>
    </valItem>
    <valItem ident="adult">
     <desc>18 to 65 years of age</desc>
    </valItem>
    <valItem ident="retired">
     <desc>over 65 years of age</desc>
    </valItem>
   </valList>
  </attDef>
 </attList>
</elementSpec>
The above declaration, were it properly placed in a customization file, establishes that the age attribute of person has only three possible values, child, adult, and retired. For more information on customization see 23.2 Personalization and Customization.

The person element may contain many sub-elements, each specifying a different property of the person being described. The remainder of this section describes these more specific elements. For convenience, these elements are grouped into three classes, corresponding with the tripartite division outlined above: one for traits, one for states and one for events. Each class contains both specific elements for common types of biographical information, and a generic element for other, user-defined, types of information.

All the elements in these three classes belong to the attribute class att.datable, which provides the following attributes:
  • att.datable.w3c provides attributes for normalization of elements that contain datable events using the W3C datatypes.
    whensupplies the value of the date or time in a standard form, e.g. yyyy-mm-dd.
    notBeforespecifies the earliest possible date for the event in standard form, e.g. yyyy-mm-dd.
    notAfterspecifies the latest possible date for the event in standard form, e.g. yyyy-mm-dd.
    fromindicates the starting point of the period in standard form, e.g. yyyy-mm-dd.
    toindicates the ending point of the period in standard form, e.g. yyyy-mm-dd.
as discussed in 13.1 Attribute Classes Defined by this Module above.
13.3.2.1 Personal Characteristics
The model.persTraitLike class contains elements describing physical or socially-constructed characteristics or traits of a person. Members of the class comprise the following specific elements:
  • faith specifies the faith, religion, or belief set of a person.
  • langKnowledge (language knowledge) summarizes the state of a person's linguistic knowledge, either as prose or by a list of langKnown elements.
  • langKnown (language known) summarizes the state of a person's ling