Place entities can describe a household address, or a street, a village, a town, a city, a whole country, etc. They have a strong hierarchical structure which effectively factors out common data. This reduced duplication helps to ensure consistency of the data and better supports geographical analysis. For instance, simply being able to see who else in a Dataset lived near the same address. It also allows relevant material (links, documents, images, maps, etc.) to be associated with the correct place, and not simply some related place.
<Place Key=’key’>
[ <Title> place-title </Title> ]
[ <Type> place-type </Type> ]
[ <Category> place-category </Category> ]
[ NAME_VARIANTS | { <PlaceName [DATA_ATTRIBUTE] ... > place-name </PlaceName> } ]
[ <Location [Open=’boolean’] [RANGE_FROM] [RANGE_TO]>
coordinates
[ TEXT_SEG ] ...
</Location> ] ...
[ <ParentPlaceLnk [RANGE_FROM] [RANGE_TO] Key=’key’>
[ TEXT_SEG ] ...
</ParentPlaceLnk> ] ...
[ <Creation>
[ <JoinFrom Key=’key’/> ... ]
[ TEXT_SEG ] ...
</Creation> ]
[ <Demise>
[ <SplitTo Key=’key’/> ... ]
[ TEXT_SEG ] ...
</Demise> ]
[ EVENTLET ] ...
[ SOURCE_LNK ] ...
[ <RelatedTo>
<PlaceLnk Key=’key’/> ...
[ TEXT_SEG ] ...
</RelatedTo> ]
[ EXTERNAL_ID ] ...
[ TEXT_SEG ] ...
</Place>
The location of the Place may be specified using optional <Location> elements — more than one of a location has changed over time. This normally contains an ISO 6709 longitude/latitude pair (for a point) or an ordered closed list of such values describing a polygon (for an irregular area — requires minimum of 3 points). An Open=’1’ attribute may be added to declare an ordered open list for representing roads and streets (Open=’0’ is the default for 3 or more points). For instance:
<Place Key=’wGladeHill’>
<PlaceName> Glade Hill </PlaceName>
<ParentPlaceLnk Key=’cNottm’/>
<Location> +53.0020-001.1517/+53.0018-001.1510/
+53.0012-001.1510/+53.0012-001.1522/+53.0017-001.1527/
</Location>
<Text>
A differentiation between this place and nearby <PlaceRef>Bendigo’s Ring</PlaceRef> can be found at <Link URL=’http://parallax-viewpoint.blogspot.com/2013/11/where-is-bendigos-ring.html’>Where is Bendio’s Ring?</Link>
</Text>
</Place>
The ISO standard mandates a trailing ‘/’ at the end of a pair and so an ordered list is simply a concatenated series of them. If a different coordinate system is required, such as the Ordnance Survey National Grid of Great Britain, then it must use an explicit namespace prefix. Support for alternative systems can be important if interfacing to local map resources; especially through a software interface. Alternatively, an authoritative set of coordinates can be imported from some external Place Authority using one of the EXTERNAL_ID values.
Items of information about the place that have been extracted from relevant sources may be specified using the following Properties. These are defined here using the syntax used for Extended Properties.
<PropertyDef Name=’Name’ Type=’PlaceRef’/>
The name of the place, as recorded in the supporting source.
<PropertyDef Name=’Parish’ Type=’Text’/>
The name of the ecclesiastical parish associated with the Place.
<PropertyDef Name=’Role’ ItemList=’1’ Type=’EnumList’/>
The role(s) of a place mentioned in Event sources. Role values currently include Destination, from the http://stemma.parallaxview.co/place-role/ namespace. See Extended Vocabularies for custom roles.
Any custom Place properties can also be used in the context of PLACE_PROPERTY. See Extended Properties.
Places may be part of several flavours of hierarchy such as registration/statistical (registration district, in registration county), or religious (ecclesiastical parish, in diocese, in archdiocese), electoral wards, etc., but the Place entity primarily focuses on the geographical/administrative hierarchy. The underlying premise is that every place has a unique bounding parent place at any given time. The other jurisdictional zones could be represented as simple properties, although alternative hierarchies can also be constructed as long as that premise is not violated. The Place entity also support non-hierarchical relationships (see Related Entities) that may be used to tie alternative hierarchies together, if necessary. A typical example that is used to justify an entity having multiple concurrent parents — contrary to what was said above — is that of a street being in both an administrative area and a religious parish. However, it’s not uncommon to have a single street split between two such zones, especially where electoral divisions have been defined. This is actually a good case for linking hierarchies of different types using the <RelatedTo> element.
The <Title> element provides a unique descriptive title that will be used to identify the Place in genealogical reports. This is not the same as the Place-hierarchy-path as reconstructed from the Place-hierarchy (see Place Names) which may be date-dependent.
A Place entity does not demand a completely determinate address but where the address is known then it is connected to a parent Place, and so on. The termination point of this hierarchy is a matter of choice. For example, in the following Nottingham address, we could have continued the parentage all the way up to Country (England). This would have to be a consideration if a Dataset spanned several countries since no Place-hierarchy-path should be ambiguous:
[Nottinghamshire, Nottingham, Manning Grove, 15]
The following place-types are predefined:
For instance: “Flat 18 (apartment), Da Vinci House (building), 44 (number) Saffron Hill (street), London (town)”. For programmers in particular, a very useful list of presumptions that they often make about places and addresses may be found at: Falsehoods Programmers Believe About Addresses. See Extended Vocabularies for defining custom place-types.
Note that the hierarchical link to the parent Place can be made dependent upon the date. For instance, a Place may have moved from one county to another. An example of this is presented for the Place Key=’wStapenhill’ in the STEMMA Example section. The <Creation> and <Demise> elements can detail when a place was first defined, or ceased to exist. An example of this is presented below for Key=’wJessamineCottages’.
Q: Should place-type be time-dependent? we avoid the change of status of many towns to cities by having a single term (Town) for both.
Complex issues such as places being split up, or joined together, or having some other type of connection to a different place, are handled using the <SplitTo> elements (in Demise), the <JoinFrom> elements (in Creation), and <RelatedTo> elements. More details can be found at: Related Entities.
By contrast with the place-type, the place-category is looser. It does not constitute a hierarchy, and the values are not necessarily subordinate to place-type. The following values are currently defined: Cemetery, Church, Hospital, School, Ship, Prison, and Workhouse. Again, see Extended Vocabularies for defining custom place-categories.
Custom properties can be used as in the following illustration (see Extended Properties):
<Dataset Name=’Example’ xmlns:x=’http://superproduct.com/properties’>
<ExtendedProperties>
<PlaceProperties>
<PropertyDef Name=’x:Ward’ Type=’Text’/>
</PlaceProperties>
</ExtendedProperties>
<Place Key=’wJessamineCottages’>
<Title>Jessamine Cottages</Title>
<Type>Street</Type>
<PlaceName> Jessamine Cottages </PlaceName>
<ParentPlaceLnk Key=’wNottm’/>
<Demise>
<Eventlet><When Value=’1956’/></Eventlet>
</Demise>
</Place>
<Event Key=’eCensus1901’>
<SourceLnk Key=’sCensus1901’>
<PlaceLnk Key=’wJessamineCottages’>
<Property Name=’Parish’> Nottingham St Nicholas </Property>
<Property Name=’x:Ward’> Market </Property>
</PlaceLnk>
</SourceLnk>
</Event>
Some notes on various other properties that are often associated with a place or an address (see also the contact details support under Contacts):
Postal code
Postal codes or zip codes differ widely between countries and so can only be handled as plain strings. Some are based on geographical coordinates while others are based on postal sorting offices zones. At the time of writing, some countries did not have such a system, and Ireland only launched one on 13 July 2015, so it should never be mandated.
Telephone numbers
All stored telephone numbers should be fully international. The E.164 standard specifies how to represent an international telephone number, e.g. +15551234567. It does not specifically separate the ISD country dialling code, trunk code, or subscriber number. Also, it does not represent any trunk prefix required within that country. Formats such as +44 (0)1728 123456 should be avoided as the parenthesised trunk prefix is a UK/Ireland-centric way of representing numbers. E.123 is similar to E.164 but allows for some restricted punctuation for readability. Presentation differs greatly between countries but formatting them for a given locale has never been provided as part of software locale systems; it has always been added as an extra layer on top.
Geographic Coordinates
ISO 6709:2008 supports point location representation through the use of XML but, recognizing the need for compatibility with the previous version of the standard, ISO 6709:1983, it also allows for the use of a single alphanumeric string. The ISO string representations can be concatenated to generate an ordered set of coordinates for describing a polygon, and it is therefore used in the Place entity’s <Location> element. In general, the coordinates for well-established places should be left to a Place Authority rather than duplicated in all instances of personal data.