Many public sector organisations maintain registers of spatial objects such as regions, streets, addresses, buildings, cadastral parcels etc. These registers attribute identifiers to spatial objects; allowing to unambiguously refer to them in information exchanges. This blog explores whether base registers should provide HTTP-based Uniform Resource Identifiers (URIs) for location objects. It also sketches which role the INSPIRE specifications and the Core Location Vocabulary can play.
Unlike notations, identifiers unambiguously denote a location. For example, the street name ‘Maria-Theresiastraat’ could denote a street in both the cities of Brussels and Leuven. Within the context of a particular identifying system, symbols like ‘9346’ can do away with this ambiguity. In many EU Member States, public administrations maintain registers of spatial objects such as regions, streets, and addresses. These registers are the authentic source of location objects. Any change (e.g. change of street name) is often only official (non-opposable) once it has been recorded in the base location register. Example of such registers is the British National Street Gazetteer, the Dutch Basisregistraties Addressen en Gebouwen (BAG), or the Flemish Centraal Referentiebestand Adressen (CRAB).
A consensus on using common identifiers greatly improves interoperability when exchanging information about locations. The INSPIRE conceptual model is a binding specification for public administrations and allows for the interoperability of identifying systems based on namespaces, local identifiers, and version ids. Since the publication of the INSPIRE conceptual model, the Linked Data movement has gained much momentum. In this context, we see HPTTP-based Uniform Resource Identifiers (HTTP URIs) being used as location identifiers. Initiatives such as geonames.org attribute URIs to location objects. The HTTP URI ‘http://sws.geonames.org/6255148’ denotes for instance the European continent. In May 2011, the British Chief Technology Officer Council published a report entitled ‘Designing URI Sets for Location’. This report provides guidelines for the assignment of linked-data URIs for the publication of spatial objects. The guidelines incorporate the notion of INSPIRE object identifiers and the INSPIRE conceptual structure.
If base location registers adopt HTTP URIs for identifying spatial objects, their data will essentially become part of the Linked Data Cloud on the Web. The figure below depicts three generic use cases that can be applied to spatial data sets with HTTP URIs:
- Disambiguate notations: A first generic use case is to consult a base register and obtain an identifier (preferably an HTTP URI) for a location based on its notation and possibly additional information.
- Link data sets via identifiers: Based on the use of common identifiers for location objects it becomes possible to easily link disparate datasets.
- Look up (de-reference) identifiers: A single HTTP URI can be used by anyone to retrieve further information about spatial objects. This simple Web mechanism allows not duplicating information that is already known in the base register.
The aforementioned generic use cases apply in many different contexts and are useful to many different stakeholder, including the emergency services, law enforcement agencies, environmental licensing agencies, postal services, property tax administrations, cadastre, utilities, ... For all these, the use of common identifiers that can be de-referenced on the Web greatly facilitates the efficiency and effectiveness of information exchange.
This will not happen without careful consideration and investment of time and resources. Base registers will need to design their own INSPIRE-compliant URI sets. They will need to define a persistent URI policy, ideally guaranteeing that URIs will still exist in 20 years time. They will also need to employ an HTTP URI infrastructure that allows retrieving information about the spatial objects using various representation formats, such as HTML, JSON, XML, RDF-XML and various representation languages such as GML, the Core Location Vocabulary, NeoGeo, etc. The business case undoubtedly is strong enough to justify this effort.