Wednesday, 19 March 2014

Related Entities

No, not that sort of relation this week. This brief post espouses some thoughts on the esoteric subject of “related” places and groups. This should be of interest to software people but maybe not to everyone else.

To give my readers the chance to decide, let me explain the basic problem. Places are acknowledged to be fundamentally hierarchical — meaning that each place, whether a house, street, town, county, etc., is part of some bigger place — but every so often something breaks that neat picture. A place may be split into smaller ones, or small places joined together to form a bigger one, or a place torn down and replaced with an entirely new one at the same location[1].

This is a thorny issue that I don’t believe anyone has succeeded in handling gracefully. When the name of a place has changed at some point, or its boundaries have moved, then that is a simpler problem that I have already addressed. I have even addressed the more complicated situation where the parent place (i.e. the bigger one to which it belongs) has changed. In all these cases, the entity may be considered to be the same one, albeit with some new or changed properties.

The anomalous relationships I want to discuss may be categorised broadly as:

  • One-to-Many. This involves a splitting of an entity. An example for a place would be where a country has been split into several smaller ones, or a family farm has been divided between a number of siblings.
  • Many-to-One. This involves a joining of smaller entities. An example for places might be where someone has purchased adjoining land, or contiguous houses, and made them into one.
  • One-to-One. This involves a connection between two different entities that isn’t modelled by a normal hierarchy. It could be used as a catchall since the potential circumstances are more varied. For instance, the two entities may co-exist but still be related (see below), or there may be gap between the demise of one and the creation of the other. An example of the latter might be the redevelopment of an area of housing involving the digging-up and the laying-down of totally different roads. Two houses, of different dates, might then be related by their physical location.

In Revisiting the Family Group, I made the point that this issue must be solved in a consistent fashion for both places and groups. The first two categories have an obvious correspondence since groups may merge or splinter. The aforementioned post even provides a military example where two regiments were merged to form a new one. Luckily, both the Place and Group entities of STEMMA contain Creation/Demise elements that indicate when it came into being and/or ceased to exist. This turns out to be the ideal position to document the one-to-many and many-to-one transformations since the two forms would not co-exist. For convenient management, I elected to collect the links into a single place, thus providing a SplitTo and a JoinFrom sub-element.


In the one-to-one category, there’s a Group situation that has no equivalent for a Place: where one entity has inspired another. This is not the same as a splinter, which would otherwise divide the group membership, and an example I’m particularly familiar with is the creation of FHISO. This group was formed by a small set of members from BetterGEDCOM but the former group was unchanged.

So is this a complete solution? The answer has to be ‘no’ but I’m floating these ideas to get some constructive feedback, and also to indicate what failings the approach has. My goal in this exploration is to find a balance between structure and narrative; using the latter to differentiate the finer points of some generic connection or transformation event. One area it may not address is the Conurbation: a collection of neighbouring cities or towns that have a name independent of their respective parent places.

There is a need to accommodate these because they appear in such records as census returns. The example I will use for the purposes of illustration is The Potteries: an area of North Staffordshire, England, which encompassed the towns of Tunstall, Burslem, Hanley, Stoke, Fenton, and Longton. These towns, and several villages, were later given the single name of Stoke-on-Trent, a polycentric town that eventually became a city, although there was a settlement of the same name before that. An example occurrence in the records may be found for the place-of-birth of Joseph Davies in 1861[2].

I’ve picked this case since it appears in my own data. As a singular case, there may be a way of handling it as an older version of the Stoke-on-Trent town/city, but in the general case of UK Conurbations there may be instances where the natural parent place (e.g. a county) may be different for the constituent towns and villages. Short of having multiple parent entities (of different types), I cannot see a better scheme than relying on a one-to-one association at the moment.

** Post updated on 26 Dec 2015 to align with the changes in STEMMA V4.0 **



[1] STEMMA® makes a precise distinction between the terms ‘place’ and ‘location’. A definition and discussion may be found at STEMMA Places.
[2] "1861 England, Wales & Scotland Census",  database, FindMyPast (www.findmypast.org.uk : accessed 18 Mar 2014), household of Joseph Davies (age 30); citing RG 9/2292, folio 47, page 3; The National Archives of the UK (TNA).

No comments:

Post a Comment