Address data maintenance
Few of the reviewed standards delve into processes and procedures for address data maintenance; however, the standards that do include this information could provide optional guidance. The information available is comprehensive and likely would be helpful.
If this project recommends the development of a conceptual model, processes and procedures for maintenance should be included because address data are difficult to update and maintain. Any guidance that can be provided by experts would prove helpful but enforcing compliance to address data maintenance is impossible.
Quality management
All address standards support quality of addresses, for example, by ensuring the existence and accuracy of the components of an address. In this review summary quality management refers to the procedures and measures for the development, maintenance and communication of the quality of an address.
Quality management is included in some of the standards, although not all have a specific section labelling it as such. Core elements addressing data quality that can be seen in multiple standards include attribute accuracy, logical consistency, completeness, positional accuracy, and temporal accuracy. One, some, or all appeared in multiple standards.
Addresses are difficult to manage, and where a conceptual model can provide guidance for at least basic quality management, it should be included.
Life cycle
The address life cycle tracks the temporal phases, status and versions of an address. It does not appear in all standards, but there is consistency amongst those standards in which it does appear. All standards that cover the life cycle of an address name some form of potential, proposed, active, and retired elements for documentation. It is universally agreed that temporal tracking of addresses and addressable objects is a critical element in address development and maintenance. Each change to an address or its components must be documented so that one can understand that different versions of some or all elements relate to the same addressable object. The changes do not necessarily have to be physical changes, although they also require tracking.
Following are examples of common changes in an address that can cause confusion without life-cycle documentation:
- A developer designs a subdivision and the address appears on the plans. The date the plans are filed with the county planning board is assigned as the ‘proposed’ date for each address that appears on the plans. The address receives an ‘active’ date when physical construction commences, or an occupancy permit is approved. Thirty years later, the houses are taken by eminent domain to widen the road. The addresses are given an ‘endLife’ or ‘retired’ address date.
- The property owner of a single house along a street subdivides his property. Multiple houses are built along the street on either side of the original house. The municipality assigns sequential address numbers to all houses along the street, changing the address number of the original property.
- The street type for an address is erroneously recorded as ‘Canterbury Court’ instead of ‘Canterbury Boulevard’. The street type is corrected.
- The postal service changes the postal code to reflect new delivery patterns.
When a unique identifier is associated with each address, and changes are versioned and dated, and the status is documented, one can track different iterations of an address and be confident that each relates to the same addressable object.
Address aliases
Addresses and address components exist in multiple forms. Address data sets must store these alternatives together with their attributes and keep appropriate relationships between them. This calls for the standardization of data structures, terminology and classification for managing multiple addresses of the same addressable object or aliases of the same address component. There are various kinds of aliases, resulting from the diversity of languages, writing systems, urbanization progress, changes to address assignment schemes and specific service requirements, etc.
The reviewed standards support address aliases by:
- the specification of one address form as principal and other as secondary (SANS 1883-3, US FGDC Address);
- the specification of structures for storing addresses in multiple languages (SANS 1883-1);
- the specification of structures for storing addresses in multiple scripts (INSPIRE Address);
- the specification of structures for storing historical and prospective addresses as well as address changes; and
- the provision of dictionaries of valid abbreviations (AFNOR XP Z10-011).
Sometimes multiple address forms are treated as equivalent, for example, in the case of multilingual areas in Belgium and Switzerland. Alternatively, one form of the address is considered as being principal or recommended. Moreover, some existing address reference data sets (e.g. US Zip+4, Royal Mail Alias Product, New Zealand PAF) provide aliases for specific address components that are valid only within the area defined by the postcode. For example, the Royal Mail Alias Product provides names of traditional, administrative and postal counties that have overlapping territories, and relationships between names are set via postcodes.
Managing address aliases is a daily task of people working with address data. Many standards support aliases although it seems that they do not necessarily provide data structures for representing all relationships between various address forms used in various use cases. It seems that various use cases require various structures and if they are specified in a single standard, care should be taken that the result is not an overly complex data model.
Definitive address datasets (reference dataset)
Definitive address datasets were not applicable in a number of the standards reviewed. Custodians may or may not be identified, or addressing may be decentralised within a country.
There is not enough of a body of known definitive address datasets for inclusion in this review.