Linking Names and Their Referents

The class att.naming is a subclass of the class att.canonical, from which it inherits the following attributes: As discussed in , 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: The encoder may use these attributes in combination as appropriate. For example: That silly man David Paul Brown 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 David Paul Brown 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 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 : That silly man David Paul Brown 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 the Browns 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.In the module described by chapter a similar method is used to link element descriptions to the modules or classes to which they belong, for example. 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 Heathrow Airport to France

However, as explained in , 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 for further discussion.

All members of the att.naming class inherit the following attributes from the att.global.responsibility class: 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.

Dating Attributes

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

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: June 9th The period is approaching which will terminate my present copartnership. On the 1st Jany. 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: Before 510 BC Between 510 and 323 BC Hellenistic. Commonly treated as from the death of Alexander to the Roman conquest. Roman The Christian period technically starts at the birth of Jesus, but in practice is considered to date from the conversion of Constantine in 312 AD.

With these definitions in place, any datable element may be associated with a specific period: Stauropolis

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: Montgomery Bus Boycott A political and social protest campaign against the policy of racial segregation on the public transit system of the city of Montgomery.

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.

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: 15 March 1857. Some time in March or April of 1857. Lived in Amsterdam during March and April of 1857. From the 1st of March to some time later in March or April of 1857. From the 1st of March or sometime later to the end of April, 1857. From sometime in March of 1856 to sometime in April of 1858.

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

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:

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:

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 David Paul Brown has suffered the furniture of his office to be seized the third time for rent. That silly man David Paul Brown has suffered ... That silly man David Paul Brown has suffered ... That silly man David Paul Brown 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: Roosevelt, Franklin Delano Franklin Delano Roosevelt

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: Franklin Delano Roosevelt Margaret Hilda Roberts Thatcher Muhammad Ali Norman St John Stevas 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: Johan Dystvold Dystvold

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: Kara Hattersley- Smith

The full attribute may be used to indicate whether a name is an abbreviation, initials, or given in full: Maggie Thatcher

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: Peter son of Herbert gives the king 40 m. for having custody of the land and heir of John son of Hugh...

Similarly, patronymics may be treated as forenames, thus: ... but it remained for Snorri Sturluson 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 Finnur Jonsson 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: Egill Skallagrmsson In the following example, the type attribute is used to distinguish a patronymic from other forenames: Sergei Mikhailovic Uspensky

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: Marques Junior, Henrique Charles II Rudolf II von Habsburg Smith Minor

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: Mme de la Rochefoucault Walter de la Mare

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 .

Here are some further examples of the usage of these elements: Princess Grace Grandma Moses President Bill Clinton Colonel Gaddafi Frederick the Great

A name may have any combination of the above elements: Governor Edmund G. Jerry Moonbeam Brown Jr.

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 .

White space is allowed and therefore significant between elements within name, persName, orgName, and placeName. Therefore Mary Ann DeMint ]]> encodes Mary Ann DeMint and MaryAnn De Mint ]]> encodes MaryAnn De Mint. See for more information on whitespace in XML.

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. This element is a member of the same attribute classes as persName, as discussed above in .

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 Pennsyla. Abolition Society 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 Pennsyla. Abolition Society. About a year back, a question of considerable interest was agitated in the Pennsyla. Abolition Society. 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 ). 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 BSkyB rather than the BBC as a phrase: The feeling in Canada is one of strong aversion to the United States Government, and of predilection for self-government under the English Crown The Justified Ancients of Mu Mu or as a composite of other kinds of name: Ernst & Young

The components of an organization's name may include place names as well as personal names: A spokesman from IBM UK said ... or role names: THE TICKET which you will receive herewith has been formed by the Democratic Whig party 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 Welfare and Best Interests of the Community.

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: Department of Modern History Glasgow University

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 ). A place named simply in terms of geographical features such as mountains or rivers is represented using the geogName element (see section ). 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 ).

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

Like the persName element discussed in section , 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: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. After spending some time in our modern Babylon, New York, I have proceeded to the City of Brotherly Love. After spending some time in our modern Babylon, New York, I have proceeded to the City of Brotherly Love.

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.

On Monday, she was writing about the 1618 Defenestration of Prague which initiated the long war.

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

Object Names

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.

The Minster Lovell Jewel is probably the most similar to the Alfred Jewel and was found in Minster Lovell in Oxfordshire and is kept at the Ashmolean Museum.

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.

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.For example, see Renato G. Mazzolini's historical survey of European empires and their unstable constructions of race. 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:

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.

Here is a simple example: Rome 41.891775 12.486137 423025 capital of the Roman Empire

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

These elements may appear only within a listPerson element, which groups such descriptions together, and optionally also describes relationships amongst the people listed.

One or more listPerson elements may be supplied within the standOff element (see ) 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: Adam Schiff District Attorney for Manhattan in seasons 1 to 10 of . Mike Logan NYPDNew York Police Department Detective regularly appearing in seasons 1 to 5 of and seasons 5 to 7 of . Benjamin Stone Executive Assistant District Attorney for Manhattan in seasons 1 to 4 of Jack McCoy An Executive Assistant District Attorney then District Attorney for Manhattan in seasons 5 to 10 of , in seasons 1, 9, 11, and 19 of , and in season 1 of . Jamie Ross An Assistant District Attorney for Manhattan in seasons 7 & 8 of , and a defense attorney in seasons 10 & 11, and then a judge in . Joe Fontana NYPDNew York Police Department Detective regularly appearing in seasons 15 & 16 of . Adam Schiff U.S. Representative from California since 2013. Mike Logan Gridiron football player for the Pittsburgh Steelers from 2001 to 2006. Benjamin Stone Michigan State Senator from 1968 to 1979. Jack McCoy Iowa State Representative from 1955 to 1959. Jamie Ross Broadway actor, with occasional forays into television, from 1971 to roughly 2007. Joe Fontana A member of Canada’s House of Commons from 1987 to 2006, and mayor of London, Ontario from 2010 to 2014.

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: In addition, a small number of very commonly used personal properties may be recorded using attributes specific to person and 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: less than 18 years of age 18 to 65 years of age over 65 years of age 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 .

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: as discussed in above.

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. 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 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: The Silver Beetles The Beatles

The names of the people making up an organization can also change over time, (if they are known at all). For example: The Silver Beetles The Beatles John Lennon Paul McCartney George Harrison Stuart Sutcliffe Pete Best John Lennon Paul McCartney George Harrison Ringo Starr

An org may contain subordinate orgs: Oxford University Computing Services Information and Support Group Infrastructure Group Networking Team System Development Team Learning Technologies Group

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.

The TEI institutional hosts are: Brown University The host contribution is made jointly by the Brown University Women Writers Project and the Brown University Library's Center for Digital Initiatives. Nancy Hosting is provided by a group of institutions located in Nancy, France, coordinated by Loria and also including ATILF and INIST. Oxford University Hosting is provided by the Research Technologies Service at Oxford University Computing Services. University of Virginia Virginia's host support comes jointly from the Institute for Advanced Technology in the Humanities and the University of Virginia Library.

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.

Places

In 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:

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:

Events

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.

Treaty of Utrecht France ceded to Great Britain its claims to the Hudson's Bay Company territories in Rupert's Land, Newfoundland, and Acadia and recognized British suzerainty over the Iroquois but retained its other pre-war North American possessions, including Île-Saint-Jean (now Prince Edward Island)... Quebec Act 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 Treaty of Paris. Treaty of Fort Pitt Also known as the Treaty with the Delawares, this was the first written treaty between the newly formed United States and any Native American people, in this case, the Lenape or Delawares.

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

Luftwaffe shoots down Ilyushin Il-4 DB-3F Іван Чиссов Snap, Crackle, Pop is shot down by German flak B-17 Alan Magee Avro Lancaster shot down by Junkers Ju 88 Lancaster Nicholas Alkemade LANSA 508 struck by lightning Amazon rainforest Juliane Diller (née Koepcke) Bombing of Yugoslav Airlines Flight 367 JAT 367 Весна Вуловић Russian military jet collides with passenger flight Amur Oblast SAS parachute failure Bear Grylls Johannesburg parachute failure Christine McKenzie Christine McKenzie Cameraman fails to open chute Sport videographer Gare de Saint-Nazaire 47.28657 -2.21171 Johannesburg South Africa Gauteng Камчатке Russia Kamchatka Krai Kenya Bureysky District Бурейский район Russia Амурская область Bureysky 50.019444 130.466667 Oberkirchen Deutschland Nordrhein-Westfalen Arnsberg Hochsauerlandkreis Schmallenberg 51.154 8.357 Puerto Inca Peru Huánuco Puerto Inca Sebnitz 50.966667 14.283333 Eastern Front Zambia Весна Вуловић Vesna Vulović Larisa Savitskaya Савицкая, Лариса Владимировна Іван Михайлович Чиссов Иван Михайлович Чисов Ivan Mikhailovich Chisov Alan Eugene Magee Nicholas Stephen Alkemade Edward Michael Grylls Juliane Koepcke James Boole 1978, give or take a year

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: All day meeting to resolve content models first part second part

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

Objects

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.

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 where only a single objectName is provided and below where multiple versions are provided.

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. Mask of Tutankhamun 256a 60672 220 Museum of Egyptian Antiquities

15 Meret Basha Ismailia Cairo Egypt 30.047778 31.233333

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.

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.

The Minster Lovell Jewel is probably the most similar to the Alfred Jewel and was found in Minster Lovell in Oxfordshire and is kept at the Ashmolean Museum.

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.

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:

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:

Antony

an occurrence of this name in running text might be encoded as follows: Tony 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: Tony Tony Blair politician

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:

Ian Iain

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:

Bogomil

Means favoured by God from the Slavic elements bog God and mil favour

Where it is necessary to mark the substructure of nyms, this may be done by seg elements within the form:

Bogomil Bogomil

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 ) or iso-fs modules (see ).

Alternatively, each of the constituents of Bogomil might be regarded as a nym in its own right:

bog

mil

Within running text, a name can specify all the nyms associated with it: ...Bogomil... Similarly, within a nym, the attribute parts is used to indicate its constituent parts, where these have been identified as distinct nyms:

Bogomil

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:

Iohannes

John

Johnny

Jon

Ivan

Jean

The nym element may be used for components of geographical or organizational names as well. For example: Lairig Eilde ...

lairig

sloping hill face ...

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

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: A fortnight before Christmas 1786 I reached the station precisely half an hour after the departure of the afternoon train to Boston

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: A week before my birthday on 9th December The alternative reading of this phrase could be encoded as follows: A week before my birthday on 9th December

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 may be used. Consider, for example, the following temporal expression which occurs in the of August 1850, referring to the summer holiday known in Glasgow simply as the Fair: Not only is the city, during the Fair, 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 (in particular ). 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: the Fair Glasgow 1850-08-08 1850-09-19 For further discussion of feature structure representation see chapter .

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 26 October 1775 Friday, 14 May 1993

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, New Year's Day is the quietest of holidays, Independence Day 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 13:45 At sunset we walked to the beach. The train leaves for Boston at a quarter of two

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 . 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: 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: fourteenth century fourteenth century With the attribute when-iso, however, it is possible to express the same normalized value in any of the following additional ways: fourteenth century fourteenth century fourteenth century

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 :

The Julian calendar, as used in England until 1752.

The following attributes can now be used to encode dates using this calendar:

The Poole by S. Giles Churchyarde was a large water in the yeare 1244.

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: The Tryumphs of Peace. That Celebrated the Solemnity of the right Honorable Sr Francis Iones Knight, at his Inauguration into the Maioraltie of London, on Monday being the 30. of October, 1620. 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: 30. of October, 1620.