3 |
EDITORIAL RULES, CONTINUED |
|
|
|
3.5 |
|
Associative Relationships
Included in this chapter
- 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.
|
 |
|
|
|
- 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.)
3000 |
related to |
3000 |
3001 |
distinguished from |
3001 |
3005 |
possibly identified as |
3005 |
|
|
|
|
|
|
|
|
- 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.
3102 |
coextensive with |
3102 |
|
|
|
|
|
|
|
|
- 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)
3110 |
meaning/usage overlaps with |
3110 |
|
|
|
|
|
|
|
|
- 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.
3317 |
member is |
3318 |
3318 |
member of |
3317 |
|
|
|
|
|
|
|
|
- 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.
3201 |
capital of |
3202 |
3102 |
capital is |
3101 |
|
|
|
|
|
|
|
|
- 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.
3401 |
moved from |
3402 |
3402 |
moved to |
3401 |
|
|
|
|
|
|
|
|
- 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.
3411 |
successor of |
3412 |
3412 |
predecessor of |
3411 |
|
|
|
|
|
|
|
|
- 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.
3510 |
historical connection |
3510 |
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|