3

EDITORIAL RULES, CONTINUED

3.5

Associative Relationships

Included in this chapter

• Related Places
• Relationship Type
• Historical Flag
• Dates for Associative Relationship

• Example
  [from VCS, for Siena, Italy]
  

[from an end-user display, for Siena, Italy]

3.5.1

Related Places

3.5.1.1

Definition
Associative relationships to other places in the TGN, particularly any important ties or connections between places, excluding hierarchical whole/part relationships.

3.5.1.2

Values
Values for the Related Entity are concatenated automatically by the system, using the preferred name and other information from the linked record.

3.5.1.3

Sources: Warrant for linking the places
The same standard general references that are appropriate for the Descriptive Note may be used to determine which places are related. See 3.4 Descriptive Note.

3.5.1.4

Discussion
Related Places are the associative relationships between the place record at hand and other place records in the TGN. Only clear and direct relationships should be recorded. These direct relationships may be current or historical.

• Given that associative relationships may be used for retrieval, it is recommended not to frivolously make links between Related Places. Relationships should be made only between records that are directly related, but where hierarchical relationships are inappropriate. If a thesaurus is bound together by too many associative relationships between entities that are only loosely or indirectly related, the value of the relationships in retrieval is lost. Consider this question: If the end-user is interested in retrieving Place X, will he or she also want to retrieve Place Y? If not, probably there should not be an associative relationship between the two records; consider whether the information about the second place is better expressed in the Descriptive Note or a Display Date.

3.5.1.5

RULES

3.5.1.5.1

Minimum requirements
Related Place is not required. Link to related places as time and editorial priorities allow.

• If you are researching a given place, and if you come across information appropriate to create a link to a Related Place, add it.

3.5.1.5.2

When to make Associative Relationships
Make links to Related Places when it is useful to the end-user to have a cross-reference to the other places. Think in terms of retrieval: Would such a link be useful in a search engine? If not, do not make a link to the Related Place (instead, you may mention the other place in the Descriptive Note or a Display Date, if warranted).

• Confusion between two places
  If there is a significant possibility that two places may be confused because they are adjacent to each other, they are coextensive, one place has been moved to another, or places have a direct historical connection (excluding hierarchical relationships), link them as Related Places. In the example below, for the town, Sikión (in Corinth, Greece), the original town was moved 4 kilometers inland to the current site atop two plateaus in 303 BCE, and the old site has since been repopulated and renamed, Kiáton.
  
  
• Example

• See the list of Relationship Types below for further examples of when to make Related Places.

• Homographs
  If the only cause of potential confusion is that the places have the same or similar names and are near each other, do not link them as Related Places. In such cases, describe the issue regarding the name in the Descriptive Note (see Chapter 3.3).
  
  
  • If one place is the historical counterpart to the modern place (and both have the same name), however, linking them as Related Places is appropriate (as in the example for the modern town of Machu Picchu below, which may be confused with the famous ancient site of the same name).
    
    
    • Example
      [for the modern town of Machu Picchu]
    • Relationship Type: distinguished from
      Related Place: Machupicchu (Cuzco, Per$00u) (deserted settlement)
      
• Variant names vs. separate records
  If scholarly opinion is divided as to whether or not one place is the same place as another, make separate records for each place and link them with relationship type: possibly identified as. This typically occurs with historical entities or historical names for extant places. See the example of Sharuhen under Relationship Types below.
  
  
  • If scholars generally agree that a historical place sat on the same site as a modern place (or another historical place), make only one record for the place and include the other names as variant names.
    
    
• Organizations
  If you are adding a major geopolitical institution (e.g., the United Nations or the European Union), it recommended, but not required, to link to all the members as Related Places. Link to the members as time and editorial priorities allow.
  
  
  • Caveat: In such cases, if you link to any member, you must link to all of them.
    
    
• Example
  [partial list in the end-user view of the record for the European Union; in the actual record, ALL of the members are included]
  

• Hierarchical vs. Associative Relationships
  Do not make associative relationships when hierarchical relationships are more appropriate. For the administrative divisions of nations, states, empires, and any other entity with centralized power and borders, use the hierarchical relationships rather than Related Places (which are associative relationships).
  
  
  • The decisions regarding when to make a hierarchical vs. an associative relationship should be relatively clear for current entities. However, if there is confusion regarding how to treat historical entities, look to other, similar examples in TGN and consult with your supervisor.

3.5.2

Relationship Type

3.5.2.1

Definition
A term or phrase characterizing the relationship between the place at hand and the linked place.

3.5.2.2

Values
Values are chosen from a controlled list comprising a code and phrase. Each code-plus-phrase is linked to another code, which is the reciprocal relationship.

• Example
  [partial view of controlled list from VCS]

3.5.2.3

RULES

3.5.2.3.1

Appropriate Relationship Types
It is required to include a Relationship Type for each Related Place.

• Choose the specific suitable Relationship Type, if possible. If necessary, use the broad related to as a default.

• Link to the correct side of the relationship
  Remember that Relationship Types are reciprocal (that is, linked to both records). When you choose a Relationship Type, make sure that the Relationship Type and its counterpart will work from the points of view of both linked records.
  
  
  • For some relationships, the relationship type is the same on both sides of the link; however, for others it is different depending upon which record you are in. Be very careful to choose the correct relationship for the focus record (i.e., the record you are in when you make the relationship). Consider what will make sense when displayed to a user. For example, if you are in the record of a city, the relationship type linking the city to the state is capital of, because the city in the focus record is the capital of the state in the linked record. If you open the record for the linked state, the reciprocal relationship type will be capital is. If you have a question about which side of the relationship applies to your record, ask your supervisor before making the link.

• Avoid redundant links
  Do not make relationships between entities that have the relationship expressed in another way; for example, if members of an organization are linked to the organization, do not link the members to each other.
  

• Definitions of Relationship Types
  Apply Relationship Types according to thedefinitions in the table below.

   » List of relationship types:

• general
  related to: General designation for relationships, where no specific relationship is known or appropriate.
  
  distinguished from: Use when there is some significant reason why the two places are often confused, but they should be distinguished from each other. Use when a given name is sometimes applied to a different geographic area in other classification schemes. Generally applies to states or general regions rather than to inhabited places. May apply to current or historical relationships.
  
  possibly identified as: Use for places, often inhabited places or deserted settlements (rather than states), about which scholars are uncertain whether or not the historical place is on the same site as the modern place. The places may have either different or similar names. (If the places are established as occupying the same site, there should be only one record, with the historical names included as variant names.)
  

• Examples
  [for the Ancient Mesopotamian kingdom, Assyria, which is distinct from the Roman Province of the same name]
• Relationship Type: distinguished from
  Related Place: Assyria (Roman Empire) (province)
  
  [in the record for the lost settlement of Sharuhen]
• Relationship Type: possibly identified as
  Related Place: Tel el-Far'ah (As Suwayd$01a', Syria) (deserted settlement)

• adjacent to
  Use when two sites are often confused or mistakenly believed to be the same site, but they are actually adjacent to each other. Generally applies to current relationships..

• Example
  [for Saint Paul, Minnesota, USA, linked to its "Twin City"]
• Relationship Type: adjacent to
  Related Place: Minneapolis (Hennepin county, Minnesota, USA) (inhabited place)

• coextensive with
  Use when places have two different place types for different administrative or physical designations, but the places are coextensive (e.g., when an island and a province occupy the same territory); such places may share the same name. Generally applies to current relationships.

• Example
  [for Kings county, New York, USA]
• Relationship Type: coextensive with
  Related Place: Brooklyn (New York, New York, USA) (borough)

• meaning/usage overlaps with
  Use when names of two places are associated with slightly or significantly different and overlapping boundaries in different contexts or during different historical periods. For example, sometimes Judaea is considered a synonym with the Holy Land, although in TGN, they are classified as separate places with different boundaries (although boundaries overlap)

• Example
  [for Judaea (Israel) (historical region)]
• Relationship Type: meaning/usage overlaps with
  Related Place: Holy Land (Asia) (historical region)

• member of / member is
  Use for linking states to a larger organization in which their participation is characterized in your source as member. From the organization's point of view, the relationship type is member is. May be current or historical.
  

• Example
  [for the nation of Austria]
• Relationship Type: member of
  Related Place: United Nations (organization)

• capital of / capital is
  Use to link a capital city to the entity for which it is or was the capital. May be current or historical.
  

• Example
  [for Lincoln, Lincolnshire, England, was the capital of a Roman Province]
• Relationship Type: capital of
  Related Place: Flavia Caesariensis (Britannia Inferior, Britannia, Roman Empire) (province)

• ally of
  Use for allies that have a direct, important relationship that is not expressed in another way (e.g., for the towns that were members of the Medieval Tuscan Ghibelline and Guelf factions). Do not use this Relationship Type to link long lists of members to all the other members in the long list; in such cases, it is probably more appropriate to make a separate record for the organization or association, and link the members to that record.

• Example
  [for Florence, Italy]
• Relationship Type: ally of
  Related Place: Orvieto (Terni province, Umbria, Italy) (inhabited place)
  Display Date: Guelf allies during the 13th and 14th centuries

• moved from / moved to
  Use for inhabited places that were physically moved from one location to another, often due to the threat or occurrence of natural disaster in one location, the flooding of an area due to the construction of a dam, etc. Typically, one of these places will be historical, often a deserted settlement.
  

• Example
  [for Troupville, Georgia, USA]
• Relationship Type: moved to
  Related Place: Valdosta (Lowndes county, Georgia, USA) (inhabited place)

• successor of / predecessor of
  Use for states that occupy similar territory, but one historically followed the other. Typically, at least one of the entities is now a former state.
  

• Example
  [for ancient Persia]
• Relationship Type: predecessor of
  Related Place: Iran (nation)

• historical connection
  Use for states that have a strong, direct historical link, but the relationship is not necessarily successor of / predecessor of. Do not use for hierarchical whole/part relationships.
  

• Example
  [for the historical region of Guyenne, France]
  Relationship Type: historical connection
  Related Place: Gascogne (France) (historical region)

3.5.2.3.2

Adding new Relationship Types
Most of the necessary Relationship Types should already be included in the controlled list. If you feel that you wish to add another Relationship Type to this list, consult with your supervisor.

3.5.3

Historical Flag

3.5.3.1

Definition
Flag indicating the historical status of the relationship to the Related Place.

• Example
  [for Sousse, Tunisia]

3.5.3.2

Values
C - Current, H - Historical, B - Both, N/A - Not Applicable, U - Unknown

3.5.3.3

Sources
Editors should use standard, authoritative sources to determine whether or not a relationship is historical.

3.5.3.4

RULES

• Choose the flag appropriate to the relationship. The default flag for the relationship is Current. If the relationship is not current, change it to the appropriate flag, which will typically be Historical.
  
  
  • Current: For relationships that still exist, even though they may have been established long ago, use Current.
    
    
  • Historical: For a historical relationship that no longer exists, typically because one entity is no longer extant, use Historical.
    
    
  • Both:For those rare relationships where a place had a relationship to another place for a period of time, the relationship ended, and at a later time was reestablished, use Both.
    
    
  • N/A: Use N/A if Current or Historical are not appropriate to the situation. This would be a very rare circumstance. Consult with your supervisor before using this flag.
    
    
  • Unknown: This flag is used primarily for data that is loaded into VCS. Editors should avoid using Unknown because whether the relationship is current or historical is typically knowable (even if it is currently unknown by the editor due to lack of proper information). If you feel that Unknown is appropriate in a given situation, consult with your supervisor; it would be highly unusual for an editor to know enough to make the relationship, but not enough to know if it is current or historical.

3.5.4

Dates for Related Places

3.5.4.1

Definition
Dates delimiting the relationship between the two places.

• Example
  [for Reims, France]

3.5.4.2

Fields
There are three fields: Display Date, Start Date, and End Date.

3.5.4.3

Values
Display Date is a free-text field; values may be any ASCII character; no special characters or diacritics are allowed; diacritics must be expressed according to the codes in Appendix A.

• Start Date and End Date must contain valid years, validated by VCS.
  

3.5.4.4

Sources
The dates should be determined using the same standard reference works that supply other information about the relationship.

3.5.4.5

Discussion
The Display Date for the relationship usually refers to a period or date, however, it may sometimes contain notes that do not explicitly make reference to a date. In such cases, the note should implicitly refer to a date or datable condition or event, because you are required to include a Start Date and End Date with every Display Date.

• Display dates are indexed with Start Date and End Date. Start and End Dates are controlled by special formatting; dates BCE are represented by negative numbers.

3.5.4.6

RULES

• Dates are not required. However, if you enter data in any of the three fields, you must enter data in ALL three of the fields.
  
  
• The dates appear on reciprocal links. That means that the same dates will appear in BOTH records. Write the Display Dates and assign Start and End Dates so that they will be correct and unambiguous in both records. Repeat the names of the places in the Display Date when necessary to avoid ambiguity, as in the example below.
  
  
  • Example
    [in the record for Oceania]
  • Relationship Type: distinguished from
    Related Person or Corporate Body: South Sea Islands (Pacific Ocean) (islands)
    Display Date: in some classification systems, "Oceania" is considered a synonym for "South Sea Islands"
    Start Date: 1800 End Date: 9999
    
    
• A brief set of rules for Dates appears below. See also Appendix B and Dates for Names in Chapter 3.3 Names.

3.5.4.6.1

Display Date

• Follow the style of existing Display Dates.
  
  
  • Examples
    [for Antigua and Barbuda]
  • Relationship Type: member of
    Related Place: Commonwealth of Nations (association)
    Display Date: joined the association in 1981
    Start Date: 1981 End Date: 9999
    
    [for the deserted settlement, Ocotepeque, Honduras]
  • Relationship Type: moved to
    Related Place: Nueva Ocotepeque (inhabited place)
    Display Date: after 1935
    Start Date: 1935 End Date: 1937
    
    [for the modern nation, Egypt]
  • Relationship Type: successor of
    Related Place: Egypt (ancient) (Africa) (nation)
    Display Date: area of the modern nation was the core of the ancient kingdom of Egypt
    Start Date: 1922 End Date: 9999
    
    
• Do not use an initial capital, unless the word is a proper name.
  
  

• Do not use full sentences; do not end the display date with a period or any other punctuation.

• Ideally, the display date should refer, explicitly or implicitly, to a time period or date associated with the link between the related places.

• If a date is uncertain, use a broad or vague designation (e.g., ancient) or other terms such as ca. and probably to express uncertainty (e.g., ca., in the example below).
  
  
  • Example
    [for Trier (Rheinland-Pfalz, Germany)]
    Relationship Type: capital of
    Related Place: Belgica Prima (Gallia Belgica, Gaul) (nation)
    Display Date: from ca. 300 CE
    Start Date: 290 End Date: 450
    
    
• In some cases, the Display Date may be used to record unusual or important information about the Related Place relationship (see the example below), but not referring explicitly to a date. However, dates should be implicit in the condition or event mentioned and you should have a period or date in mind, because - if you record a Display Date - Start and End dates are required.
  
  
  • Example
    [for the former nation of Alashiya]
    Relationship Type: possibly identified as
    Related Place: Cyprus (Asia) (island)
    Display Date: it is possible that the name "Alashiya," which occurs in Hittite and Egyptian records, refers to Cyprus
    Start Date: -1700 End Date: 9999

3.5.4.6.2

Start Date and End Date
Use dates that most broadly delimit the span of time of the relationship referred to in the display date. In many cases, the years will be approximate years. When in doubt, it is better to estimate too broad a span rather than too narrow a span. See the Date Authority in Appendix B for approximate dates of historic events and entities; you should also consult other, related records in TGN to establish dates.

• Dates must be expressed in the proleptic Gregorian calendar, which is the Gregorian calendar projected back in time before it came into existence.
  
  
• Express dates BCE with negative numbers, using a hyphen before the number. Do not use commas or any other punctuation
  .
  • Example
    [for Ankara, Turkey]
  • Relationship Type: capital of
    Related Place: Galatia (Turkey) (general region)
    Display Date: from 25 BCE
    Start Date: -25 End Date: 450
    
    
• For current relationships, use the End Date 9999.
  
  
  • Example
    [for the European Union]
    Relationship Type: member is
    Related Place: Republic of Ireland (nation)
    Display Date: since 1973
    Start Date: 1973 End Date: 9999
    
    
• For very ancient dates, expressed as years ago or before present in the Display Date, translate these dates into approximate years in the proleptic Gregorian calendar for the Start and End Dates.