Places

A place is not always the same as location. For example, an important place to a military unit is its headquarters (HQ). Although it moves from time to time, there’s really just one HQ for each unit. We can think about it as one place associated with many locations. There are philosophical fun and games to be had in considering the concept of place and the various relationships places might have to each other. Here, we’ll try not to get bogged down too soon.

Places are mentioned in historical texts. A simple first step is to consider the mention of a place as a label that names or describes it. See, for example, the list of WW1 places in this project. This might be all we need in some circumstances, or it might be the first rung on the ladder to a more esoteric model of place.

The same place can have many labels. We need to collect the different labels for a place, choose one of them to be ‘authoritative’ (the one to display on a map) and perhaps attach a description. We need to have a data structure for this. Here, we’ll use the Simple Knowledge Organization System (SKOS).

Geospatial data

Data about locations is geospatial data. The Open Geospatial Consortium (OGC) promotes geospatial standards and data sharing. These include a standard for “expressing geographic annotation and visualization” called KML. See Google’s KML Tutorial for details.

Locations

A location is what you need if you want to display a place on a map. If you push a pin into a map then the location is simply a point. A point has coordinates that position it on a map. There are various systems for geographic coordinates, but the most common is the World Geodetic System (WGS84).

As well as points, You may want to show lines or polygons on a map, which means that a location has a geometry. Lines and polygons are constructed from multiple points. A general location is therefore a set of points and a geometry.

Locations from Google Earth

To collect locations from Google Earth:

Locations from GeoNames

To collect locations from GeoNames:

Trench Maps

The Long, Long Trail has information on how to read a British trench map, together with links to trench map sources. Another useful resource is tMapper, which also lets you convert trench map references to latitudes and longitudes. The British Trench Map Ontology models trench maps and their relationships to WGS84.

Data

We need place names or, more generally, place labels. The simplest data structure is a list of labels. We can add more structure to our data by grouping together labels for the same place, and then perhaps providing coordinates. See, for example, the Baleen gazetteer formats.

The next step is to give each place an identity. This means assigning a unique identifier that can be used by a knowledge base to refer to that place. Ideally, this identifier is something that can be agreed and shared amongst researchers. See, for example, the WW1LOD municipilaties in the WW1LOD dataset from World War I as Linked Open Data. These assign a unique Uniform Resource Identifier (URI) to places, among other things, that can be used to discover more information about those places. Sources such as GeoNames and DBpedia use their own URI’s as identifiers, but will reference other equivalent URI’s they know about (often each others).

URI’s allow different researchers to know when they’re referring to the same thing, but we won’t always have them. If we can’t share identity through a common unique identifier, and a place name is ambiguous, then we must use a place’s associations and context as well its name to identify it. We can use SKOS to organise this contextual information.

We don’t need to get to a finished model of places in one go. We can gradually piece things together. Uncertain and loose associations may be useful in building a model, even if they aren’t correct. Models should be validated and tested as they are built. Discovering a mistake often means discovering something new and useful about the model.