A Place for Everything

Why do people get in such a muddle with references to places? A common question on genealogical forums is what to record when the modern name of a place differs from its historical name. Similarly when the enclosing region, such as a county, has been changed since the recording of the document in-hand. Do you alter it to the modern designation, or what? Which is correct?

Well, the obvious answer is that both are correct within their respective timeframes. At the root of this difficulty is the prevailing notion that a place, as represented in your data, is simply the place-name[1]. Just for a moment, let us examine what would happen if you were recording a reference to a person rather than a place. In the details of a marriage, you would not simply write the name of the bride and the groom – you would link the marriage details to the respective person-entities in your data. Those person-entities would contain all the known names used by those people, and the events in their lives, and maybe even biographical notes, documents such as certificates for vital events, photographs, and parentage. If the source had a dubious version of their name, or an obvious spelling error, then it would not be a problem – you would record what was in the source, usually with some explanatory annotation, and still link it to the corresponding person-entity.

The concept of treating places in a parallel fashion to people may sound odd depending on what software you currently use, and whether you’ve ever conducted any place studies. However, there are strong analogies than can be leveraged to good effect, and the STEMMA^® R&D project has pushed this concept further than most. If places are represented as top-level entities in your data then you can attach documents to them (e.g. maps, land deeds), attach photographs, add events to form a timeline, define the coordinates of the associated location[2], and add historical narrative. The similarities in the handling of names, especially multiple names, misspellings, alternative spellings, foreign-language forms, and time dependencies, are striking, and a synopsis can be found at Person & Place Name Similarities.

A contrived example that demonstrates how people can be replaced by places when recording historical data may be found at Case Study - Places. There is also some analogy in the area of parentage although there are also fundamental differences here too. A person has just two biological parents and that fact is fixed forever. Each place has an enclosing region of geographical or administrative importance but this can change over time.

This nicely brings me on to the subject of place-hierarchies. We appreciate that a simple place-name may be ambiguous so we expect it to be qualified in some way. For instance, a town called Americus exists in both the US states Georgia and Indiana. The linking of each place to a parent place creates a place-hierarchy, and the printed form of that place-hierarchy is termed a place-hierarchy-path in STEMMA. For instance:

[Americus, Indiana, US]

[Americus, Georgia, US]

There are some important things to note here:

·         The printed form isn’t the place-hierarchy itself. It is only one representation of it. The true place-hierarchy would be encoded in some way in your data.

·         The printed direction (small-to-large or vice versa), the separating characters (commas in this example), and any enclosing delimiters are all culturally-dependent options.

·         The individual items in each place-hierarchy are all places-entities themselves. STEMMA allows these to be anything from a single household up to a whole country.

The more astute people reading this — at least those who haven’t fallen asleep yet — will realise that place-entities exist in a place-hierarchy, whilst place-names exist in a place-hierarchy-path. This is an important differentiation to make for a hierarchy since we have already shown that a place-entity is not the same as a mere place-name.

On 12^th August 2013, James Tanner took issue with standardised place names in his blog: Wherein I once again take on the threat of standardized place names and rather unfairly blamed this on programmers. The post was quickly followed up with another one giving a specific software example: examples-of-attempts-at-name. His original post leads with an example of five different references to the same place:

Allen's Camp, Yavapai, Arizona Territory, United States
St. Joseph, Yavapai, Arizona Territory, United States
St. Joseph, Apache, Arizona Territory, United States
St. Joseph, Navajo, Arizona Territory, United States
St. Joseph, Navajo, Arizona, United States
Joseph City, Navajo, Arizona, United States

These are all examples of place-hierarchy-paths but alternative place-names are accepted, and even advocated above. The only standardisation that is necessary is that of the place-hierarchy itself, i.e. which place-entities appear in the hierarchy for each country, and in which order. For display purposes, control over the choice of alternative place-names might be a customisable option, but during input the software should consult all the known place-names for each place-entity. In effect, James’s issue wasn’t so much with standardised names as with a poor software implementation. In defence of programmers everywhere, that could even be blamed on product management.

So can everyone do this? It depends on the software you’re using whether you can create a true place-hierarchy as in the illustration below. This depicts the bottom part of a place-hierarchy and attempts to show that all the constituent place-entities could have multiple names and time-dependent parentage, in addition to citing local resources such as photographs and external resources such as historical details. If your software doesn’t support places as top-level entities then you can simulate things to some extent by consolidating the information for each place, say in a document or folder, and linking evidential place-names to your cache for the respective entity. This overcomes the leading question of this post, although it doesn’t help you simulate a full place-hierarchy.

Place-hierarchies could deliver so much but the concept is stymied by lack of understanding about real use cases, lack of analysis regarding their true capabilities, poor software implementations, lack of corresponding standards, and no collaboration. Otherwise, everything is great!

---

[1] I deliberately use a hyphenated form for this term, and several other terms in this post, in order to emphasise that it describes a single concept that is under discussion, and to avoid ambiguities.

[2] The terms place and location are often used interchangeably, and attempts to differentiate them have not gained ground in family history. My own distinction between them, and postal address, may be found at: Place Names. This satisfies a need to be precise about two different concepts.