14 Names, Dates, People, and Places

목차

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.6 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 (14.1 Attribute Classes Defined by This Module) before discussing specifically the elements provided for the encoding of component parts of personal names (section 14.2.1 Personal Names), place names (section 14.2.3 Place Names) and organizational names (section 14.2.2 Organizational Names). Elements for encoding personal and organizational data are discussed in section 14.3 Biographical and Prosopographical Data. Elements for the encoding of geographical data are discussed in section 14.3.4 Places. Finally, elements for encoding onomastic data are discussed in 14.3.7 Names and Nyms, and the detailed encoding of dates and times is described in section 14.4 Dates.

⚓︎14.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.

⚓︎14.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 that 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 or identity for the entity being named by means of one or more URIs.
As discussed in 3.6.1 Referring Strings, these attributes provide two different ways of associating any sort of name with its referent. For cases where all that is required is to provide some minimal information about the person name, for example their occupation or status, the att.naming class also provides a simple role attribute. It also provides an additional attribute, which allows the name itself to be associated with a base or canonical form:
  • att.naming 사람, 장소, 조직 등의 이름을 지시하는 요소에 공통적 속성을 제공한다.
    rolemay be used to specify further information about the entity referenced by this name in the form of a set of whitespace-separated values, for example the occupation of a person, or the status of a place.
    nymRef(표준 이름에 대한 참조) URI를 포함하는 요소에 의해 명명된 대상과 연관된 이름의 표준형식 (nym)의 위치를 가리키는 방법을 제공한다.
The encoder may use these attributes in combination as appropriate. For example:
That silly man <name role="politician" type="person">David Paul Brown</name>
has suffered ...
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.
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 14.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 17.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.51 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>

However, as explained in 3.6.1 Referring Strings, interchange is improved by use of tag URIs in ref instead of key.

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

All members of the att.naming class inherit the following attributes from the att.global.responsibility class:

  • att.global.responsibility provides attributes indicating the agent responsible for some aspect of the text, the markup or something asserted by the markup, and the degree of certainty associated with it.
    resp(책임 당사자) 편집자 또는 전사자와 같이 또는 해석에 대한 책임이 있는 대리인을 나타낸다.
    cert(확실성) 간섭 또는 해석과 연관된 확실성의 정도를 나타낸다.

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.

⚓︎14.1.2 Dating Attributes

Members of the att.datable class share the following attributes:

  • att.datable 날짜, 시간 또는 날짜 명기 사건을 포함하는 요소의 규격화에 대한 속성을 제공한다.
    period시간을 명시할 수 있는 항목이 일어난 시간의 기간명을 정의하는 특정 위치로의 포인터를 제공한다.
  • att.datable.w3c W3C 데이터 유형을 사용하여 날짜가 명기된 사건을 포함하는 요소의 규격화를 위한 속성을 제공한다.
    when표준형식으로 날짜 또는 시간의 값을 제공한다.
    notBeforeyyyy-mm-dd와 같은 표준 형식으로 사건의 가능한 한 이른 날짜를 명시한다.
    notAfteryyyy-mm-dd와 같은 표준 형식으로 사건의 가능한 한 나중 날짜를 명시한다.
    from표준 형식으로 기간의 시작 지점을 표시한다.
    to표준 형식으로 기간의 종료 지점을 나타낸다.
The when attribute is used to specify a normalized form for any temporal expression, independently of how it is represented in the text, as in the following example:
<date when="1807-06-09">June 9th</date> The period is approaching which will terminate my present
copartnership. On the <date when="1808-01-01">1st Jany.</date> next, it expires by its own limitation.
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 element 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. The from and to attributes may be used to express the begining and ending of a period of time, for example:
<event xml:id="eMBB" from="1955-12-01"
 to="1956-12-20">
 <label>Montgomery Bus Boycott</label>
 <desc>A political and social protest campaign against the policy of racial segregation on the public transit system of
   the city of <placeName ref="#MONT">Montgomery</placeName>.</desc>
</event>
The notBefore and notAfter attributes may be used to express a range of possibilities for a particular date (or time). For example the following element, extracted from an imaginary prosopographic entry for Anne Calthorpe, indicates that although the exact date of her death is not known, it can be narrowed down to a particular range: from 22 August 1579 to 28 March 1582, inclusive. Ostensibly the encoder has evidence that Anne Calthorpe was alive on the 22nd of August 1579 and evidence that she was already dead on the 28th of March 1582.
<death notBefore="1579-08-22"
 notAfter="1582-03-28"/>

Since when is used for a particular date or time, from and to for a duration, and notBefore and notAfter for a date or time within a range, it makes no sense to use when in combination with one or more of the others. Thus these Guidelines at present recommend against the use of when in combination with any of from, to, notBefore, or notAfter.

The from or to attributes imply that the temporal expression to which they are attached signifies a duration, so the use of either with notBefore or notAfter means a duration is indicated.

notBefore from
notAfter range of possibilities, inclusive duration from from to sometime before notAfter, inclusive
to duration from sometime after notBefore to to, inclusive duration from from to to, inclusive
Some further self-explanatory 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">Lived in Amsterdam during March and April of 1857.</residence>
<date from="1857-03-01"
 notAfter="1857-04-30">From the 1st of March to some time later in March or April of 1857.</date>
<residence notBefore="1857-03-01"
 to="1857-04-30">From the 1st of March or sometime later to the end of April,
1857.</residence>
<residence from="1856-03" to="1858-04">From sometime in March of 1856 to sometime in April of 1858.</residence>

Normalization 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 14.4.3 More Expressive Normalizations below.

⚓︎14.2 Names

⚓︎14.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 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 (개인 이름) 개인의 이름, 성, 존칭어, 추가 명 등의 하나 또는 전부를 사용하여 개인을 지칭하는, 고유명사 또는 고유명사구를 포함한다.
  • surname (surname) 이름, 세례명, 또는 별명에 반대되는 것으로 (물려받은) 성을 포함한다.
  • forename (forename) 이름 또는 세례명을 포함한다.
  • roleName (role name) 공식적 직함 또는 서열과 같이 사회에서 특별한 역할 또는 지위를 나타내는 이름 성분을 포함한다.
  • addName (부가명) 별명, 통명, 가명, 또는 개인 이름 내에서 사용되는 다른 기술적 구와 같이 부가적 이름 성분을 포함한다.
  • nameLink (name link) van der 또는 of와 같이 이름의 부분으로 간주되지 않는 이름 내의 연결 구 또는 연결을 포함한다.
  • genName (세대명 성분) 개인의 상대적 나이 또는 세대에 기반하여 유사 이름을 다른 방식으로 구분하는 이름 성분을 포함한다.

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 (사람 이름의 성분에 대한 속성) 사람 이름의 부분을 형성하는 요소에 대한 공통 속성
    full축약 또는 이니셜로 간단하게 이름 성분이 완전히 제시된 것인지의 여부를 나타낸다.
    sort(sort) 사람 이름 내에 다른 것과 관련된 이름 성분의 정렬 순서를 명시한다.
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, birth, pen, pseudo, or religious name. Consequently the following examples are equivalent:
That silly man <rs ref="tag:projectname.org,2012: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 ref="tag:projectname.org,2012:DPB1"
 type="person">
 <name>David Paul Brown</name>
</rs> has suffered ...
That silly man <name ref="tag:projectname.org,2012:DPB1"
 type="person">David Paul Brown</name> has suffered ...
That silly man <persName ref="tag:projectname.org,2012: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="birth">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 ref="tag:projectname.org,2012: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 ref="tag:projectname.org,2012:HEMA1">
 <surname>Marques</surname>
 <genName>Junior</genName>, <forename>Henrique</forename>
</persName>
<persName>
 <forename>Charles</forename>
 <genName>II</genName>
</persName>
<persName xml:lang="de">
 <forename>Rudolf</forename>
 <genName>II</genName>
 <surname>von Habsburg</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 ref="tag:projectname.org,2012: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 mark roles which function as part of a person's name, not the role of the person bearing the name in general. Information about roles, occupations, etc. of a person are encoded within the person element discussed below in 14.3 Biographical and Prosopographical Data.

Here are some further examples of the usage of these elements:
<persName ref="tag:projectname.org,2012:PGK1">
 <roleName type="nobility">Princess</roleName>
 <forename>Grace</forename>
</persName>
<persName ref="tag:projectname.org,2012:GRMO1"
 type="pseudo">
 <addName type="honorific">Grandma</addName>
 <surname>Moses</surname>
</persName>
<persName ref="tag:projectname.org,2012:SLWICL1">
 <roleName type="office">President</roleName>
 <forename>Bill</forename>
 <surname>Clinton</surname>
</persName>
<persName ref="tag:projectname.org,2012:MOGA1">
 <roleName type="military">Colonel</roleName>
 <surname>Gaddafi</surname>
</persName>
<persName ref="tag:projectname.org,2012:FRTG1">
 <forename>Frederick</forename>
 <addName type="epithet">the Great</addName>
</persName>
A name may have any combination of the above elements:
<persName ref="tag:projectname.org,2012: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, nor for every 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 19 Feature Structures.

White space is allowed and therefore significant between elements within name, persName, orgName, and placeName. Therefore 

<persName> <forename>Mary</forename> <forename>Ann</forename> <nameLink>De</nameLink><surname>Mint</surname> </persName>⚓

encodes ‘Mary Ann DeMint’ and 

<persName> <forename>Mary</forename><forename>Ann</forename> <nameLink>De</nameLink> <surname>Mint</surname> </persName>⚓

encodes ‘MaryAnn De Mint’. See 1.3.1.1.6 XML Whitespace for more information on whitespace in XML.

⚓︎14.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 institutions such as ‘Harvard College’ or ‘the BBC’ and businesses such as ‘Apple’ or ‘Google’ 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 businesses 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 (조직명) 조직명을 포함한다.

This element is a member of the same attribute classes as persName, as discussed above in 14.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"
 ref="tag:projectname.org,2012: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 ref="tag:projectname.org,2012:PAS1"
 type="org">
 <name>Pennsyla. Abolition Society</name>
</rs>.
About a year back, a question of considerable interest was agitated in the
<name ref="tag:projectname.org,2012: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 14.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 may include place names as well as personal 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>

⚓︎14.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 14.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 14.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 14.2.3.3 Relative Place Names).

  • placeName (place name) 절대적 또는 상대적 위치명을 포함한다.
  • geogName (지리명) 윈드러시 계곡 또는 시나이 산과 같이 지리적 특성과 관련된 이름

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 14.3.4 Places below.

Like the persName element discussed in section 14.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:52
After spending some time in our <rs ref="tag:projectname.org,2012:NY1"
 type="place">modern <name ref="tag:projectname.org,2012:BA1"
  type="place">Babylon</name>
</rs>, <name ref="tag:projectname.org,2012:NY1"
 type="place">New York</name>, I have proceeded to the <rs ref="tag:projectname.org,2012:PH1"
 type="place">City of Brotherly Love</rs>.
After spending some time in our <placeName ref="tag:projectname.org,2012:NY1">modern <placeName ref="tag:projectname.org,2012:BA1">Babylon</placeName>
</placeName>, <placeName ref="tag:projectname.org,2012:NY1">New York</placeName>, I have proceeded
to the <placeName ref="tag:projectname.org,2012:PH1">City of Brotherly Love</placeName>.
⚓︎14.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 (district) 교구, 구 또는 다른 행정 지리적 단위와 같이 거주지의 하위 구분명을 포함한다.
  • settlement (settlement) 하나의 지리-정치 또는 행정 단위로 식별되는 시, 읍, 마을과 같이 거주지명을 포함한다.
  • region (region) 도보다는 작고 정착지보다는 큰 주, 성, 도와 같은 행정단위명을 포함한다.
  • country (country) 하나의 블록보다 큰 국가, 지역, 식민지, 또는 공화국, 또는 하나의 블록보다 작은 지역의 상급 행정기관과 같은, 지리-정치 단위명을 포함한다.
  • bloc (bloc) 둘 이상의 민족국가 또는 국가로 구성된 지리-정치적 단위의 이름을 포함한다.
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 ref="tag:projectname.org,2012: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>
⚓︎14.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 ref="tag:projectname.org,2012:MIRI1"
 type="river">Mississippi River</geogName>

In addition to the usual phrase level elements, the geogName element may contain the following specialized element:

  • geogFeat (지리적 특성명) 계곡 산 등과 같이 지리적명에 포함된 지리적 특성을 식별하는 일반명사를 포함한다.
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 ref="tag:projectname.org,2012: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 ref="tag:projectname.org,2012:GLCO1"
 type="place">Glencoe</name> into <geogName ref="tag:projectname.org,2012:GLET1"
 type="glen">
 <geogFeat>Glen</geogFeat>
 <name>Etive</name>
</geogName>, the <geogName ref="tag:projectname.org,2012:LAGA1"
 type="hill">
 <geogFeat xml:lang="gd">Lairig</geogFeat>
 <name>Gartain</name>
</geogName> and the
<geogName ref="tag:projectname.org,2012: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 14.3.7 Names and Nyms.

⚓︎14.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 (offset) 표현에 포함된 두 장소명, 날짜, 또는 시간 사이의 차이 방향을 표시하는 상대적 시간 또는 공간 표현의 부분
  • measure (measure) 개체 또는 물체의 수량을 지시하는 단어 또는 구를 포함한다. 이들은 숫자, 단위, 물체명으로 구성되어 있다.
Some examples of relative place names are:
<placeName ref="tag:projectname.org,2012: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 ref="tag:projectname.org,2012: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 24.3 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 14.3.7 Names and Nyms may also be of use. Alternatively, the meaning structure itself may be represented using feature structures (19 Feature Structures).

⚓︎14.2.4 Event Names

The eventName element is provided in parallel to other naming mechanisms; it is intended especially for ‘canonical’ names that are used in texts to mention specific named events, whether real or fictional.
<p>On <date when="1719-03-19">Monday</date>, <rs type="person">she</rs> was writing about the
<eventName ref="#SecondDefPrague">1618 Defenestration of Prague</eventName> which initiated the
<rs type="event" ref="#ThirtyYearsWar">long war</rs>.</p>
  • eventName (name of an event) contains a proper noun or noun phrase used to refer to an event.

There are two major applications of eventName:

  • to indicate names of events mentioned in transcribed text, such as in the above example; and
  • to indicate the names of events for which details are being provided in an event element.

For the first application, as with most other naming elements, the eventName element is a member of the att.canonical class, and thus the ref (or key) attribute may be used to refer to a an event element (about which see 14.3.5 Events) or some other data item that contains further information about the event.

When used as a direct child of event, an eventName provides one of the names of the event about which details are being provided in its parent event. A single event may be known by many names. All, only one, or indeed none of these might be provided in the event used to provide information about such an event. If more than one eventName is used they may be differentiated by use of type, where, or dating attributes. In cases where multiple event elements describe events that have the same name, the xml:id attribute of the event or an idno, head, or label sibling of the eventName may be used for disambiguation and identification. Typically xml:id or idno would be used for machine-processable disambiguation, and either head or label for human readers.

⚓︎14.2.5 Object Names

  • objectName (name of an object) contains a proper noun or noun phrase used to refer to an object.
As with other proper nouns or noun phrases used as names, the names of objects may be marked up simply with the name element. For those working with a variety of named objects the objectName element provides more flexibility.
<p>The <objectName ref="#MinsterLovellJewel">Minster Lovell Jewel</objectName> is probably the most similar to the
<objectName ref="#AlfredJewel">Alfred Jewel</objectName> and was found in <placeName ref="#MinsterLovell">Minster
   Lovell</placeName> in <placeName ref="#Oxfordshire">Oxfordshire</placeName> and is kept at the <orgName ref="#AshmoleanMuseum">Ashmolean Museum</orgName>.</p>

The objectName element may be used to encode any named object whether or not this is a text-bearing object. The use of objectName by itself does not categorize the object referenced, but this may be done further with the type and subtype attributes or through reference to a taxonomy. Additionally, the use of the objectName element says nothing about the physical reality of the object – that is whether it is real, fictional, purported, or missing – and this may be one aspect that some may wish to record through the type attribute. Where more detailed information is available for a named object the ref attribute should be used to point to an object element or other source of information about this object. The objectName element is intended for named objects; where an object is mentioned through a descriptive phrase but not named explicitly the rs element should be used.

⚓︎14.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 a number of users and uses for these elements. For example, an encoder may be interested in creating or converting a set of biographical records of the type found in a Dictionary of National Biography. Another use is the creation or conversion of a database-like collection of information about a group of people, such as the people referenced in a marked-up collection of documents, or persons who have served as informants in the creation of spoken corpora. It is also appropriate to use these elements to register information relating to those who have taken part in the creation of a TEI document.

To cater for this diversity, these Guidelines propose a flexible strategy, in which encoders may choose for themselves the approach 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 14.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 in the text, and encode it directly using the more specific elements described in this section.

⚓︎14.3.1 Basic Principles

Information about people, places, organizations, and events, 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,
  • external resources where other information on the subject can be found.

‘Characteristics’ or ‘traits’ are typically independent of an individual's volition or action and can be either physical, such as hair and eye colour; or cultural, such as ethnicity and caste. The distinction is not entirely straightforward: gender and sex can be regarded as culturally determined with physical manifestations, interpreted based on the social hierarchies of a time and place. Also the division of humanity into different ‘races’, formalized in the nineteenth century to organize a hierarchy of humanity on the basis of physical characteristics such as skin colour, hair type, and skull measurements, is now recognized as a colonialist social construct.53 When such a construct defined individuals' identities beyond their volition, the markup and documentation should reflect this as a culturally-determined characteristic.

‘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.

‘Changes in state’ refer to life-changing or identity-changing events 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 about 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 documentable, put into a time frame, and be relatable to other statements or assertions.

The elements defined by the module described in this chapter may, for the most part, all be regarded as specializations of one or other of the above three classes. Generic elements for state, trait, and event are also defined:

  • state (state) 개인, 장소, 또는 조직에 관련한 현재 지위 또는 특성 기술을 포함한다.
  • trait (trait) 사람 또는 장소에 관한, 문화적으로 결정된 특성 기술을 포함한다.
  • event (event) 개인, 장소, 또는 조직과 관련된 중요한 사건에 해당하는 데이터를 포함한다.
  • att.locatable provides attributes for referencing locations by pointing to entries in a canonical list of places.
    whereindicates one or more locations by pointing to a place element or other canonical description.
  • listEvent (list of events) contains a list of descriptions, each of which provides information about an identifiable event.

When developing a prosopography record of a named entity it is a common practice to refer explicitly to other resources, for example the Library of Congress Name Authority File, Virtual Internationl Authority File (VIAF), a gazetteer of places like Pleiades, or a printed book.

  • idno (식별 숫자) 서지 정보 항목을 식별하기 위해 사용되는 표준 또는 비표준 숫자를 제시한다.
    type예를 들어 ISBN 또는 기타 표준 일련번호로, 숫자를 범주화한다.
Here is a simple example:
<place xml:id="Rome">
 <placeName>Rome</placeName>
 <location>
  <geo>41.891775 12.486137</geo>
 </location>
 <idno type="Pleiades">423025</idno>
 <note>capital of the Roman Empire</note>
</place>

⚓︎14.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 14.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.

  • listPerson (개인 목록) 기술 목록을 포함하며, 그 개별 기술 각각은, 언어 상호작용 참여자 또는 역사적 원전에서 언급되는 사람과 같이, 식별 가능한 사람 또는 사람군에 관한 정보를 제공한다.
  • listRelation 비공식적으로 산문체 또는 공식적으로 표현된 관계 연결을 통하여 사람, 장소, 그리고 조직 사이에 식별되는 관련성에 관한 정보를 제공한다.

One or more listPerson elements may be supplied within the standOff element (see 17.10 The standOff Container) or, when used to list the participants in a linguistic interaction, within the particDesc (participant description) element in the profileDesc element of a TEI header. Like other forms of list, however, 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:
<standOff>
 <listPerson type="fictional">
  <person xml:id="person_FAS">
   <persName>Adam Schiff</persName>
   <note>District Attorney for <placeName>Manhattan</placeName> in
       seasons 1 to 10 of <title>Law and Order</title>.</note>
  </person>
  <person xml:id="person_FML">
   <persName>Mike Logan</persName>
   <note>
    <choice>
     <abbr>NYPD</abbr>
     <expan>New York Police
           Department</expan>
    </choice> Detective regularly appearing in
       seasons 1 to 5 of <title>Law and Order</title> and seasons 5 to 7
       of <title>Law and Order: Criminal Intent</title>.</note>
  </person>
  <person xml:id="person_FBS">
   <persName>Benjamin Stone</persName>
   <note>Executive Assistant District Attorney for
   <placeName>Manhattan</placeName> in seasons 1 to 4 of <title>Law
         and Order</title>
   </note>
  </person>
  <person xml:id="person_FJM">
   <persName>Jack McCoy</persName>
   <note>An Executive Assistant District Attorney then District
       Attorney for <placeName>Manhattan</placeName> in seasons 5 to 10
       of <title>Law and Order</title>, in seasons 1, 9, 11, and 19 of
   <title>Law and Order: Special Victims Unit</title>, and in
       season 1 of <title>Law and Order: Trial by Jury</title>.</note>
  </person>
  <person xml:id="person_FJR">
   <persName>Jamie Ross</persName>
   <note>An Assistant District Attorney for
   <placeName>Manhattan</placeName> in seasons 7 &amp; 8 of
   <title>Law and Order</title>, and a defense attorney in seasons
       10 &amp; 11, and then a judge in <title>Law and Order: Trial by
         Jury</title>.</note>
  </person>
  <person xml:id="person_FJF">
   <persName>Joe Fontana</persName>
   <note>
    <choice>
     <abbr>NYPD</abbr>
     <expan>New York Police
           Department</expan>
    </choice> Detective regularly appearing
       in seasons 15 &amp; 16 of <title>Law and Order</title>.</note>
  </person>
 </listPerson>
<!-- == == -->
 <listPerson type="real">
  <person xml:id="person_RAS">
   <persName>Adam Schiff</persName>
   <note>U.S. Representative from California since 2013.</note>
  </person>
  <person xml:id="person_RML">
   <persName>Mike Logan</persName>
   <note>Gridiron football player for the Pittsburgh Steelers from
       2001 to 2006.</note>
  </person>
  <person xml:id="person_RBS">
   <persName>Benjamin Stone</persName>
   <note>Michigan State Senator from 1968 to 1979.</note>
  </person>
  <person xml:id="person_RJM">
   <persName>Jack McCoy</persName>
   <note>Iowa State Representative from 1955 to 1959.</note>
  </person>
  <person xml:id="person_RJR">
   <persName>Jamie Ross</persName>
   <note>Broadway actor, with occasional forays into television,
       from 1971 to roughly 2007.</note>
  </person>
  <person xml:id="person_RJF">
   <persName>Joe Fontana</persName>
   <note>A member of Canada’s House of Commons from 1987 to 2006,
       and mayor of London, Ontario from 2010 to 2014.</note>
  </person>
 </listPerson>
</standOff>

The person element carries several attributes. As a member of the classes att.global.responsibility, att.editLike, and att.global.source class, it carries the usual attributes for providing details about the information recorded for that person, such as its reliability or source:

  • att.global.responsibility provides attributes indicating the agent responsible for some aspect of the text, the markup or something asserted by the markup, and the degree of certainty associated with it.
    cert(확실성) 간섭 또는 해석과 연관된 확실성의 정도를 나타낸다.
    resp(책임 당사자) 편집자 또는 전사자와 같이 또는 해석에 대한 책임이 있는 대리인을 나타낸다.
  • att.editLike 어떤 유형의 부호화된 학문적 간섭 또는 해석의 특성을 기술하는 속성을 제공한다.
    evidence간섭 또는 해석의 신뢰성 또는 정확성을 지지하는 증거의 특성을 나타낸다. 제안값은 다음을 포함한다: 1] internal; 2] external; 3] conjecture
  • att.global.source provides attributes used by elements to point to an external source.
    sourcespecifies the source from which some aspect of this element is drawn.

In addition, a small number of very commonly used personal properties may be recorded using attributes specific to person and personGrp:

  • person (person) 예를 들어 언어 상호작용의 참여자 또는 역사적 문헌에서 언급된 사람과 같이 식별가능한 개인에 관한 정보를 제공한다.
    role사람에 대한 주요 역할 또는 분류를 명시한다.
    sex사람의 성을 명시한다.
    age사람의 연령군을 명시한다.
  • personGrp (개인군) 분석적 목적을 위해 하나의 개인으로 처리된 개인군을 기술한다.

These attributes are intended for use where only a small amount of data is to be encoded in a more or less normalized form, possibly for many person elements, for example when encoding basic facts about respondents to a questionnaire. When however a more detailed encoding is required for all kinds of information about a person, for example in a historical gazetteer, then it will be more appropriate to use the elements age, sex and others described elsewhere in this chapter.

Note 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 idiosyncratic, and thus these Guidelines make no particular recommendation as to possible values. Instead, individual projects are recommended to define the values they use in their own customization file, using a declaration like the following:
<elementSpec ident="person"
 module="namesdates" mode="change">
 <attList>
  <attDef mode="replace" ident="age">
   <datatype>
    <dataRef key="teidata.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 24.3 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 may contain specific elements for common types of biographical information, and contains 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 W3C 데이터 유형을 사용하여 날짜가 명기된 사건을 포함하는 요소의 규격화를 위한 속성을 제공한다.
    when표준형식으로 날짜 또는 시간의 값을 제공한다.
    notBeforeyyyy-mm-dd와 같은 표준 형식으로 사건의 가능한 한 이른 날짜를 명시한다.
    notAfteryyyy-mm-dd와 같은 표준 형식으로 사건의 가능한 한 나중 날짜를 명시한다.
    from표준 형식으로 기간의 시작 지점을 표시한다.
    to표준 형식으로 기간의 종료 지점을 나타낸다.

as discussed in 14.1 Attribute Classes Defined by This Module above.

⚓︎14.3.2.1 Personal Characteristics
The model.persStateLike class contains elements describing physical or socially-constructed characteristics, traits, or states of a person. Members of the class comprise the following specific elements:
  • affiliation (affiliation) 고용주 또는 후원자와 같이 개인의 현재 또는 과거 소속 조직에 대한 비공식적 기술을 포함한다.
  • age (age) 개인의 나이를 명시한다.
  • education (education) 개인의 학력에 대한 기술을 포함한다.
  • faith (faith) 개인의 신념, 종교 또는 믿음을 명시한다.
  • floruit (floruit) 개인의 활동 기간에 대한 정보를 포함한다.
  • gender (gender) specifies the gender identity of a person, persona, or character.
  • langKnowledge (언어 지식) 산문체 또는 langKnown 요소 목록으로 개인의 언어 지식 상태를 요약한다.
  • nationality (nationality) 개인의 현재 또는 과거의 국적 또는 시민권에 대한 비공식적 기술을 포함한다.
  • occupation (occupation) 개인의 직업에 대한 비공식적 기술을 포함한다.
  • persName (개인 이름) 개인의 이름, 성, 존칭어, 추가 명 등의 하나 또는 전부를 사용하여 개인을 지칭하는, 고유명사 또는 고유명사구를 포함한다.
  • persona provides information about one of the personalities identified for a given individual, where an individual has multiple personalities.
  • persPronouns (personal pronouns) indicates the personal pronouns used, or assumed to be used, by the individual being described.
  • residence (거주) 개인의 현재 또는 과거의 거주지를 기술한다.
  • sex (sex) 개인의 성을 명시한다.
  • socecStatus (사회-경제적 지위) 개인의 사회 또는 경제적 지위에 대한 비공식적 기술을 포함한다.
  • state (state) 개인, 장소, 또는 조직에 관련한 현재 지위 또는 특성 기술을 포함한다.
  • trait (trait) 사람 또는 장소에 관한, 문화적으로 결정된 특성 기술을 포함한다.
All, apart from langKnowledge and persona, allow content of ordinary prose containing phrase-level elements.
<socecStatus ref="tag:projectname.org,2012:AB1">Status AB1 in the RG Classification scheme</socecStatus>

Encoders should take particular care to be explicit about culturally determined concepts such as nationality, ethnicity, age, or sex/gender system that influence their markup.54 For example, when recording personal age in different cultures, there may be different assumptions about the point from which age is reckoned. Scholars face similar issues when marking sex and gender according to cultural systems from times and places not their own. A statement of the practice adopted in a given encoding may usefully be provided in the editorialDecl element discussed in 2.3.3 The Editorial Practices Declaration.

The langKnowledge element contains either paragraphs or a number of langKnown elements; it may take a tags attribute, which provides one or more standard codes or ‘tag’s for the languages. The langKnown element must have a tag attribute, which indicates the language with the same kind of ‘language tag’. These ‘language tags’ are discussed in detail in vi.1. Language Identification.

Furthermore, the langKnown element also has a level attribute to indicate the level of the person's competence in the language. It is thus possible either to say:
<langKnowledge tags="ff fr wo en">
 <p>Speaks fluent Fulani, Wolof, and French. Some knowledge of
   English.</p>
</langKnowledge>
or
<langKnowledge>
 <langKnown level="fluent" tag="ff">Fulani</langKnown>
 <langKnown level="fluent" tag="wo">Wolof</langKnown>
 <langKnown level="fluent" tag="fr">French</langKnown>
 <langKnown level="basic" tag="en">English</langKnown>
</langKnowledge>

The persona element may contain the same component elements as a person element. Its function is to document a distinct persona assumed by the person element containing it. A person, not necessarily fictional, may take on different personas at different times or in different situations, each persona having different personal characteristics, such as name, age, sex, gender etc. We distinguish a persona, which is a set of characteristics associated with one specific individual, from a role, which is a set of characteristics that many different people can assume. An actor does not change their persona when adopting a different role, but none of the personas associated with one person can properly be associated with another.

The persPronouns element may be used to indicate the personal pronouns used, or assumed to be used, by the individual being described. It is common practice in email signatures and biographies, for people to include their preferred personal pronouns along with their name or handle. This allows transgender and gender variant people to express how they wish to be identified, without having to share their gender identity (though some do). Cisgender people have also adopted the practice, which normalizes the idea that a person's personal pronouns should not be inferred by their name, sex, gender, or gender presentation. The persPronouns element may be used either in transcribed content to encode a phrase used to indicate preferred personal pronouns, or may be used inside a person or persona element to indicate the associated pronouns.

For example, the following entry from a hypothetical prosopography lists only the nominative case of the preferred pronouns as identified by Miss Major Griffin-Gracy, a historical figure.
<person>
 <persName>
  <forename>Miss Major</forename>
  <surname>Griffin-Gracy</surname>
 </persName>
 <birth when="1940-10-25"/>
 <gender value="transWoman"
  evidence="selfIdentification">trans woman</gender>
 <persPronouns value="she"
  evidence="selfIdentification"/>
 <note>
  <p>Veteran of the Stonewall Riots. Founder of the
     Griffin-Gracy Educational Retreat and Historical
     Center (the House of GG). Activist and advocate for
     transgender and gender-nonconforming people of
     color.</p>
 </note>
</person>
Personal pronouns often occur as part of the closer of an email, post, or other electronic communication.
<div type="email">
 <opener>
  <salute>Dear all,</salute>
 </opener>
 <p>With apologies for length. I'm expanding a schema …</p>
<!-- ... -->
 <closer>
  <lb/>
  <persName>Diane Jakacki, Ph.D.</persName>
  <lb/>
  <roleName>Digital Scholarship Coordinator</roleName>
  <lb/>
  <roleName>Affiliate Faculty in Comparative &amp; Digital Humanities</roleName>
  <lb/>
  <orgName>Bucknell University</orgName>
  <lb/>
  <email>d…@….edu</email>
  <lb/>(<persPronouns>she/her/hers</persPronouns>)
 <lb/>
  <lb/>
  <roleName>Principal Investigator</roleName>,
 <lb/>
  <orgName>LAB Cooperative</orgName> and <orgName>REED London Online</orgName>
  <lb/>
  <roleName>Chair</roleName>, <orgName>ADHO Conference Coordinating Committee</orgName>
 </closer>
</div>
The sex and gender elements each carry a value attribute to give values from a project-internal taxonomy, or an external standard.
<sex value="F">female</sex>
<gender value="W">woman</gender>
As elsewhere, these coded values may be used as an alternative to or normalization of the actual descriptive text contained in the element. The previous example might equally well be given as
<sex value="F"/>
<gender value="W"/>
The generic trait and state elements are also members of this class,
  • trait (trait) 사람 또는 장소에 관한, 문화적으로 결정된 특성 기술을 포함한다.
  • state (state) 개인, 장소, 또는 조직에 관련한 현재 지위 또는 특성 기술을 포함한다.
These elements can be used to extend the range of information supplied about an individual's personal characteristics. Either may contain an optional label element, used to provide a human-readable specification for the characteristic concerned and a description of the feature itself supplied within a desc element. These may be followed by or one or more p elements supplying more detailed information about the trait. In either case, these may be followed by one or more notes or bibliographical references. The type, ref, and key attributes may be used to indicate a fuller definition of the combination of feature and value.
<trait type="ethnicity" key="alb">
 <label>Ethnicity</label>
 <desc>Ethnic Albanian.</desc>
</trait>
These elements are provided as a simple means of extending the set of descriptive features available in a standardized way. For example, there are no predefined elements for such features as eye or hair colour. If these are to be recorded, they may simply be added as new types of trait:
<trait type="physical">
 <label>eye colour</label>
 <desc>blue</desc>
</trait>
<trait type="physical">
 <label>hair colour</label>
 <desc>brown</desc>
</trait>

If none of the more specialized elements listed above is appropriate, then a choice must be made between the two generic elements trait and state. If you wish to distinguish between characteristics that are generally perceived to be transient and those which are generally considered unchanging, use state for the former, and trait for the latter. It may also be helpful to note that traits are typically, but not necessarily, independent of the volition or action of the holder. If the distinction between state and trait is not considered relevant or useful, use state.

The persName element is repeatable and can, like all TEI elements, take the attribute xml:lang to indicate the language of the content of the element, as well as a type attribute to indicate the type of name, whether a nickname, maiden or birth name, alternative form, etc. This is useful in cases where, for example, a person is known by a Latin name and also by any number of vernacular names, many or all of which may have claims to ‘authenticity’. In order to ensure uniformity, the method generally employed in the library world has been to accept the form found in some authority file, for example that of the American Library of Congress, as the ‘base’ or ‘neutral’ form. Feelings can run high on this matter, however, and people are often reluctant to accept as ‘neutral’ an overtly foreign form of the name of their local saint or hero. Within the person element any number of variant forms of a name can be given, with no prioritization, and hence less likelihood of offence. The Icelandic scholar and manuscript collector Árni Magnússon, to give his name in standard modern Icelandic spelling, is known in Danish as Arne Magnusson, the form which he himself, as a long term resident of Denmark, generally used; there is also a Latinized form, Arnas Magnæus, which he used in his scholarly writings. All three forms can be given, and in any order:
<person xml:id="ArnMag">
 <persName xml:lang="is">Árni Magnússon</persName>
 <persName xml:lang="da">Arne Magnusson</persName>
 <persName xml:lang="la">Arnas Magnæus</persName>
</person>
At the other extreme, a person may be named periphrastically as in the following example:
<person xml:id="simon_son_of_richard2">
 <persName>Simon, son of Richard</persName>
 <residence>
  <placeName>
   <region>Essex</region>
  </placeName>
 </residence>
 <floruit notBefore="1219" notAfter="1223">1219-1223</floruit>
</person>
Alternatively, the generic name element may be used for all of the naming components in a description. For example, a description of the first living held by the Icelandic clergyman and poet Jón Oddsson Hjaltalín might be tagged as follows:
<state type="office" from="1777-04-07"
 to="1780-07-12">
 <p>Jón's first living — which he apparently accepted rather reluctantly — was at <name type="place">Háls í
     Hamarsfirði</name>, <name type="place">Múlasýsla</name>, to which he was presented on 7 April 1777. He was
   ordained the following month and spent three years at Háls, but was never happy there, due largely to the general
   penury in which he was forced to live — a recurrent theme throughout the early part of his life. In June of 1780
   the bishop recommended that Jón should <q xml:lang="da">promoveres til andet bedre kald, end det hand hidindtil
     har havt</q>, and on 12 July it was agreed that he should exchange livings with <name type="person"
   ref="tag:projectname.org,2012:ThorJon">sr. Þórður Jónsson</name> at <name type="place">Kálfafell á Síðu</name>,
 <name type="place">Skaftafellssýsla</name>.</p>
 <bibl>ÞÍ, Stms I.15, p. 733.</bibl>
 <bibl>ÞÍ, Stms I.17, p.
   102.</bibl>
</state>
Similarly, the generic state or trait element may be used in preference to the more specific elements listed above:
<state type="nationality"
 notBefore="2002-01-15">
 <label>Nationality</label>
 <desc>American citizen from 15 January 2002.</desc>
</state>
is the same as:
<nationality notBefore="2002-01-15">American citizen from 15 January 2002.</nationality>
or even:
<nationality notBefore="2002-01-15"
 key="US"/>
⚓︎14.3.2.2 Personal Events

This section describes events that relate to one or more persons, while the section on Events below describes the use of event in more general terms.

Events in a person's history are not characteristics of an individual, but often cause an individual to gain such characteristics, or to enter a new state. Most such events, for example marriage, appointment, promotion, or a journey may be recorded using the generic element event, which may be grouped with listEvent, and has a content model similar to that of state and trait. The chief difference is that event can include a placeName element to identify the name of the place where the event occurred.

Two particular events in a person's life, namely birth and death, are both ubiquitous and usually considered particularly important, and thus may be represented by specialized elements for the purpose:

  • birth (birth) 날짜, 장소와 같이 개인의 출생에 관한 정보를 포함한다.
  • death (death) 날짜, 장소와 같이 개인의 죽음과 관련된 정보를 포함한다.
In the following example, we give a brief summary of the wedding of Jane Burden to the English writer, designer, and socialist William Morris, encoded as an event element embedded within the person element used to record data about Morris, though we could equally well have embedded the event element within the person element for Burden, or have encoded it independently of either person element:
<person xml:id="WM">
<!-- ... -->
 <event type="marriage" when="1859-04-26">
  <label>Marriage</label>
  <desc>
   <name type="person" ref="#WM">William Morris</name> and <name type="person"
    ref="http://en.wikipedia.org/wiki/Jane_Burden">Jane Burden</name> were married at <name type="place">St
       Michael's Church, Ship Street, Oxford</name> on <date when="1859-04-26">26 April 1859</date>. The wedding was
     conducted by Morris's friend <name type="person" ref="#RWD">R. W. Dixon</name> with <name type="person" ref="#CBF">Charles Faulkner</name> as the best man. The bride was given away by her father, <name type="person" ref="#RB">Robert Burden</name>. According to the account that <name type="person"
    ref="http://en.wikipedia.org/wiki/Edward_Burne-Jones">Burne-Jones</name> gave <name type="person" ref="#JWM">Mackail</name>
   <quote>M. said to Dixon beforehand <said>Mind you don't call her Mary</said> but he did</quote>. The entry in
     the Register reads: <quote>William Morris, 25, Bachelor Gentleman, 13 George Street, son of William Morris decd.
       Gentleman. Jane Burden, minor, spinster, 65 Holywell Street, d. of Robert Burden, Groom.</quote> The witnesses
     were Jane's parents and Faulkner. None of Morris's family attended the ceremony. Morris presented Jane with a
     plain gold ring bearing the London hallmark for 1858. She gave her husband a double-handled antique silver
     cup.</desc>
  <bibl>J. W. Mackail, <title>The Life of William Morris</title>, 1899.</bibl>
 </event>
</person>
<person xml:id="RB">
 <persName>Robert Burden</persName>
</person>
<person xml:id="RWD">
 <persName>R.W. Dixon</persName>
</person>
<person xml:id="CBF">
 <persName>Charles Faulkner</persName>
</person>
<person xml:id="EBJ">
 <persName>
  <forename>Edward</forename>
  <surname>Burne-Jones</surname>
 </persName>
</person>
<person xml:id="JWM">
 <persName>J.W. Mackail</persName>
</person>
In this example the ref attributes on the various name elements point either to an external source or to a person element within which other information about the person named may be found. As further discussed below (14.3.2.3 Personal Relationships), a relation element may then be used to link them in a more meaningful way:
<relation name="spouse" mutual="#WM #JBM"/>
<relation name="friend" mutual="#WM #RWD"/>
<relation name="parent" active="#RB"
 passive="#JBM"/>
As mentioned above, all these elements, both the specific and the generic, are members of the att.datable attribute class, which means they can be limited in terms of time. The following encoding, for example, demonstrates that the person named David Jones changed his name in 1966 to David Bowie:
<person xml:id="DB">
 <persName notAfter="1966">David Jones</persName>
 <persName notBefore="1966">David Bowie</persName>
</person>
All the generic elements are also members of the att.global.responsibility and att.editLike classes. These classes make available the attributes cert, to indicate the degree of certainty, resp, the agency responsible, evidence, the nature of the evidence used, and source, a pointer to a resource from which the information derives. In this way it is possible, in the case of multiple and conflicting sources, to provide more than one view of what happened, as in the following example:
<event type="birth" resp="#XYZ" cert="high">
 <p>Born in <name type="place">Brixton</name> on 8 January
   1947.</p>
</event>
<event type="birth" resp="#ABC" cert="low">
 <p>Born in <name type="place">Berkhamsted</name> on 9 January
   1947.</p>
</event>
⚓︎14.3.2.3 Personal Relationships

When the module defined by this chapter is included in a schema, the following two elements may be used to document relationships amongst the persons, places, or organizations identified:

  • listRelation 비공식적으로 산문체 또는 공식적으로 표현된 관계 연결을 통하여 사람, 장소, 그리고 조직 사이에 식별되는 관련성에 관한 정보를 제공한다.
  • relation (관련성) 명시된 참여자군 사이에 관련성 또는 연결 종류를 기술한다.
    name이것이 실례인 관련성 종류에 대한 이름을 제공한다.
    activeidentifies the ‘active’ participants in a non-mutual relationship, or all the participants in a mutual one.
    mutualsupplies a list of participants amongst all of whom the relationship holds equally.
    passive비상호적 관련성에서 ‘passive’ 참여자를 식별한다.

These elements are both members of the att.typed class, from which they inherit the type and subtype attributes in the usual way. The value specified for either attribute on a listRelation element is implicitly applicable to all of its child relation elements, unless overridden.

A relationship, as defined here, may be any kind of describable link between specified participants. A participant (in this sense) might be a person, a place, or an organization. In the case of persons, therefore, a relationship might be a social relationship (such as employer/employee), a personal relationship (such as sibling, spouse, etc.) or something less precise such as ‘possessing shared knowledge’. A relationship may be mutual, in that all the participants engage in it on an equal footing (for example the ‘sibling’ relationship); or it may not be if participants are not identical with respect to their role in the relationship (for example, the ‘employer’ relationship). For non-mutual relationships, only two kinds of role are currently supported; they are named active and passive. These names are chosen to reflect the fact that non-mutual relations are directed, in the sense that they are most readily described by a transitive verb, or a verb phrase of the form is X of or is X to. The subject of the verb is classed as active; the direct object of the verb, or the object of the concluding preposition, as passive. Thus parents are ‘active’ and children ‘passive’ in the relationship ‘parent’ (interpreted as is parent of); the employer is ‘active’, the employee ‘passive’, in the relationship employs. These relationships can be inverted: parents are ‘passive’ and children ‘active’ in the relationship is child of; similarly ‘works for’ inverts the active and passive roles of ‘employs’.

For example:
<listRelation>
 <relation name="parent" active="#P1 #P2"
  passive="#P3 #P4"/>
 <relation name="spouse" mutual="#P1 #P2"/>
 <relation type="social" name="employer"
  active="#P1" passive="#P3 #P4"/>
</listRelation>
This example defines the relationships amongst a number of people not further described here; we assume however that each person has been allocated an identifier such as P1, P2, etc. which can be linked to using references such as #P1, #P2, etc. Then the above set of relation elements describe the following three relationships amongst the people referenced:
  • P1 and P2 are parents of P3 and P4.
  • P1 and P2 are linked in a mutual relationship called ‘spouse’—that is, P2 is the spouse of P1, and P1 is the spouse of P2.
  • P1 has the social relationship ‘employer’ with respect to P3 and P4.

Relationships within places and organizations are further discussed in the relevant sections below. Relationships between for example organizations and places, or places and persons, may be handled in exactly the same way.

⚓︎14.3.3 Organizational Data

The org and listOrg elements are used to store data about an organization such as its preferred name, its locations, or key persons within it.

  • org (조직) 업무, 종족, 또는 사람들의 다른 종류의 그룹과 같은 식별 가능한 조직에 대한 정보를 제공한다.
  • listOrg (조직 목록) 식별 가능한 조직에 관한 정보를 제공하며, 각각에 대한 기술 목록을 포함한다.

These elements are intended to be used in a way analogous to the place and person elements discussed elsewhere in this chapter, that is to provide a unique wrapper element for information about an entity, distinct from references to that entity which are typically encoded using a naming element such as <name type="org"> or orgName. The content of a naming element will represent the way an organization is named in a given context; the content of an org represents the information known to the encoder about that organization, gathered together in a single place, and independent of its textual realization.

An organization is not the same thing as a list or group of people because it has an identity of its own. That identity may be expressed solely in the existence of a name (for example ‘The Scythians’), but is likely to consist in the combination of that name with a number of events, traits, or states which are considered to apply to the organization itself, rather than any of its members. For example, a sports team might be described in terms of its membership (a listPerson), its fixtures (a listPlace), its geographical affiliation (a placeName), or any combination of these. It will also have properties which may be used to categorize it in some way such as the kind of sport played, whether the team is amateur or professional, and so on: these are probably best dealt with by means of the type attribute. However, it is the name of the sports team alone which identifies it.

The content model for org permits any mixture of generic state, trait, or event elements: the presence of the orgName element described in 14.2.2 Organizational Names is however strongly recommended.

In other respects, the org element is used in much the same way as place or person. An organization may have different names at different times:
<org xml:id="fab4">
 <orgName notAfter="1960">The Silver Beetles</orgName>
 <orgName from="1960-08">The Beatles</orgName>
</org>
The names of the people making up an organization can also change over time, (if they are known at all). For example:
<org xml:id="FAB4">
 <orgName notAfter="1960">The Silver Beetles</orgName>
 <orgName notBefore="1960">The Beatles</orgName>
 <state type="membership" from="1960-08"
  to="1962-05">
  <desc>
   <persName>John Lennon</persName>
   <persName>Paul McCartney</persName>
   <persName>George Harrison</persName>
   <persName>Stuart Sutcliffe</persName>
   <persName>Pete Best</persName>
  </desc>
 </state>
 <state type="membership" notBefore="1963">
  <desc>
   <persName>John Lennon</persName>
   <persName>Paul McCartney</persName>
   <persName>George Harrison</persName>
   <persName>Ringo Starr</persName>
  </desc>
 </state>
</org>
An org may contain subordinate orgs:
<org xml:id="OUCS">
 <orgName>Oxford University Computing Services</orgName>
 <org xml:id="OUCSisg">
  <orgName>Information and Support Group</orgName>
 </org>
 <org xml:id="OUCSig">
  <orgName>Infrastructure Group</orgName>
  <org xml:id="OUCSig.nt">
   <orgName>Networking Team</orgName>
  </org>
  <org xml:id="OUCSig.sdt">
   <orgName>System Development Team</orgName>
  </org>
 </org>
 <org xml:id="OUCSltg">
  <orgName>Learning Technologies Group</orgName>
 </org>
</org>
The following example demonstrates the use of the listOrg element to group together a number of org elements, each of which is defined solely by means of an informal description, itself containing other names.
<p>The TEI institutional hosts are: <listOrg>
  <org xml:id="bu">
   <orgName>Brown University</orgName>
   <desc>The host contribution is made jointly by the <name type="project">Brown University Women Writers
         Project</name> and the <orgName>Brown University Library's Center for Digital Initiatives</orgName>.</desc>
  </org>
  <org xml:id="na">
   <orgName>Nancy</orgName>
   <desc>Hosting is provided by a group of institutions located in Nancy, France, coordinated by
   <orgName>Loria</orgName> and also including <orgName>ATILF</orgName> and <orgName>INIST</orgName>.</desc>
  </org>
  <org xml:id="ou">
   <orgName>Oxford University</orgName>
   <desc>Hosting is provided by the <orgName>Research Technologies Service</orgName> at <orgName>Oxford University
         Computing Services</orgName>.</desc>
  </org>
  <org xml:id="uv">
   <orgName>University of Virginia</orgName>
   <desc>Virginia's host support comes jointly from the <orgName>Institute for Advanced Technology in the
         Humanities</orgName> and the <orgName>University of Virginia Library</orgName>.</desc>
  </org>
 </listOrg>
</p>
In a more elaborated version of this example, the organizational names tagged using orgName might be linked using the key or ref attribute to a unique org element elsewhere.

⚓︎14.3.4 Places

In 14.2.3 Place Names we discuss various ways of naming places such as towns, countries, etc. In much the same way as these Guidelines distinguish between the encoding of names for people and the encoding of other data about people, so they also distinguish between the encoding of names for places and the encoding of other data about places. In this section we present elements which may be used to record in a structured way data about places of any kind which might be named or referenced within a text. Such data may be useful as a way of normalizing or standardizing references to particular places, as the raw material for a gazetteer or similar reference document associated with a particular text or set of texts, or in conjunction with any form of geographical information system.

The following elements are provided for this purpose:

  • listPlace (장소 목록) 장소 목록을 포함하며, 그 뒤에 수의적으로 그들 사이에 정의된 (포함 외의) 관련성 목록을 제시한다.
  • place (place) 지리적 위치에 관한 데이터를 포함한다.

The model.placeStateLike class contains elements describing characteristics of a place which have a definite duration, such as its name. Any member of the model.placeNamePart may be used for this purpose, since a place element will usually contain at least one, and possibly several, placeName-like elements indicating the names associated with it, by different people, in different languages, or at different times.

For example, the modern city of Lyon in France was in Roman times known as Lugdunum. Although the modern and the Roman city are not physically co-extensive, they have significant areas which overlap, and we may therefore wish to regard them as the same place, while supplying both names with an indication of the time period during which each was current.

Places usually have physical locations in addition to names. As with the example of Lyon, the precise geographic location and extent of a place may change over time, and so locations like names may need to be qualified with indications of the time period to which they apply. Locations may be specified in a number of ways: as a set of coordinates defining a point or an area on the surface of the earth, or by providing a description of how the place may be found, usually in terms of other place names. For example, we can identify the location of the Canadian city of London, either by specifying its latitude and longitude, or by specifying that we mean the city called London located in the province called Ontario within the country called Canada.

In addition we may wish to supply a brief characterization of the place identified, for example to state that it is a city, an administrative area such as a country, or a landmark of some kind such as a monument or a battlefield. If our typology of places is simple, the open ended type attribute is the easiest way to represent it: so we might say <place type="city">, <place type="battlefield"> etc.

Within the place element, the following elements may be used to provide more information about specific aspects of the place in a structured form:

  • placeName (place name) 절대적 또는 상대적 위치명을 포함한다.
  • location (location) 다른 이름의 지리-정치적 개체를 통하여 지리적 좌표의 집합으로, 또는 주소로 장소의 위치를 정의한다.
⚓︎14.3.4.1 Varieties of Location

A location may be specified in one or more of the following ways:

  1. by supplying a string representing its coordinates in some standardized way within a geo element, as shown below
  2. by supplying one or more place name component elements (e.g. country, settlement etc.) to place it within a geo-political context
  3. by supplying a postal address, e.g. using the address element
  4. by supplying a brief textual description, e.g. using the desc element
  5. by using a non-TEI XML vocabulary such as the Geography Markup Language

We give examples of all of these methods in the remainder of this section.

The simplest method of specifying a location is by means of its geographic coordinates, supplied within the geo element. This may be used to supply any kind of positional information, using one of the many different geodetic systems available. Such systems vary in their format, in their scope or coverage, and more fundamentally in the reference frame (the ‘datum’) used for the coordinate system itself. The default recommended by these Guidelines is to supply a string containing two real numbers separated by whitespace, of which the first indicates latitude and the second longitude according to the 1984 World Geodetic System (WGS84); this is the system currently used by most GPS applications which TEI users are likely to encounter.55We might therefore record the information about the place known as ‘Lyon’ as follows:
<place xml:id="LYON1" type="city">
 <placeName notBefore="1400">Lyon</placeName>
 <placeName notAfter="0640">Lugdunum</placeName>
 <location>
  <geo>45.769559 4.834843</geo>
 </location>
</place>
Identifying Lyon by its geo-political status as a settlement within a country forming part of a larger political entity, we might represent the same ‘place’ as follows:
<place xml:id="LYON2">
 <placeName notBefore="1400">Lyon</placeName>
 <placeName notAfter="0640">Lugdunum</placeName>
 <location>
  <bloc>EU</bloc>
  <country>France</country>
 </location>
</place>
Elements such as bloc are specialized forms of placeName, as discussed in 14.2.3.1 Geo-political Place Names.
We may use the same procedure to represent the location of smaller places, such as a street or even an individual building:
<place xml:id="BGbldg" type="building">
 <placeName>Brasserie Georges</placeName>
 <location>
  <country key="FR"/>
  <settlement type="city">Lyon</settlement>
  <district type="arrondissement">IIème</district>
  <district type="quartier">Perrache</district>
  <placeName type="street">
   <num>30</num>, Cours de Verdun</placeName>
 </location>
</place>
Note the use of the type attribute to categorize more precisely both the kind of place concerned (a building) and the kind of name used to locate it, for example by characterizing the generic district as an ‘arrondissement’, or a ‘quartier’.
We may also treat imaginary places in the same way:
<place xml:id="Atl" type="imaginary">
 <placeName>Atlantis</placeName>
 <location>
  <offset>beyond</offset>
  <placeName>The Pillars of <persName>Hercules</persName>
  </placeName>
 </location>
</place>
A location sometimes resembles a set of instructions for finding a place:
<place xml:id="MYF">
 <placeName notAfter="1969">Yasgur's Farm</placeName>
 <placeName notBefore="1969">Woodstock Festival Site</placeName>
 <location>
  <measure>one mile</measure>
  <offset>north west of</offset>
  <settlement>Bethel</settlement>
  <region>New York</region>
 </location>
</place>
The element address may also be used to identify a location in terms of its postal or other address:
<place xml:id="locCA" type="cemetery">
 <placeName>Protestant Cemetery</placeName>
 <placeName type="official" xml:lang="it">Cimitero Acattolico</placeName>
 <location type="geopolitical">
  <country>Italy</country>
  <settlement>Rome</settlement>
  <district>Testaccio</district>
 </location>
 <location type="address">
  <address>
   <addrLine>Via Caio Cestio, 6</addrLine>
   <addrLine>00153 Roma</addrLine>
  </address>
 </location>
</place>
When, as here, the same place is given multiple locations, the type attribute should be used to characterize the kind of location, as a means of indicating that these are alternative ways of identifying the same place, rather than that the place is spread across several locations.

The location element may thus identify a place to a greater or lesser degree of precision, using a variety of means: a name, a set of names, or a set of coordinates. The geo element introduced earlier is by default understood to supply a value expressed in a specific (and widely used) notation. If a location contains more than one geo, this is interpreted as being really the same place in the universe, but with different systems used to refer to it. If there is a lack of consensus about the location (of, for example, Camelot), more than one location should be used, each with its own geo.

By default, the content of geo is interpreted as following the standard known as the World Geodetic System (WGS). This may be modified, however, in two ways.

Firstly, the content of the geo element can be expressed some other way, that is, according to some different geodetic system. The decls attribute is used point to a geoDecl element defined in the document header, which describes a different datum.

Secondly, the element geo may be redefined to contain markup from a different XML vocabulary which is specifically designed to represent this kind of information. This technique is used throughout these Guidelines where specialized markup is required, for example to embed mathematical expressions or vector graphics, and is further described and exemplified in 24.3.4 Examples of Modification . For geographic information, suitable non-TEI vocabularies include:

  • the OpenGIS Geography Markup Language (GML) being defined by the OGC56
  • the Keyhole Markup Language (KML) used by Google Maps57
In the following example, we have defined the location of the place ‘Lyon’ using GML and indicated the two names associated with it at different times:
<place xml:id="locLyon" type="city">
 <placeName notBefore="1400">Lyon</placeName>
 <placeName notAfter="0640">Lugdunum</placeName>
 <location>
  <geo>
   <gml:Polygon>
    <gml:exterior>
     <gml:LinearRing> 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8 -109.2 45.256 -110.45 </gml:LinearRing>
    </gml:exterior>
   </gml:Polygon>
  </geo>
 </location>
</place>

A bibl element may be used within location to indicate the source of the location information.

<location>
 <geo>53.226658 -0.541254</geo>
 <bibl>
  <title>Roman Inscriptions of Britain</title>, <idno>262</idno>
 </bibl>
</location>
⚓︎14.3.4.2 Multiple Places
A place may contain other places. This containment relation can be directly modelled in XML: thus we can say that the towns of Vilnius and Kaunas are both in a place called Lithuania (or Lietuva) as follows:
<place xml:id="locLith">
 <country>Lithuania</country>
 <country xml:lang="lt">Lietuva</country>
 <place>
  <settlement>Vilnius</settlement>
 </place>
 <place>
  <settlement>Kaunas</settlement>
 </place>
</place>

This does not, of course, imply that Vilnius and Kaunas are the only places constituting Lithuania; only that they are within it. A separate place element may indicate that it is a part of Lithuania by supplying a relation element, as discussed below (14.3.4.4 Relations Between Places).

As a further example, the islands of Mauritius, Réunion, and Rodrigues are collectively known as the Mascarene Islands. Grouped together with Mauritius there are also several smaller offshore islands, with rather picturesque French names. These offshore islands do not however constitute an identifiable place as a whole. One way of representing this is as follows:
<place xml:id="locMascarenes"
 type="islandGroup">
 <placeName>Mascarene Islands</placeName>
 <placeName>Mascarenhas Archipelago</placeName>
 <place type="island">
  <placeName>Mauritius</placeName>
  <listPlace type="offshoreIslands">
   <place>
    <placeName>La roche qui pleure</placeName>
   </place>
   <place>
    <placeName>Île aux cerfs</placeName>
   </place>
  </listPlace>
 </place>
 <place type="island">
  <placeName>Rodrigues</placeName>
 </place>
 <place type="island">
  <placeName>Réunion</placeName>
 </place>
</place>
Here is a more complex example, showing the variety of names associated at different times and in different languages with a set of hierarchically grouped places—the settlement of Carmarthen Castle, within the town of Carmarthen, within the administrative county of Carmarthenshire, Wales.
<place xml:id="wales" type="country">
 <placeName xml:lang="cy">Cymru</placeName>
 <placeName xml:lang="en">Wales</placeName>
 <placeName xml:lang="la">Wallie</placeName>
 <placeName xml:lang="la">Wallia</placeName>
 <placeName xml:lang="fro">Le Waleis</placeName>
 <place xml:id="carmarthenshire"
  type="region">
  <region type="county" xml:lang="en"
   notBefore="1284">Carmarthenshire</region>
  <place xml:id="carmarthen"
   type="settlement">
   <placeName xml:lang="en">Carmarthen</placeName>
   <placeName xml:lang="la"
    notBefore="1090" notAfter="1300">Kaermerdin</placeName>
   <placeName xml:lang="cy">Caerfyrddin</placeName>
   <place xml:id="carmarthen_castle"
    type="castle">
    <settlement>castle of Carmarthen</settlement>
   </place>
  </place>
 </place>
</place>

As noted previously, country, region, and settlement are all specializations of the generic placeName element; they are not specializations of the place element. If it is desired to distinguish amongst kinds of place this can only be done by means of the type attribute as in the above example.

This use of multiple place elements should be distinguished from the (possibly simpler) case where a number of places with some property in common are being grouped together for convenience, for example, in a gazetteer. The listPlace element is provided as a means of grouping places together where there is no implication that the grouped elements constitute a distinct place. For example:
<place xml:id="pl-c-H" type="county">
 <placeName>Herefordshire</placeName>
 <listPlace type="villages">
  <place xml:id="pl-v-AD">
   <placeName>Abbey Dore</placeName>
   <location>
    <geo>51.969604 -2.893146</geo>
   </location>
  </place>
  <place xml:id="pl-v-AB">
   <placeName>Acton Beauchamp</placeName>
  </place>
<!-- ... -->
 </listPlace>
 <listPlace type="towns">
  <place xml:id="pl-t-H">
   <placeName>Hereford</placeName>
  </place>
  <place xml:id="pl-t-L">
   <placeName>Leominster</placeName>
  </place>
<!-- ... -->
 </listPlace>
</place>
⚓︎14.3.4.3 States, Traits, and Events

There are many different kinds of information which it might be considered useful to record for a place in addition to its name and location, and the categories selected are likely to be very project-specific. As with persons therefore these Guidelines make no claim to comprehensiveness in this context. Instead, the generic state, trait, and event elements defined by this module should be used. Each of these may be customized for particular needs by means of their type attribute. These are complemented by a small number of predefined elements of general utility:

  • population (population) 장소의 인구에 관한 정보를 포함한다.
  • climate (climate) 장소의 기후에 관한 정보를 포함한다.
  • terrain (terrain) 장소의 물리적 지역에 대한 정보를 포함한다.

These are all specializations of the generic trait element. This element may be used for almost any kind of event in the life of a place; no specialized version of this element is proposed, nor do we attempt to enumerate the possible values which might be appropriate for the type attribute on any of these generic elements.

Here is an example, showing how the specific and generic elements may be combined:
<place xml:id="IS">
 <placeName xml:lang="en">Iceland</placeName>
 <placeName xml:lang="is">Ísland</placeName>
 <location>
  <geo>65.00 -18.00</geo>
 </location>
 <terrain>
  <desc>Area: 103,000 sq km</desc>
 </terrain>
 <state type="governance" notBefore="1944">
  <p>Constitutional republic</p>
 </state>
 <state type="governance" notAfter="1944">
  <p>Part of the kingdom of <placeName key="DK">Denmark</placeName>
  </p>
 </state>
 <event type="governance" when="1944-06-17">
  <desc>Iceland became independent on 17 June 1944.</desc>
 </event>
 <state type="governance" from="1944-06-17">
  <p>An independent republic since June 1944</p>
 </state>
</place>
In the following example, the climate example is used to provided a detailed discussion of this particular aspect of the information available about a particular place:
<place xml:id="greece">
 <placeName>Greece</placeName>
 <climate>
  <desc>Greece's climate is divided into three well defined classes:</desc>
  <climate>
   <label>Mediterranean</label>
   <desc>It features mild, wet winters and hot, dry summers. Temperatures rarely reach extremes, although snowfalls
       do occur occasionally even in <placeName>Athens</placeName>, <placeName>Cyclades</placeName> or
   <placeName>Crete</placeName> during the winter.</desc>
  </climate>
  <climate>
   <label>Alpine</label>
   <desc>It is found primarily in <placeName>
     <offset>Western</offset> Greece</placeName>
       (<placeName>Epirus</placeName>, <placeName>
     <offset>Central</offset> Greece</placeName>,
   <placeName>Thessaly</placeName>, <placeName>
     <offset>Western</offset> Macedonia</placeName> as well as
       central parts of <placeName>Peloponnesus</placeName> like <placeName>Achaea</placeName>,
   <placeName>Arcadia</placeName> and parts of <placeName>Laconia</placeName> where the Alpine range pass
       by)</desc>
  </climate>
  <climate>
   <label>Temperate</label>
   <desc>It is found in <placeName>
     <offset>Central</offset> and <offset>Eastern</offset> Macedonia</placeName> as
       well as in <placeName>Thrace</placeName> at places like <placeName>Komotini</placeName>,
   <placeName>Xanthi</placeName> and <placeName>
     <offset>northern</offset> Evros</placeName>. It features cold,
       damp winters and hot, dry summers.</desc>
  </climate>
 </climate>
</place>
As the above example shows, state and trait elements, and others of the same class, can be nested hierarchically within each other. When this is done, values for the type attribute are to be understood as cumulatively inherited, as elsewhere in the TEI scheme (for example on category or linkGrp). In the following example, the outermost population element concerns the squirrel population between the dates given. This is then broken down into red and gray squirrel populations, and within that into male and female:
<population type="squirrel"
 notBefore="1901" notAfter="1902-01-11" resp="#strabo">
 <population type="red" when="1901-01-10">
  <population type="female">
   <desc>12</desc>
  </population>
  <population type="male">
   <desc>15</desc>
  </population>
 </population>
 <population type="gray" when="1902-01-10"
  cert="high">
  <population type="female">
   <desc>23</desc>
  </population>
  <population type="male" cert="low"
   resp="#biber">
   <desc>45</desc>
  </population>
 </population>
</population>
The dating and responsibility attributes here behave slightly differently from the type attribute: responsibility is not an additive property, and therefore an element either states it explicitly, or inherits it from its nearest ancestor. Dating is slightly different again, in that a child element may specify a date more precisely than its parent, as in the example above.

An event may be related to other named entities, and thus may appear within an org, person, personGrp, persona, or place element as well as within a listEvent or another event.

⚓︎14.3.4.4 Relations Between Places
The relation element may also be used to express relationships of various kinds between places, or between places and persons, in much the same way as it is used to express relationships between persons alone. Returning to the Mascarene Islands example cited above, we might define the island group and its constituents separately, but indicate the relationship by means of a relation element:
<listPlace>
 <place xml:id="MASC">
  <placeName>Mascarene islands</placeName>
  <placeName>Mascarenhas Archipelago</placeName>
 </place>
 <place xml:id="MRU">
  <placeName>Mauritius</placeName>
<!-- ... -->
 </place>
 <place xml:id="ROD">
  <placeName>Rodrigues</placeName>
 </place>
 <place xml:id="REN">
  <placeName>Réunion</placeName>
 </place>
 <relation name="contains" active="#MASC"
  passive="#ROD #MRU #REN"/>
</listPlace>
This ‘stand-off’ style of representation has the advantage that we can now also represent the fact that a place may be a ‘part of’ more than one other place; for example, Réunion is part of France, as well as part of the Mascarenes. If we add a declaration for France to the list above:
<place type="country" xml:id="FRA">
 <placeName>France</placeName>
</place>
we can now model this dual allegiance by means of a relation element:
<relation name="partOf" active="#REN"
 passive="#FRA #MASC"/>

⚓︎14.3.5 Events

  • event (event) 개인, 장소, 또는 조직과 관련된 중요한 사건에 해당하는 데이터를 포함한다.
  • eventName (name of an event) contains a proper noun or noun phrase used to refer to an event.
  • listEvent (list of events) contains a list of descriptions, each of which provides information about an identifiable event.

An event is a change of state whether real, planned, fictional, or purported about which more information is known. The eventName element may be used to encode the proper name of an event, if known. The head or label element may also appear in event, either in lieu of or in addition to the eventName element, to provide a human-readable heading or editorially supplied label for the event.

These guidelines do not prescribe what encoders count as events, nor their granularity, nesting, or amount of other information to record in relation to each event. Yet most events can be identified by their time, location, or agents involved (be they organizations, persons, or objects).

An event element may be used to record information about a place, person, or organization related to the described event; for this reason the element may appear as content of a place, person, or org. However, it is also possible to describe events independently of either a place, person, or organization. This may be useful not only for encoding texts which describe named events and their eventNames, but also in applications as chronologies or lists of significant events (e.g., important battles, legislative milestones, or the stages of construction of a large building, etc.).

The listEvent element is a member of the model.listLike class, and may therefore appear inside standOff, or wherever else lists are permitted, in the same way as the listPerson, listPlace, listOrg etc. elements described elsewhere in this chapter.

<standOff>
 <listEvent>
  <event when="1713"
   ref="https://www.canadiana.ca/view/oocihm.9_01832/2">
   <label>Treaty of Utrecht</label>
<!-- The following example presupposes that the editors of the TEI document decided to understand legislation or a treaty as an <gi>event</gi>, which itself may be considered a shortcut for several events that led up to the existence or validity of the law or treaty (e.g. the signing of a treaty could also be modeled as an event, and the result on paper could be encoded as an <gi>object</gi> or <gi>bibl</gi>). -->
   <desc>France ceded to Great Britain its claims to the <orgName>Hudson's Bay Company</orgName> territories in
   <placeName>Rupert's Land</placeName>, <placeName>Newfoundland</placeName>, and <placeName>Acadia</placeName> and
       recognized British suzerainty over <orgName type="tribe">the Iroquois</orgName> but retained its other pre-war
       North American possessions, including
   <placeName key="PEI">Île-Saint-Jean</placeName>
       (now <placeName key="PEI">Prince Edward Island</placeName>)...</desc>
  </event>
  <event when="1774" key="14-GeoIII-c83">
   <label>Quebec Act</label>
   <desc>This act of the British Parliament guaranteed free practice of the Catholic faith and restored use of the
       French Civil Code for private matters throughout the Province of Quebec, which had been expanded in territory
       following the <ref>Treaty of Paris</ref>.</desc>
  </event>
  <event when="1778"
   ref="http://avalon.law.yale.edu/18th_century/del1778.asp">
   <label>Treaty of Fort Pitt</label>
   <desc>Also known as the <name type="event">Treaty with the Delawares</name>, this was the first written treaty
       between the newly formed <orgName>United States</orgName> and any Native American people, in this case, the
   <orgName type="tribe">Lenape</orgName> or Delawares.</desc>
  </event>
 </listEvent>
</standOff>

The next example demonstrates the use of the where attribute with event, coordinated with location information stored in listPlace.

<standOff>
<!-- ========= events ========= -->
 <listEvent>
  <event xml:id="DB-3F" where="#WWIIEast"
   when="1942-01">
   <head>Luftwaffe shoots down Ilyushin Il-4</head>
   <head type="short">DB-3F</head>
   <ab type="altitude">
    <measure unit="m" quantity="7000"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-IC">Іван Чиссов</persName>
   </ab>
  </event>
  <event xml:id="SCP" where="#l-GSN"
   when="1943-01-03">
   <head>Snap, Crackle, Pop is shot down by German flak</head>
   <head type="short">B-17</head>
   <ab type="altitude">
    <measure unit="m" quantity="6700"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-AM">Alan Magee</persName>
   </ab>
  </event>
  <event xml:id="DS664" where="#l-Obe"
   when="1944-03-24">
   <head>Avro Lancaster shot down by Junkers Ju 88</head>
   <head type="short">Lancaster</head>
   <ab type="altitude">
    <measure unit="m" quantity="5490"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-NA">Nicholas Alkemade</persName>
   </ab>
  </event>
  <event xml:id="LANSA508" where="#l-PI"
   when="1971-12-04">
   <head>LANSA 508 struck by lightning</head>
   <head type="short">Amazon rainforest</head>
   <ab type="altitude">
    <measure unit="m" quantity="3000"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-JK">Juliane Diller (née Koepcke)</persName>
   </ab>
  </event>
  <event xml:id="jat367" where="#l-Seb"
   when="1972-01-26T16:01:29Z">
   <head>Bombing of Yugoslav Airlines Flight 367</head>
   <head type="short">JAT 367</head>
   <ab type="altitude">
    <measure unit="m" quantity="10050"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-VV">Весна Вуловић</persName>
   </ab>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/JAT_Flight_367"/>
  </event>
  <event xml:id="BG" where="#l-KorZ"
   when="1996">
   <head>SAS parachute failure</head>
   <head type="short">Bear Grylls</head>
   <ab type="altitude">
    <measure unit="m" quantity="4877"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-BG"/>
   </ab>
  </event>
  <event xml:id="CM" where="#l-Joh"
   when="2004-08-22">
   <head>Johannesburg parachute failure</head>
   <head type="short">Christine McKenzie</head>
   <ab type="altitude">
    <measure unit="m" quantity="3353"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-CM">Christine McKenzie</persName>
   </ab>
  </event>
  <event xml:id="JBK" where="#l-Kam"
   when="2009-05">
   <head>Cameraman fails to open chute</head>
   <head type="short">Sport videographer</head>
   <ab type="altitude">
    <measure unit="m" quantity="1829"/>
   </ab>
   <ab type="survivor">
    <persName ref="#p-JB"/>
   </ab>
  </event>
 </listEvent>
<!-- ========= places ========= -->
 <listPlace>
  <place xml:id="l-GSN">
   <placeName xml:lang="fr">Gare de Saint-Nazaire</placeName>
   <location>
    <geo>47.28657 -2.21171</geo>
   </location>
  </place>
  <place xml:id="l-Joh">
   <placeName>Johannesburg</placeName>
   <location>
    <country>South Africa</country>
    <region type="province">Gauteng</region>
   </location>
  </place>
  <place xml:id="l-Kam">
   <placeName xml:lang="ru">Камчатке</placeName>
   <location>
    <country>Russia</country>
    <region>Kamchatka Krai</region>
   </location>
  </place>
  <place xml:id="l-Ken">
   <country>Kenya</country>
  </place>
  <place xml:id="l-Obe" xml:lang="de">
   <placeName>Oberkirchen</placeName>
   <location>
    <country>Deutschland</country>
    <region type="state">Nordrhein-Westfalen</region>
    <region>Arnsberg</region>
    <district>Hochsauerlandkreis</district>
    <settlement>Schmallenberg</settlement>
    <geo cert="low">51.154 8.357</geo>
   </location>
  </place>
  <place xml:id="l-PI" xml:lang="es">
   <placeName>Puerto Inca</placeName>
   <location>
    <country>Peru</country>
    <region>Huánuco</region>
    <district>Puerto Inca</district>
   </location>
  </place>
  <place xml:id="l-Sch">
   <placeName xml:lang="de">Schmallenberg</placeName>
   <placeName xml:lang="wep">Smalmereg</placeName>
   <location/>
  </place>
  <place xml:id="l-Seb">
   <placeName xml:lang="de">Sebnitz</placeName>
   <location>
    <geo>50.966667 14.283333</geo>
   </location>
  </place>
  <place xml:id="l-WWIIEast">
   <name>Eastern Front</name>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Eastern_Front_(World_War_II)"/>
  </place>
  <place xml:id="l-Zam">
   <country>Zambia</country>
  </place>
 </listPlace>
<!-- ========= people ========= -->
 <listPerson>
  <person xml:id="p-VV">
   <persName xml:lang="sr-Cyrl">Весна Вуловић</persName>
   <persName xml:lang="sr-Latn">Vesna Vulović</persName>
   <birth when="1950-01-03"/>
   <death when="2016-12-23"/>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Vesna_Vulovi%C4%87"/>
  </person>
  <person xml:id="p-IC">
   <persName xml:lang="uk-Cyrl">Іван Михайлович Чиссов</persName>
   <persName xml:lang="ru-Cyrl">Иван Михайлович Чисов</persName>
   <persName xml:lang="uk-Latn">Ivan Mikhailovich Chisov</persName>
   <birth when="1916"/>
   <death when="1986"/>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Ivan_Chisov"/>
  </person>
  <person xml:id="p-AM">
   <persName>Alan Eugene Magee</persName>
   <birth when="1919-01-13"/>
   <death when="2003-12-20"/>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Alan_Magee"/>
  </person>
  <person xml:id="p-NA">
   <persName>Nicholas Stephen Alkemade</persName>
   <birth when="1922-12-10"/>
   <death when="1987-06-22"/>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Nicholas_Alkemade"/>
  </person>
  <person xml:id="p-BG">
   <persName>Edward Michael Grylls</persName>
   <birth when="1974-06-07"/>
   <ptr type="furtherInfo"
    target="https://www.beargrylls.com/pages/about-bear-grylls"/>
  </person>
  <person xml:id="p-JK">
   <persName>Juliane Koepcke</persName>
   <birth when="1954-10-10"/>
   <ptr type="furtherInfo"
    target="https://en.wikipedia.org/wiki/Juliane_Koepcke"/>
  </person>
  <person xml:id="p-JB">
   <persName>James Boole</persName>
   <birth>1978, give or take a year</birth>
   <ptr type="furtherInfo"
    target="https://www.facebook.com/james.boole/?ref=page_internal"/>
  </person>
 </listPerson>
<!-- ========= conjunctions and disjunctions ========= -->
 <altGrp type="location">
  <alt xml:id="l-KorZ"
   target="#l-Ken #l-Zam"/>
 </altGrp>
</standOff>

The where attribute on event can point to multiple canonical place descriptions, which indicates that an event took place in multiple locations. For example, the November 2015 Paris Attacks took place at six different locations in Paris; this might be encoded as an event with a where attribute with six space-separated values, or using a listPlace (nested into the event or standalone).

Events may also be modeled as hierarchies of nested events. For example, a two part meeting might be represented as follows:
<event type="meeting" when="2007-05-29">
 <desc>All day meeting to resolve content models</desc>
 <event type="preamble" notAfter="13:00:00">
  <desc>first part</desc>
 </event>
 <event type="conclusions"
  notBefore="13:00:00">
  <desc>second part</desc>
 </event>
</event>

For event as a child element of person, note the Section 14.3.2.2 Personal Events.

⚓︎14.3.6 Objects

  • object contains a description of a single identifiable physical object.
  • objectName (name of an object) contains a proper noun or noun phrase used to refer to an object.
  • listObject (list of objects) contains a list of descriptions, each of which provides information about an identifiable physical object.

An object is any material thing whether real, in existence, fictional, missing, or purported about which more information is known. Where objects have proper names the objectName element may be used to encode these. However, many objects are not named but the object element may still be used to provide a description of them. The object element is a more general descriptive form of the msDesc element. The latter should be used for describing manuscripts and similar text-bearing objects but can be viewed as a more specific form of the object element.

Please note: The object element is a recent addition to TEI P5 Guidelines as of version 3.5.0 and as such might be more prone to further revision in the next few releases as its use develops. This may be particularly evident where its contents have been borrowed from msDesc and have yet to be generalized from their use in the context of manuscript descriptions.

The object element usually appears inside the listObject element which is used to group descriptions of identifiable objects. The listObject element is a member of model.listLike and so may appear inside standOff, or anywhere else that list is allowed. This enables the flexibility of using listObject to contain a set of metadata descriptions stored in the TEI header, or as a list of objects transcribed from a source document. The equivalent list for manuscript descriptions is listBibl.

  • objectIdentifier (object identifier) groups one or more identifiers or pieces of locating information concerning a single object.
  • msContents (원고 내용) 일련의 문단으로 또는 일련의 구조화된 원고 항목으로 원고 또는 원고 일부의 지적 내용을 기술한다.
  • physDesc (물리적 기술) model.physDescPart 클래스에서 더 특별화된 요소로 사용하기 위해 수의적으로 더 세분화한 원고 또는 원고 일부에 대한 완전한 물리적 기술을 포함한다.
  • history (history) 원고 또는 원고 일부의 전체 이력을 기술하는 요소를 모아 놓는다.
  • additional (additional) 원고 또는 원고의 사본에 관한 서지 정보와 관리 정보를 결합한 부가적 정보를 모아 놓는다.

Overall, the basic structure of an object element is akin to that of msDesc in that it is providing a structured description of an object. After a group of identifying information, it has the option of paragraphs or, if the msdescription module is loaded, msContents, physDesc, history, and additional elements for descriptive metadata about this object. Although these elements originate from manuscript description the object element may be used for all forms of object (whether text-bearing or not). Where descendents of object still have the hallmarks of their use in manuscript description, the descriptions as relating to manuscripts should be interpreted as applying to all forms of object (text-bearing) or not.

The objectIdentifier element is a general-purpose grouping element for location or identification information relating to a single object or resource. It is very similar to an msIdentifier element with less contraints on the order of its contents. The objectIdentifier may be more or less detailed dependent on the needs of the encoder. In some cases an object may be used mostly as a common reference point for multiple objectName elements to refer back to. In situations, one might provide more detailed information in the objectIdentifier where it is available or desirable. Compare
<object xml:id="Excalibur-shortIdentifier">
 <objectIdentifier>
  <objectName>Excalibur</objectName>
 </objectIdentifier>
 <p>Excalibur is the name for the legendary sword of King Arthur.</p>
</object>
where only a single objectName is provided and below where multiple versions are provided.
<object xml:id="Excalibur-longerIdentifier">
 <objectIdentifier>
  <objectName type="main">Excalibur</objectName>
  <objectName type="alt">Caliburn</objectName>
  <objectName xml:lang="cy">Caledfwlch</objectName>
  <objectName xml:lang="cnx">Calesvol</objectName>
  <objectName xml:lang="br">Kaledvoulc'h</objectName>
  <objectName xml:lang="la">Caliburnus</objectName>
  <country>Wales</country>
 </objectIdentifier>
 <p>Excalibur is the main English name for the legendary
   sword of King Arthur. In Welsh it is called
 <mentioned>Caledfwlch</mentioned>, in Cornish it is called
 <mentioned>Calesvol</mentioned>, in Breton it is called
 <mentioned>Kaledvoulc'h</mentioned>, and in Latin it is
   called <mentioned>Caliburnus</mentioned>. In some versions
   of the legend, Excalibur’s blade was engraved with phrases on opposite
   sides: <q>Take me up</q> and <q>Cast me away</q> (or similar).</p>
</object>
Moreover, the objectIdentifier may include an address element to provide the address at which the object currently resides. The use of location within this enables the provision of geographical coordinates when describing objects not housed in traditional repositories or institutions. This may also be used to supplement more traditional repository location information if available and, for example, to enable providing outputs such as maps showing the location of encoded objects.
<objectIdentifier>
 <objectName xml:lang="en">Mask of Tutankhamun</objectName>
 <idno type="carter">256a</idno>
 <idno type="JournalD'Entrée">60672</idno>
 <idno type="exhibition">220</idno>
 <institution>Museum of Egyptian Antiquities</institution>
 <address>
  <street>15 Meret Basha</street>
  <district>Ismailia</district>
  <settlement>Cairo</settlement>
  <country>Egypt</country>
  <location>
   <geo>30.047778 31.233333</geo>
  </location>
 </address>
</objectIdentifier>
The msContents element is currently used to provide a description of the intellectual contents of any text on an object and, being optional, is not necessary if there are no intellectual contents to describe. (Such contents, especially in the case of artistic objects, may not always be textual.) The physDesc element may be used to give a physical description of the object either in prose or using more structured elements as and where they apply to that kind of object. The history element provides the option to describe the history of the object as paragraphs or with more structure using the origin element, as many provenance stages as are appropriate, and acquisition to describe its current ownership. The additional element may be used to provide information about surrogates for the object (such as digital facsimiles) as well as administrative and curatorial information. A full description of an object can provide more or less detail at any level to represent the state of knowledge about the object.
<listObject>
 <object xml:id="TutankhamunMask">
  <objectIdentifier>
   <objectName xml:lang="en">Mask of Tutankhamun</objectName>
   <idno type="carter">256a</idno>
   <idno type="JournalD'Entrée">60672</idno>
   <idno type="exhibition">220</idno>
   <institution>Museum of Egyptian Antiquities</institution>
   <address>
    <street>15 Meret Basha</street>
    <district>Ismailia</district>
    <settlement>Cairo</settlement>
    <country>Egypt</country>
    <location>
     <geo>30.047778 31.233333</geo>
    </location>
   </address>
  </objectIdentifier>
  <msContents>
   <p>The back and shoulders of the mask is inscribed with a protective spell in Egyptian hieroglyphs formed of ten
       vertical and horizontal lines. This spell first appeared on masks in the Middle Kingdom at least 500 years
       before Tutankhamun, and comes from chapter 151 of the <title>Book of the Dead</title>.</p>
  </msContents>
  <physDesc>
   <p>The mask of Tutankhamun is 54cm x 39.3cm x 49cm. It is constructed from two layers of high-karat gold that
       varies in thickness from 1.5-3mm. It weighs approximately 10.23kg and x-ray crystallography shows that it is
       composed of two alloys of gold with a lighter 18.4 karat shade being used for the face and neck while a heavier
       22.5 karat gold was used for the rest of the mask.</p>
   <p>In the mask Tutankhamun wears a nemes headcloth which has the royal insignia of a cobra (Wadjet) and vulture
       (Nekhbet) on it. These are thought respectively to symbolize Tutankhamun's rule of both Lower Egypt and Upper
       Egypt. His ears are pierced for earrings. The mask has rich inlays of coloured glass and gemstones, including
       lapis lazuli surrounding the eye and eyebrows, quartz for the eyes, obsidian for the pupils. The broad collar is
       made up of carnelian, feldspar, turquoise, amazonite, faience and other stones.</p>
  </physDesc>
  <history>
   <origin>
    <p>The mask of Tutankhamun was created in <origPlace>Egypt</origPlace> around <origDate when="-1323" type="circa">1323 BC</origDate>. It is a death mask of the 18th-dynasty ancient Egyptian Pharaoh Tutankhamun
         who reigned 1332–1323 BC.</p>
   </origin>
   <provenance>
    <p>The mask of Tutankhamun was found in his burial chamber at Theban Necropolis in the Valley of the Kings in
         1922. On 28 October 1925 the excavation team led by English archaeologist Howard Carter opened the heavy
         sarcophagus and three coffins and were the first people in around 3,250 years to see the mask of Tutankhamun.
         Carter wrote in his diary: <quote> The pins removed, the lid was raised. The penultimate scene was disclosed –
           a very neatly wrapped mummy of the young king, with golden mask of sad but tranquil expression, symbolizing
           Osiris … the mask bears that god's attributes, but the likeness is that of Tut.Ankh.Amen – placid and
           beautiful, with the same features as we find upon his statues and coffins. The mask has fallen slightly
           back, thus its gaze is straight up to the heavens. </quote>
    </p>
   </provenance>
   <acquisition> In December 1925, the mask was removed from the tomb, placed in a crate and transported 635
       kilometres (395 mi) to the Egyptian Museum in Cairo, where it remains on public display. </acquisition>
  </history>
  <additional>
   <adminInfo>
    <custodialHist>
     <custEvent when="1944">When it was discovered in 1925, the 2.5kg narrow gold beard was no longer attached to
           the mask and was reattached to the chin by use of a wooden dowel in 1944.</custEvent>
     <custEvent when="2014-08"> In August 2014 when the mask was removed from its display case for cleaning, the
           beard fell off again. Those working in the museum unadvisedly used a quick-drying epoxy to attempt to fix
           it, but left the beard off-centre. </custEvent>
     <custEvent when="2015-01">The damage was noticed and repaired in January 2015 by a German-Egyptian team who
           used beeswax, a material known to be used as adhesives by the ancient Egyptians.</custEvent>
    </custodialHist>
   </adminInfo>
  </additional>
 </object>
</listObject>
If the object is being referenced from elsewhere in the document, this is usually done with an objectName. For example here the Alfred-Jewel xml:id is referenced from a paragraph elsewhere in the document using the ref attribute on the objectName element.

<!-- Inside <standOff>: --><listObject>
 <object xml:id="Alfred-Jewel">
  <objectIdentifier>
   <country>United Kingdom</country>
   <region>Oxfordshire</region>
   <settlement>Oxford</settlement>
   <institution>University of Oxford</institution>
   <repository>Ashmolean Museum</repository>
   <collection>English Treasures</collection>
   <idno type="ashmolean">AN1836p.135.371</idno>
   <idno type="wikipedia">https://en.wikipedia.org/wiki/Alfred_Jewel</idno>
   <objectName>Alfred Jewel</objectName>
  </objectIdentifier>
  <physDesc>
   <p>The Alfred Jewel is about 6.4 cm in length and is made of combination of filigreed <material>gold</material>
       surrounding a polished teardrop shaped piece of transparent <material>quartz</material>. Underneath the rock
       crystal is a cloisonné enamel image of a man with ecclesiastical symbols. The sides of the jewel holding the
       crystal in place contain an openwork inscription saying "AELFRED MEC HEHT GEWYRCAN", meaning 'Alfred ordered me
       made'.</p>
  </physDesc>
  <history>
   <origin>It is generally accepted that the Alfred Jewel dates from the <origDate>late 9th Century</origDate> and
       was most likely made in <origPlace>England</origPlace>. </origin>
   <provenance when="1693">The jewel was discovered in 1693 at Petherton Park, North Petherton in the English county
       of Somerset, on land owned by Sir Thomas Wroth. North Petherton is about 8 miles away from Athelney, where King
       Alfred founded a monastery. </provenance>
   <provenance when="1698">A description of the Alfred Jewel was first published in 1698, in the Philosophical
       Transactions of the Royal Society.</provenance>
   <acquisition> It was bequeathed to Oxford University by Colonel Nathaniel Palmer (c. 1661-1718) and today is in
       the Ashmolean Museum in Oxford. </acquisition>
  </history>
 </object>
</listObject>
<!-- Inside <text>: -->
<p> The <objectName ref="#MinsterLovellJewel">Minster Lovell Jewel</objectName> is probably the most similar to the
<objectName ref="#Alfred-Jewel">Alfred Jewel</objectName> and was found in <placeName ref="#MinsterLovell">Minster
   Lovell</placeName> in <placeName ref="#Oxfordshire">Oxfordshire</placeName> and is kept at the <orgName ref="#AshmoleanMuseum">Ashmolean Museum</orgName>.
</p>

There is no restriction on the form, size, or type of object that may be described by an object element, however, some objects may be more adequately described by a place element depending on context. Where a description of an object is being provided in terms of identification, physical characteristics, or history, then an object element may be preferred. Where metadata is being recorded about the geo-political location, population, or similar traits, then the place element may be better suited. A corresponding relation between an object description and place may be recorded through the use of the corresp attribute. An example of a large object that might be described with the object element could be a building such as the Central Library of the National Autonomous University of Mexico.

<object type="building" xml:lang="en"
 xml:id="UNAM-CL">
 <objectIdentifier>
  <objectName type="abbr">The Central Library of UNAM</objectName>
  <objectName type="full">The Central Library of the National Autonomous University of Mexico</objectName>
  <objectName xml:lang="es">La Biblioteca Central de la Universidad Nacional Autónoma de México</objectName>
  <settlement>Mexico City</settlement>
  <region>Coyoacán</region>
  <country>Mexico</country>
 </objectIdentifier>
 <physDesc>
  <objectDesc>
   <p>The Central Library encompasses an area of <dim unit="m" quantity="16000"
     type="area">16 thousand square
         meters</dim> and is built on a three meter platform. The base contains two <material>basalt</material>
    <objectType>fountains</objectType> and <objectType>decorative reliefs</objectType> inspired by
       pre-Hispanic art.</p>
   <p>The library has ten windowless floors for book storage, each having enough space for 120 thousand volumes.
       These storage areas have the necessary lighting, temperature and humidty conditions for book conservation.
       In the reading room, flanked by a garden on each side, the diffuse and matte light is filtered through
   <material>thin tecali stone slabs</material>. The semi-basement of the building contains the service
       and administrative offices of the library.</p>
   <p>The building facades are covered with one of the largest murals in the world and is made from naturally
       colored stone tiles. It is entitled <title>Historical Representation of Culture</title> and is by
   <persName role="artist">Juan O'Gorman</persName>.</p>
  </objectDesc>
  <decoDesc>
   <decoNote>
    <label>Base</label> At the base of the building there are two basalt fountains and decorative reliefs
       around the outside that are inspired by pre-Hispanic art. The color of the stone in these elements is left
       exposed to take advantage of the stone's texture as an aesthetic and expressive element, and to give a
       sense of continuity to the external pavement.</decoNote>
   <decoNote>
    <label>Murals</label>
    <p>The outside windowless portion of the building contains one of the largest murals in the world. This is
         called <title>Historical Representation of the Culture</title> and is a <material>stone polychromatic
           mosaic</material> based on the combination of 12 basic colors. The mural is created in an
         impressionist style where the coloured tiles when seen from a distance form specific figures. The 12
         colors where chosen from 150 samples of original stones with the criteria including the stone's
         resistance to degredation by weather. According to the artist, <persName role="artist">Juan
           O'Gorman</persName>, in the mosaic he represented three fundamental historical facets of the Mexican
         culture: the pre-Hispanic era, the Spanish colonial era, and the modern age. For example with the North
         Wall, this represents the pre-Hispanic era and is dominated by mythical elements relating to the
         life-death duality. The left side of the main axis there are
         deities and scenes pertaining to the creation of life. The right hand side of the mural contains figures
         relating to death. For a more detailed description see <ref target="https://en.wikipedia.org/wiki/Central_Library_(UNAM)#Murals">https://en.wikipedia.org/wiki/Central_Library_(UNAM)#Murals</ref>.</p>
   </decoNote>
  </decoDesc>
 </physDesc>
 <history>
  <origin> In <origDate when="1948" type="conceptual">1948</origDate> the architect and artist Juan O'Gorman, in
     collaboration with architects Gustavo Saavedra and Juan Martinez de Velasco designed the building with a
     functionalist approach, as part of the greater project of the construction of the University City on the
     grounds of the Pedregal de San Angel in Mexico City. Originally the building was planned to host the National
     Library and National Newspaper Library of Mexico. The library finally opened its doors for the first time on
  <origDate when="1956-04-05"
    type="opening">5 April 1956</origDate>. In July 2007 it was declared a UNESCO
     world heritage site. </origin>
 </history>
 <additional>
  <adminInfo>
   <custodialHist>
    <custEvent from="1981" to="1983"> The library was significantly remodelled from 1981 - 1983 with the
         purpose of changing from closed shelving to open stacks, providing users more direct access to the
         collections. </custEvent>
   </custodialHist>
  </adminInfo>
 </additional>
</object>

⚓︎14.3.7 Names and Nyms

So far we have discussed ways in which a name or referring string encountered in running text may be resolved by considering the object that the name refers to: in the case of a personal name, the name refers to a person; in the case of a place name, to a place, for example. The resolution of this reference is effected by means of the key or ref attributes available to all elements which are members of the att.naming class, such as persName or placeName and their more specialized variants such as forename or country. However, names can also be regarded as objects in their own right, irrespective of the objects to which they are attached, notably in onomastic studies. From this point of view, the names John in English, Jean in French, and Ivan in Russian might all be regarded as existing independently of any person to which they are attached, and also independently of any variant forms that might be attested in different sources (such as Jon or Johnny in English, or Jehan or Jojo in French). We use the term nym to refer to the canonical or normalized form of a name regarded in such a way, and provide the following elements to encode it:

  • listNym (표준 이름 목록) 어떤 사물에 대한 표준화된 이름 목록을 포함한다.
  • nym (표준 이름) 표준 이름 또는 어떤 종류의 이름부 정의를 포함한다.
Any element which is a member of the att.naming class may use the attribute nymRef to indicate the nym with which it corresponds. Thus, given the following nym for the name Antony:
<listNym>
 <nym xml:id="N123">
  <form>Antony</form>
 </nym>
<!-- other nym definitions here -->
</listNym>
an occurrence of this name in running text might be encoded as follows:
<forename nymRef="#N123">Tony</forename> Blair
Note that this association (between "Tony" and "Antony") has nothing to do with any individual who might use the name.
The person identified by this particular Tony may however be indicated independently using the ref attribute, either on the forename or on the whole name component:
<forename nymRef="#N123" ref="#BLT">Tony</forename>
<!-- ... -->
<person xml:id="BLT">
 <persName>Tony Blair</persName>
 <occupation>politician</occupation>
</person>
The nym element may be thought of as providing a specialized kind of dictionary entry. Like a dictionary entry, it may contain any element from the model.entryPart class, such as form, etym, etc. For example, we may show that the canonical form for a given nym has two orthographic variants in this way:
<nym xml:id="J451">
 <form>
  <orth xml:lang="en-US">Ian</orth>
  <orth xml:lang="en-x-Scots">Iain</orth>
 </form>
</nym>
Because a schema intending to make use of the nym or listNym element must include the dictionaries module as well as the namesdates module, many other elements are available in addition to form. For example, to provide a more complex etymological decomposition of a name, we might use the existing etym element, as follows:
<nym xml:id="XYZ">
 <form>Bogomil</form>
 <etym>Means <gloss>favoured by God</gloss> from the <lang>Slavic</lang> elements <mentioned xml:lang="ru">bog</mentioned>
  <gloss>God</gloss> and <mentioned xml:lang="ru">mil</mentioned>
  <gloss>favour</gloss>
 </etym>
</nym>
Where it is necessary to mark the substructure of nyms, this may be done by seg elements within the form:
<nym xml:id="ABC">
 <form>
  <choice>
   <seg type="morph">
    <seg>Bog</seg>
    <seg>o</seg>
    <seg>mil</seg>
   </seg>
   <seg type="morph">
    <seg>Bogo</seg>
    <seg>mil</seg>
   </seg>
  </choice>
 </form>
</nym>
The seg element used here is provided by the TEI linking module, which would therefore also need to be included in a schema built to validate such markup. Other possibilities for more detailed linguistic analysis are provided by elements included in that and the analysis (see 18 Simple Analytic Mechanisms) or iso-fs modules (see 19 Feature Structures).
Alternatively, each of the constituents of Bogomil might be regarded as a nym in its own right:
<nym xml:id="B1" type="part">
 <form>bog</form>
</nym>
<nym xml:id="M1" type="part">
 <form>mil</form>
</nym>
Within running text, a name can specify all the nyms associated with it:
...<name nymRef="#B1 #M1">Bogomil</name>...
Similarly, within a nym, the attribute parts is used to indicate its constituent parts, where these have been identified as distinct nyms:
<nym xml:id="BM1" parts="#B1 #M1">
 <form>Bogomil</form>
</nym>
The nym element may also combine a number of other nym elements together, where it is intended to show that they are all regarded as variations on the same root. Thus the different forms of the name John, all being derived from the same root, may be represented as a hierarchic structure like this:
<nym xml:id="J45">
 <form xml:lang="la">Iohannes</form>
 <nym xml:id="J450">
  <form xml:lang="en">John</form>
  <nym xml:id="J4501">
   <form>Johnny</form>
  </nym>
  <nym xml:id="J4502">
   <form>Jon</form>
  </nym>
 </nym>
 <nym xml:id="J455">
  <form xml:lang="ru">Ivan</form>
 </nym>
 <nym xml:id="J453">
  <form xml:lang="fr">Jean</form>
 </nym>
</nym>
The nym element may be used for components of geographical or organizational names as well. For example:
<geogName ref="tag:projectname.org,2012:LAEI1"
 type="hill">
 <geogFeat xml:lang="gd" nymRef="#LAIRG">Lairig</geogFeat>
 <name>Eilde</name>
</geogName> ... <nym xml:id="LAIRG">
 <form xml:lang="gd">lairig</form>
 <def>sloping hill face</def>
</nym> ...

As noted above, use of these elements implies that both the dictionaries and the namesdates modules are included in a schema.

⚓︎14.4 Dates

The following elements for the encoding of dates and times were introduced in section 3.6.4 Dates and Times:

  • date (date) 다양한 형식의 날짜를 포함한다.
  • time (time) 어떤 형식의, 하루의 시간을 정의하는 구를 포함한다.

The current module namesdates provides a mechanism for more detailed encoding of relative dates and times. A relative temporal expression describes a date or time with reference to some other (absolute) temporal expression, and thus may contain an offset element in addition to one or more date or time elements:

  • offset (offset) 표현에 포함된 두 장소명, 날짜, 또는 시간 사이의 차이 방향을 표시하는 상대적 시간 또는 공간 표현의 부분

As members of the att.datable and att.duration classes, which in turn are members of att.datable.w3c and att.duration.w3c respectively, the date and time elements share the following attributes:

  • att.datable.w3c W3C 데이터 유형을 사용하여 날짜가 명기된 사건을 포함하는 요소의 규격화를 위한 속성을 제공한다.
    when표준형식으로 날짜 또는 시간의 값을 제공한다.
  • att.duration.w3c 시간적 지속을 규격화한 녹음에 대한 속성
    dur(지속) 시간선상에서 이 요소의 길이를 나타낸다.

⚓︎14.4.1 Relative Dates and Times

As noted above, relative dates and times such as ‘in the Two Hundredth and First Year of the Republic’, ‘twenty minutes before noon’, and, more ambiguously, ‘after the lamented death of the Doctor’ or ‘an hour after the game’ have two distinct components. As well as the absolute temporal expression or event to which reference is made (e.g. ‘noon’, ‘the game’, ‘the death of the Doctor’, ‘[the foundation of] the Republic’), they also contain a description of the ‘distance’ between the time or date which is indicated and the referent expression (e.g. ‘the Two Hundredth and First Year’, ‘twenty minutes’, ‘an hour’); and (optionally) an ‘offset’ describing the direction of the distance between the time or date indicated and the referent expression (e.g. ‘of’ implying after, ‘before’, ‘after’).

The ‘distance’ component of a relative temporal expression may be encoded as a temporal element in its own right using either date or time, or with the more generic measure element. A special element, offset, is provided by this module for encoding the ‘offset’ component of a relative temporal expression. The absolute temporal expression contained within the relative expression may be encoded with a date or time element; in turn, those elements may of course be relative, and thus contain date or time elements within themselves. This allows for deeply nested structures such as ‘the third Sunday after the first Monday before Lammastide in the fifth year of the King's second marriage ... ’ but so does natural language.

In the following examples, the when and dur attributes have been used to simplify processing of variant forms of expression:
<date when="1786-12-11">
 <date dur="P14D">A fortnight</date>
 <offset>before</offset>
 <date when="1786-12-25" type="holiday">Christmas 1786</date>
</date>
I reached the station <time when="14:15:00">
 <time dur="PT30M0S">precisely half an hour</time>
 <offset>after</offset>
 <time when="13:45:00" type="occasion">the departure of the afternoon train to Boston</time>
</time>
In the following example, a nested date element is used to show that ‘my birthday’ and the cited date are parts of the same temporal expression, and hence to disambiguate the phrase ‘A week before my birthday on 9th December’:
<date when="--12-02">
 <date>A week</date>
 <offset>before</offset>
 <date when="--12-09">
  <date type="occasion">my birthday</date> on <date>9th December</date>
 </date>
</date>
The alternative reading of this phrase could be encoded as follows:
<date when="--12-09">
 <date>A week</date>
 <offset>before</offset>
 <date type="occasion" when="--12-16">my birthday</date> on <date>9th December</date>
</date>
Where more complex or ambiguous expressions are involved, and where it is desirable to make more explicit the interpretive processes required, the feature structure notation described in chapter 19 Feature Structures may be used. Consider, for example, the following temporal expression which occurs in the Scottish Temperance Review of August 1850, referring to the summer holiday known in Glasgow simply as ‘the Fair’:
Not only is the city, <date ana="#gf50">during the Fair</date>, a horrible
nucleus of immorality and wickedness; it sends our multitudes to pollute and demoralize the country.
For the definition of the ana attribute, see chapter 18 Simple Analytic Mechanisms (in particular 18.2 Global Attributes for Simple Analyses). It is used here to link the temporal phrase with an interpretation of it. Like most traditional fairs and market days, the Glasgow Fair was established by local custom and could vary from year to year. Consequently, in order to provide such an interpretation, it is necessary to draw upon additional information which may or may not be located in the particular text in question. In this case, it is necessary at least to know the spatial and temporal context (year and place) of the fair referred to. These and other features required for the analysis of this particular temporal expression may be combined together as one feature structure of type date-analysis:
<fs xml:id="gf50" type="date-analysis">
 <f name="event">
  <string>the Fair</string>
 </f>
 <f name="place">
  <string>Glasgow</string>
 </f>
 <f name="year">
  <numeric value="1850"/>
 </f>
 <f name="from-value">
  <string>1850-08-08</string>
 </f>
 <f name="to-value">
  <string>1850-09-19</string>
 </f>
</fs>
For further discussion of feature structure representation see chapter 19 Feature Structures.

⚓︎14.4.2 Absolute Dates and Times

The following are examples of absolute temporal expressions.

The university's view of American affairs
produced a stinging attack by Edmund Burke in the Commons debate of <date when="1775-10-26">26 October
1775</date>
<date when="1993-05-14">Friday, 14 May 1993</date>
It may be useful to categorize a temporal expression which is given in terms of a named event, such as a public holiday, or a named time such as ‘tea time’ or ‘matins’:
In
New York, <date type="occasion" when="--01-01">New Year's Day</date> is the quietest of holidays, <date when="--07-04" type="occasion">Independence Day</date> the most turbulent.
Absolute temporal expressions denoting times which are given in terms of seconds, minutes, hours, or of well-defined events (e.g. ‘noon’, ‘sunset’) may similarly be represented using the time element.
The train leaves for Boston at <time type="twentyfourHour" when="13:45:00">13:45</time>
At <time type="occasion">sunset</time> we walked to the beach.
The train leaves for Boston at <time xml:lang="en-US" type="descriptive"
 when="13:45:00-05:00"> a quarter of two </time>

⚓︎14.4.3 More Expressive Normalizations

The attributes for normalization of dates and times so far described use a standard format defined by XML Schema Part 2: Datatypes Second Edition. This format is widely accepted and has significant software support. It is essentially a profile of ISO 8601 Data elements and interchange formats — Information interchange — Representation of dates and times. The full ISO standard provides formats not available in the W3C recommendation, for example, the capability to refer to a date by its ordinal date or week date, or to refer to a century. It also provides ways of indicating duration and range.

When this module is included in a schema, the following additional attributes are provided:
  • att.datable.iso ISO 8601:2004 표준을 사용해서 날짜를 추정할 수 있는 사건을 포함하는 요소의 규격화를 위한 속성을 제공한다.
    when-iso표준형의 날짜 또는 시간 값을 제시한다.
    notBefore-isoyyyy-mm-dd 같은 표준형으로 사건의 시작 날짜를 명시한다.
    notAfter-isoyyyy-mm-dd 같은 표준형으로 사건의 종료 날짜를 명시한다.
    from-iso표준형으로 기간의 시작 지점을 나타낸다.
    to-iso표준형으로 기간의 종료 지점을 나타낸다.
  • att.duration.iso 규격화된 시간적 지속을 기록하기 위한 속성
    dur-iso(지속 기간) 시간에서 이 요소의 길이를 나타낸다.
These attributes may be used in preference to their W3C equivalent when it is necessary to provide a normalized value in some form not supported by the W3C attributes. For example, a century date in the W3C format must be expressed as a range, using the from attribute together with either the to attribute or the dur (duration) attribute:
<date from="1301" to="1400">fourteenth century</date>
<date from="1301" dur="P100Y">fourteenth century</date>
With the attribute when-iso, however, it is possible to express the same normalized value in any of the following additional ways:
<date when-iso="13">fourteenth
century</date>
<date when-iso="1301/1400">fourteenth century</date>
<date when-iso="1301/P100Y">fourteenth century</date>

⚓︎14.4.4 Using Non-Gregorian Calendars

All date-related encoding described above makes use of the Gregorian calendar, on which both the ISO and W3C datetime formats are based. However, historical texts often pre-date the invention of the Gregorian calendar in the 16th century, or its adoption in Europe over the following centuries, and many other calendars are used in texts from other cultures and contexts. Non-Gregorian dates can be encoded using methods described below.

First, a Calendar Description element needs to be supplied in the teiHeader as described in 2.4.5 Calendar Description:

<calendarDesc>
 <calendar xml:id="Julian_England">
  <p>The Julian calendar, as used in England until 1752.</p>
 </calendar>
</calendarDesc>
The following attributes can now be used to encode dates using this calendar:
  • att.calendarSystem provides attributes for indicating calendar systems to which a date belongs.
    calendar날짜 표현 시스템 또는 달력 표시 형식을 표시한다.
  • att.datable.custom provides attributes for normalization of elements that contain datable events to a custom dating system (i.e. other than the Gregorian used by W3 and ISO).
    when-customsupplies the value of a date or time in some custom standard form.
    notBefore-customspecifies the earliest possible date for the event in some custom standard form.
    notAfter-customspecifies the latest possible date for the event in some custom standard form.
    from-customindicates the starting point of the period in some custom standard form.
    to-customindicates the ending point of the period in some custom standard form.
    datingMethodsupplies a pointer to a calendar element or other means of interpreting the values of the custom dating attributes.
<p>The Poole by S. <hi>Giles</hi> Churchyarde was a large water in the yeare <date calendar="#Julian_England">1244</date>.</p>
Here, the calendar attribute points to the calendar element in the header which defines and describes the calendar used.
The calendar attribute is used to specify the calendar used in the text content of the dating element which bears it. For reasons of consistency and computability, it is often useful to complement the content of an element with attributes such as when, notBefore, notAfter, etc. For dates expressed in a non-Gregorian calendar, such normalizations may also be expressed in terms of the non-Gregorian calendar specified by the datingMethod attribute. The attributes when-custom, notBefore-custom, from-custom, etc. are provided for this purpose; the datingMethod attribute is used to identify the calendar used in the value of these attributes:
<head> The Tryumphs of Peace.<lb/> That Celebrated the Solemnity of the right Honorable Sr Francis Iones Knight, at
his Inauguration into the Maioraltie of London, on Monday being the <date when-custom="1620-10-30"
  datingMethod="#Julian_England" calendar="#Julian_England"> 30. of October, 1620. </date>
</head>
Here, the calendar attribute specifies the calendar used in the text content of the date element, as before, whereas the datingMethod attribute signifies that the calendar used in the when-custom attribute is also Julian. The schema could be customized in order to constrain the content of custom attributes in a manner similar to the constraints provided on regular Gregorian dating attributes such as when, to enforce consistency in the use of non-Gregorian dates.
Custom dating attributes can be combined with any of the standard dating attributes in order to provide a standardized Gregorian version of a non-Gregorian date. We might enhance the preceding example with the addition of when, providing the Gregorian calendar equivalent of the Julian date:
<date when-custom="1620-10-30"
 when="1620-11-09" datingMethod="#Julian_England"
 calendar="#Julian_England"> 30. of
October, 1620. </date>
주석
51
In the module described by chapter 23 Documentation Elements a similar method is used to link element descriptions to the modules or classes to which they belong, for example.
↵
52
Strictly, a suitable value such as figurative should be added to the two place names which are presented periphrastically in the second version of this example. This would preserve the distinction indicated by the choice of rs rather than name to encode them in the first version of this example.
↵
53
For example, see Renato G. Mazzolini's historical survey of European empires and their unstable constructions of race.Mazzolini (2018)
↵
54
Following Gayle Rubin’s influential theory,
‘Every society also has a sex/gender system—a set of arrangements by which the biological raw material of human sex and procreation is shaped by human, social intervention and satisfied in a conventional manner, no matter how bizarre some of the conventions may be.’Rubin (1975)
.
↵
55
See http://earth-info.nga.mil/GandG/wgs84/index.html. The most recent revision of this standard is known as the Earth Gravity Model 1996.
↵
56
The OGC is an international voluntary consensus standards organization whose members maintain the Geography Markup Language standard. The OGC coordinates with the ISO TC 211 standards organization to maintain consistency between OGC and ISO standards work. GML is also an ISO standard (ISO 19136:2007).
↵

[English] [Deutsch] [Español] [Italiano] [Français] [日本語] [한국어] [中文]


TEI Guidelines P5 Version 4.8.0. Last updated on 2nd September 2024, revision 4e6e41b0b. This page generated on 2024-09-04T14:56:06Z.