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.
City/Location: Brussels
Comments
Thanks for the article. We're currently considering creating a new data model in Malta for core areas, such as Location and Person.
For Location, our main baseline is INSPIRE but of course we are also looking at the Core Vocabularies. Among other things, the latter states the following in terms of compatability with INSPIRE (bold added for emphasis):
Some questions:
Thanks a lot for your relevant questions. We have discussed this briefly with the INSPIRE Commission Team, which co-chaired the Working Group on the Core Location Vocabulary.
1. Should a new address model (implemented by the address registrar) be based on INSPIRE or Core Vocabulary? (Seems that INSPIRE is the natural choice since it's a superset)
You are right INSPIRE is the natural choice. The Core Location Vocabulary is to some extent a subset of the INSPIRE Data Specifications on Addresses, as it based on the INSPIRE AddressRepresentation class. Another aspect is that the INSPIRE data specifications are legally binding. This means that Address Registrars should provide their data according to the INSPIRE data specifications. Data that is INSPIRE-compliant is also compliant to the Core Location Vocabulary. The reverse is not true.
2. How does the above relate to the approach of using URIs as address identifiers? Does this imply that address registrars would need to maintain at least two identifiers, i.e. URI and UUID?
The INSPIRE identifying system is defined in the INSPIRE Conceptual Model. In the latest version of this specification, pending changes are mentioned with regard to the Identifier type and the inclusion of URIs. The specification of the UK Government ‘Designing URI Sets for Location’ also discusses how to mint INSPIRE-based URIs. This might mean that address registrars do not need to do away with existing identiying systems and that it will most likley be possible that one can be converted into the other.
3. If an address is based on the INSPIRE model, for what situations will the Core Vocabulary be used?
We see two levels of actors and use cases:
Where the INSPIRE Data Specifications on Addresses are a good starting point to tackle the first level of use cases, the Core Location Vocabulary is a sufficiently meaningful subset to deal with the second level of use cases. In summary, we believe that the Core Location Vocabulary is oriented towards the "consumer" of location data. In the next few months, we will give support to pilot projects that want to demonstrate the usefulness of this approach. The proof is in the eating...
The idea of assigning Web identifiers to addresses is further explored in this linked data pilot: Core Location Pilot - Interconnecting Belgian Address Data. The pilot demonstrates also that a Linked Data layer can be built on top of an existing INSPIRE implementation with a minimum of effort, thus facilitating the cross-sector re-use of INSPIRE resources.