The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: October 30, 2010
Markup Languages for Names and Addresses

This document contains a [provisional] short list of projects creating markup-based or markup-accommodating specifications for name and address data. Virtually all jurisdictions (international, national, regional) depend upon written standards and cultural practices for machine-processing of name and address data, of course. The activities surveyed here are some of the more prominent. Developers in the process of designing requirements or implementing solutions for treatment of names and addresses may find these activities worthy of investigation.

The document reveals what we would expect: abstract data models and corresponding markup models vary considerably, depending upon the particular features of interest in name and address: the mail delivery system does not care so much about the content of a name as does an archivist, genealogy specialist, or library science expert working on name authority control.


Extract from a news item of 2002-03-18:

As XML vocabularies, DTDs, and Schemas continue to proliferate, rising in number from hundreds to thousands, one feature remains consistent: markup models almost always provide some mechanism to represent name and address information for personal and corporate entities central to the application domain. XML markup schemes for name and address sometimes draw upon established standards or data models, but usually do not. For simple applications, a few data elements are adequate to represent the name of a person, corporate entity, or geographic location; for complex applications (e.g., criminal records and health records management, genealogical and prosopographical research, bibliographic name authority), dozens or hundreds of information objects are required to represent a name and its relationships over time. Similarly, simple forms used for collecting address information typically use a dozen data fields; specialized applications (e.g., land and property ownership, international postal mail, GIS-aware database systems) require hundreds of data entities to model the notion of address. Name and address data models are often deeply integrated into personal information database frameworks. Reconciling the different models is not easy because the problem domains are so different: variably-scoped information spaces and conceptual/analytical perspectives unique to different models give rise to fundamentally different factoring of the same or similar information into metamodels for discrete factoids. Models competent to support machine processing of internationally-standardized name/address data must reckon with linguistic variation and differing cultural conventions. Significant standards work now underway will provide the basis for some re-use of markup models across application domains, but we expect convergence to be slow. Ubiquitous computing levies new requirements to model features of 3-D physical location and recipient-authentication along with traditional address data.

A recipient's name may be treated as a mutable character string if the goal in the the real world is simply to ensure the physical delivery of a mailpiece to a certain residential address, for example. For other machine-processing goals, information management concerns relevant to name are considerably more complicated. Context, relationships, conditions, process, and transactional aspects may be critical to the model. So, for example, the airmail letter delivered to:

Mr. H. Potter
The Cupboard under the Stairs
4 Privet Drive
Little Whinging

created no end of problems. Much of the difficulty could have been averted had the database model, markup notation, and delivery process honored the more subtle but critical notions of recipient authentication and interiorDomicileLocation. No doubt, the local custom treated as entirely ignorable and semantically irrelevant the implicit markup: <addressLine1>The Cupboard under the Stairs</addressLine1>.

An example of heavy requirements for markup representation of name may be drawn from the domain of library automation, where (for example) the Anglo-American Cataloguing Rules has recognized authority. The AACR2 [1998] volume dedicates a full 100 pages (chapters 22-24, pages 379-479) to the topic of personal, corporate, and geographic names, offering guidelines for sub-element decomposition and aggregation adequate to support name authority control in a bibliographic context. You might need to know whether a personal name composed with a prefix "De" is Afrikaans, Danish, Dutch, English, Flemish, French, Italian, Portuguese, or Romanian; name processing (e.g. collation) varies in different application contexts. A reflex of this may be seen in the MARC 21 Format For Authority Data: Field List and MARC 21 Concise Format for Authority Data. Name and identity are handled similarly in the world of archival authority records; see ISAAR(CPF): International Standard Archival Authority Record for Corporate Bodies, Persons and Families, 1995.

With the advent of ubiquitous computing there are many new applications for address/location management (and "location" modeling). In HP's Cooltown project, for example, there is tight integration between physical location description (e.g., absolute location expressed in a 3-D coordinate system) and geographic location description based upon zip codes, street names, visual landmarks, service centers, buildings, floors, rooms, etc. As users become increasingly mobile, models for "address" will need to quickly accommodate additional notions of proximity, direction, accessibility/reachability, and "semantic" location. The delivery of both electronic and tangible goods will increasingly depend upon time-dependent addressing -- defined from the perspective of (mobile) computing devices and mobile users.

Finally, illustrating the idea that design of a (markup) model for "names and addresses" in the abstract is difficult (or impossible), see an excerpted draft version of the OASIS Web Services for Remote Portlets Specification version 0.85, where the Producer and Consumer "role" definitions need to draw upon name/address "User Information." Martin Bryan wrote in a comment: "...consider what happens if the Producer is Finnish and the Consumer is Japanese and both use their own languages to define their services. Now we have a real problem, which will only be solved if you introduce a multilingual ontology of mapped terms into the equation. The real problem, however, is how to do this dynamically, so that we can annotate recorded roles with 'related names from other sources' (e.g., record that someone has determined, by some off-line means, that A relates to B). Incidentally your address info structure in section 10 has not been suitably internationalized. You need techniques for defining subsections of what you call cities (e.g., Kensington, London) and for identifying blocks (both at street and house level) and subunits of buildings (flats or suites). For example, I have a friend in Roumania for whose address I need to identify the flat number, the staircase, the block on the road (unless you call Block 26 a name!) and the district of the town in addition to the fields you allow me to define once only if I want to send him something. It looks like I'm going to have to define more extensions than you do base fields, even though every different Consumer and Producer will have to define his own set of extensions for most of these :-(..."

Projects/Standards for 'Name and Address'

ASC/X12 Transaction Set 101 for Domestic Name and Address Lists

According to an overview presentation from Mabel Grein (United States Postal Service, Information Technology): "In 1996 the USPS began working with industry leaders and the Data Interchange Standards Association on an EDI standard (TS-101) for domestic name and address lists... TS-101 is a domestic address standard designed to facilitate the transmission of strung address lines or parsed address elements or a combination of both styles. TS-101 took a year and a half to be completed, approved and published." The work was completed under Product Data Subcommittee X12E which has since been disbanded and the effort transfered to the X12M Procurement and Distribution Subcommittee. The Transaction Set 101 [Transaction Set 101: "Name and Address List Message"] was supported by Triplex Direct Marketing, RR Donnelly and other mailing industry representatives, the United States Postal Service (USPS) the Department of Defense (DOD) and the Public Utilities Commission (PUC) who all had interest in using this message. Transaction Set (TS) 101 Name and Address Lists was approved in 1998 and will be updated in conjunction with the Universal Postal Union POC POST*CODE subcommittee effort to develop addressing templates that will be the basis for the business requirements of the Transaction Set (TS) 101 Name and Address Lists and the PROLST message. [corrected 2002-03-19 by Mabel Grein (USPS, Information Technology), updating an earlier presentation]

BS 7666 Spatial data-sets for geographic referencing

British Standard BS7666 "Spatial Data-Sets for Geographic Referencing" is a 4-part standard produced by BSI IST/36. An e-GIF XML schema for BS7666 was submitted to the e-GIF working group in 2001. This XML schema (with variants) is now being referenced widely by other XML schemas which require address elements (e.g. CECA XML Specification and other UK GovTalk/eGIF Schemas).


CEN/TC133/WG3 Postal services, Addresses and Automatic Identification of Items

The European Comité Européen de Normalisation (CEN, European Committee for Standardization) has a Technical Committee (TC 331) for Postal Services. WG 3: "Addresses and Automatic Identification of Items" is actively involved with the Universal Postal Union (UPU) in the development of address database standards.

CEN/TC 331 'Postal Services' has the following scope: the measurement of quality of service, hybrid mail, tracing, identification, encoding and physical characteristics of mail address data and forms -- in order to increase the interoperability of postal networks and improve the quality of service."

There is now good cooperation between the UPU Post*Code Group and the address database subgroup of CEN TC/331 WG 3. It is possible that the UPU standard could be an extension of the CEN standard (EN).

Description of CEN TC/331 Workgroup 3, from Convenor Holger Wandt: "European Standardization Committee (CEN) has established working group 'Mail Processing Operations' (WG3). Its subgroup 'Address Databases' develops a five-part standard which covers all the relevant aspects of the address and address data. The five-part standard deals with address components, physical representation [of address elements], electronic data interchange, validation, interpretation of address data. Note: In March 2000, Holger Wandt of Human Inference was invited to take the chair of the European Standardization Committee (CEN TC331/WG3).

According to definitions of Part 1, addresses have three levels of components: elements (the lowest layer), constructs (groups of elements meaningful especially for humans), and segments (logical portions of a postal address e.g., addressee specification, mailee specification, mail recipient dispatching information, delivery point specification)... The 'addressee' is the individual or the organisation intended as the eventual receiver of the postal item. The 'mailee' is the individual or the organisation intended as the responsible party for the postal item reaching the 'addressee'. Lastly, the 'delivery point specification' is the physical location where the postal item must actually be delivered." See some details in the December 2001 update Physische Repräsentation von Adresskomponenten and earlier in "International address standardisation developing rapidly."

In terms of Part 2 (physical representation), the group has studied: the components used; whether address lines are mandatory or optional; the length of an address line; the sequence in which the components occur; address components that exclude the use of other components; whether and where there are abbreviations; whether and where abbreviations are used."

In connection with Part 3 (Electronic data exchange) it is said: "In tandem with the physical representation, the team is also carrying out a study into the use of formal languages for the electronic exchange of data (including XML, ASN1). The standards commission is expected to decide to use a formal language to describe the exchange standard. It is obvious that representation and electronic exchange are very closely related, which is why the commission is now busy getting acquainted with the subject..."

Part 1 of the multipart standard from CEN TC/331 WG3 has been released for approval. A draft version is available online: CEN TC/331 N231. "Draft EN 00331015 Postal services - Address data bases - Part 1: Components of postal addresses. 2000-04-05. 19 pages. Comments were due July 07, 2000. See also N284: Comment resolution report for Draft EN 00331015 Postal services - Address data bases - Part 1: Components of postal addresses (document CEN/TC 331/N231). [cache N231]

CEN TC/331 Cooperation with UPU based upon Memorandum of Understanding between UPU and CEN:

MoU: "Co-operation in developing international standards for postal services took the next step with the signature of a Memorandum of Understanding between the Universal Postal Union (UPU) represented by T. Leavey, Director General, and the CEN represented by G. Hongler, Secretary General. If co-operation between both organisations is already taking place, the MOU is establishing a framework that will allow it to be significantly enhanced through defined processes and procedures, clear principles for related aspects such as mutual standards recognition and Intellectual Property Rights and the establishment of a Contact Committee in charge of supervising the implementation of the MOU and the cooperation between UPU and CEN." See "Signature of the MOU between UPU and CEN. Bern, 22 October 2001" in CEN/TC 331 Newsletter #9 (December 2001).

The MoU recognizes "(1) the competence of the Universal Postal Union to develop world-wide postal standards to enable better interoperability between postal networks and to serve the interests and business objectives of the Postal Administrations of the UPU and their partners and customers; (2) the competence of CEN to develop European postal standards to enable better interoperability between postal networks and better postal Quality of Service as provided by the 97/67 EC Postal Directive and the mandates it has received from the European Commission; (3) the need for mutual recognition between UPU and CEN according to their respective missions and powers in the technical standardization-related activities in relation to the postal sector; (4) the involvement of both organisations in common areas as well as in distinct areas of technical standardization work; (5) the growing need for common standards within the postal world, which should, wherever possible and appropriate, be adopted within both UPU and CEN, while avoiding copyright and Intellectual Property Rights (IPR) limitations and, as far as possible, any formatting and interpretation differences; (6) the need to closely monitor and control the timely development and approval of postal standards; (7) the need to involve, in the development of postal standards, all parties concerned, including postal operators, relevant industry players, consumers and regulators/ministries; (8) the standards approval processes that are in place within the respective organisations and which facilitate the development and formal recognition of any standards that are developed..." The MoU provides for Information through Liaison Status; Co-operation on Standards Development; Adoption by one party of standards developed by the other; Maintenance of standards.

See the text also at: "CEN - UPU Memorandum Of Understanding."

In December 2001, Original Part 1 on Components of postal addresses was [proposed to be] split: Address databases Part 1 - Components of postal addresses; Address databases Part 2 - Common file format; Address databases Part 3 - Components of postal addresses for existing printing rules. See the "Resolution CEN/TC 331/010/07/2001 taken by CEN/TC 331 on 2001-06-20. Location of the meeting (Budapest). The TC decided to split "WI 00331015 Postal services - Address databases - Part 1: Components of postal addresses" into 3 work items, with the following titles and target dates: (1) Postal services - Address databases - Part 1: Components of postal addresses; Track: Enquiry + Formal Vote (EN); Target dates: Stage 32: 2000-04 Stage 40: 2001-05 Stage 49: 2002-01; (2) Postal services - Address databases - Part 2: Common file format; Track: Enquiry + Formal Vote (EN); Target dates: Stage 32: 2001-12; Stage 40: 2002-04; Stage 49: 2002-12; (3) Postal services - Address databases - Implementation of EN 14142-1 - Postal services - Address databases - Part 1: Components of postal addresses - for existing address printing rules; Track: CEN report Target date: 2001-12. See CEN/TC 331 Newsletter Issue #9, December 2001. Pending 2002-02.

Note that CEN ENV 14014 on Hybrid Mail was adopted in 2001 and is now being implemented. [ENV 14014:2001 Postal services - Hybrid mail - Document type definitions for customer to operator: a common set of default tags.'] Its "HML" uses an XML syntxax. 2001'12: "WG 2 is promoting the use of the standard and is gathering field experience for the maintenance of the ENV. In the meantime, the Working Group is preparing for future work items, such as the hybrid mail test suite." See "Hybrid Mail Language (HML)."


ECCMA International Address Element Code

IAEC [International Address Element Code] is one of the ECCMA Code Sets. The Electronic Commerce Code Management Association (ECCMA) has a goal of "building and maintaining the global, open standard dictionaries that are used to unambiguously label information. The existence of these dictionaries of labels allows information to be passed from one computer system to another without losing meaning."

The International Address Element Code (IAEC) "is a schema that identifies the component data elements of a name and address. It is used to improve the distribution of name and address information and the formatting of international addresses for mailing purposes... Address templates specify the order in which name and address information will be displayed line by line. The templates, and the name and address elements are identified and stored in codified tables. The code tables are maintained by the Electronic Commerce Code Management Association (ECCMA)."

A full IAEC definition consists of four values: (1) The Class: a number denoting the class; (2) The Component : a code assigned by the Electronic Commerce Code Management Association (a neutral, not-for-profit body that manages the IAEC); (3) The Title: a small textual label describing the element's relevance; (4) The Description a full-length textual description describing the element's parameters and what it means.

Benefits of standardization: "Address Standardization gives a company the ability to compare names within a file and eliminate duplicate mailings. Address Standardization at the element level allows for intelligent abbreviation, rather than truncation, when dealing with address data that exceeds the available print area for an address line. Improved ability to deliver reduces waste and results in a lower cost for the Post and the mailer. Address templates assist checking whether an address is complete. Address templates identify necessary address components. We also use templates to specify the order of the address elements that make up an address. There is at least one template for every country. Some countries may have identical or similar templates..."

"The primary purpose of the IAEC hierarchical classification (EAEC) is to avoid duplication and to provide a tool for those responsible for classifying address components to easily identify the appropriate code within the IAEC table. The most important feature of the IAEC schema is that there should only be one occurrence of a component title or definition and each title and definition should be capable of being easily differentiated from all others. The order in the class and component levels is not significant, and the order of the words in a title does not imply hierarchy or importance. The EAEC is a two level hierarchical classification. The recommended representation of the EAEC is as one 2-digit and one 3-digit numerical value separated by periods: NN.NNN. The primary purpose of the ECCMA Address Element Identifier (EAEI) is to provide a sequence identifier to the IAEC table to allow for version control and cross table linking. The EAEI is linked to the title and definition of the classification and whereas the EAEC may change if a component is re-classified the EAEI is never changed. The EAEI is a non-significant sequential number assigned to every record in the IAEC table. The EAEI uses one value to represent a fully expressed two level EAEC." (from the IAEC Implementation Guide)

"As international address element and template information is gathered by the UPU this information will be added to the ECCMA - IAEC tables. Countries that have already built databases and have identified address elements will find this easier to do then less developed countries. Eventually, we hope that this work will reflect all of the world Posts." (from the May 2001 report of Mabel Grein (United States Postal Service, Information Technology)

IAEC table incorporated into the EGAS: "The ECCMA Newsletter of 2/28/02 included a special ballot to incorporate the IAEC (International Address Element Codes) table into the EGAS (ECCMA Global Attribute Schema) table. This change was proposed because essentially the IAEC codes are 'attributes' of people, places and locations; combining the two seems to make more sense than maintaining two separate tables of attributes. The changes were made to the EGAS table and scheduled for release with the April 15, 2002 version... The ECCMA Global Attribute Schema (EGAS) is a standardized attribute definition schema that is used to further define the attributes associated with a specific product or service."


  • ECCMA website
  • IAEC website [The International Address Element Code]
  • Code list (HTML format). See the original Public Version as a spreadsheet.
  • IAEC Implementation Guide. From Electronic Commerce Code Management Association, Technical Secretariat. 3 pages. [Implementation Guide source]
  • IAEC Technical Manual
  • Visual maps ["The webserver is a demonstration of System Inc.'s Visual Net product... This demonstration visualizes the Electronic Commerce Code Management Association's (ECCMA) taxonomies. This demonstration shows three different code taxonomies: the International Address Element Code (IAEC), which identifies the component data elements of a name and address; the Universal Standard Products and Services Classification (UNSPSC), used to classify goods and services; and the ECCMA Global Attribute Schema (EGAS), used to more closely define commodities found in the UNSPSC. See also the demo.
  • See also UN/PROLST

The Encoded Archival Context (EAC) Initiative

The Encoded Archival Context specification provides a formal method of "encoding descriptions of persons, corporate bodies, and families responsible for the creation of records and other resources, where such descriptions provide context for understanding and interpreting the records and resources." Edited by Daniel V. Pitti (Institute for Advanced Technology in the Humanities, University of Virginia), this proposed metadata standard complements other standard formalisms governing name authority control for personal and corporate entities. EAC data are designed for use in federated database applications and collaborative research across a broad range of domains, including prosopographical research and genealogical studies. The designers intend that intellectual content of EAC records comply with the International Standard Archival Authority Record for Corporate Bodies, Persons, and Families. EAC is also "complementary to the UNIMARC/Authorities format, combining bibliographic authority records and archival authority records, which give information both about the creator and the context of creation of archival material..."


EURADIN: European Addresses Infrastructure

The EURADIN (European Addresses Infrastructure) Project, according to a July 31, 2008 announcement posted to the EUROGI web site, is "a Best Practice Network (BPN) cofunded by the EC eContentplus Programme (ECP-2007-GEO-317002) after a successful proposal submitted under the 2007 call. It aims to create a network for promoting the harmonization of European Addresses, focusing on how to access existing related data and to make it interoperable, as well as to define a strategy for building up access services to national or regional addresses infrastructures. The project main result will be the proposal for the European addresses Infrastructure and the implementation, testing, and validation of a pilot solution. The results shall be used as a reference for all European Member States to fulfil the INSPIRE recommendations with respect to addresses. EURADIN is a 24-month project, led by the Government of Navarra (Spain), initiated in June 2008 and gathering 30 partners from across Europe and different profiles. The kick off meeting took place on June 16-17, 2008 in Pamplona, Navarra, Spain. After a long time commitment to the Addresses issue, EUROGI strongly supported the EURADIN since its very beginning, being one of the partners and the leader of Work package 9 on Networking and Dissemination... The project will be considered successfully if the results achieved would be used as a reference for all European Member States to fulfil the INSPIRE recommendations with respect to addresses."

The specific objectives are the following (from INSPIRE):

  • To establish a wide European Best Practice Network of addresses stakeholders which will continue its labour and activity after the project end.
  • To aggregate the critical mass of content to ensure that valid conclusions are obtained from the project results.
  • To aggregate the existing best practices related to addresses definition, registration, and maintenance, in order to analyse, select, synthesize and document the best ones.
  • To deliver a proposal for the harmonization of European Addresses (Data, Metadata, Data Flow and Business Model) based on the available INSPIRE specifications and implementing rules.
  • To make the validation of the proposed harmonization model and Addresses Infrastructures through the development of a Pilot European Gazetteer Service giving access to the addresses of several European countries and/or regions.
  • To make an overall assessment and evaluation of the results obtained the project success, and the impact achieved.

Background (from the Abstract

INSPIRE Directive lays down general rules for the establishment of an infrastructure for spatial information in Europe, based on Spatial Data Infrastructures created by the Member States and that are made compatible and interoperable. Addresses are part of Annex I of INSPIRE, and will therefore be part of the aforementioned European Spatial Data Infrastructures.

Formally, addresses serve several purposes, and the NEN5825:2002 describes 4 functions for addresses: Location function (e.g. for the delivery of mail), Identification function (e.g. in context of a building registration), Jurisdiction function (e.g. which authorities are responsible for object attached to address) and Sorting and ordering function.

Due to the important functions they are used for, over the last decade it has become commonly acknowledged that good address systems constitute a very important part of a society's infrastructure. A good address system and the availability of high quality address data is for the benefit of [...] Governance, Business, Citizens...

Ideally, an Addresses Infrastructure (with a regional, national, European or global coverage) should allow accessing all the existing addresses via a central access point (this does not imply that all the addresses should be centralized but that the access to all addresses could be done via single central hub), and the addresses data should be adequately actualized and of course geo-referenced.

Given the self-evident importance of an Addresses Infrastructure as a useful tool for public and private services, it is logical to expect the European Union should have an adequate European Address Infrastructure allowing the access in a seamless and interoperable way to all the existing European Addresses for all the potential users. Following the INSPIRE directive philosophy; we believe that this European Addresses Infrastructure should be based on those existing national addresses Infrastructures distributed across Europe...

At this moment, nothing that could be considered as a European Address Infrastructure exists. From a European point of view, the lack of harmonization regarding European addresses definition, registration and access, prevents a European Addresses Infrastructure from being built, which consequently means that addresses cannot be adequately and extensively used, shared and exploited by European public and private sector..."

Some figures about EURopean ADdresses INfrastructure. Acronym: EURADIN. Starting Date: June 1, 2008. Finishing Date: May 31, 2010. Partners: 30. Countries: 16. Maximum EC Funding: 3.200.000 Euros. Program: eContentplus 2007.


GCA/Idealliance Address Data Interchange Specification (ADIS)

Updated information on the ADIS Working Group is available in the main reference document "Address Data Interchange Specification (ADIS)." The electronic distribution includes the database file formats, the XML DTD, sample XML data, and a narrative description.

Address Data Interchange Specification (ADIS). An Industry Standard for Domestic and International Address Management and Mail Production Using Address Element Technology. GCA Standard 105-1986, Version 01-1. Edited by Mabel Grein (United States Postal Service, Information Technology), Phil Thompson (Quad/Graphics), and Noel Wickham (Experian). From Graphic Communications Association (GCA). April, 2001. 96 pages. First version: 1986. Pages 21-25 supply the XML DTD for ADIS Version 01-1. Appendix I: Additional CEN Elements. Appendix II: Additional PROLST Elements. Appendix III: Templates for USPS Addresses. Appendix IV: UPU Standards Board Resolutions. The document "is meant to make a contribution toward the objectives approved by the Standards Board of the Universal Postal Union in its two [2001] resolutions pertaining to the topic of international address standardization." The section on "ADIS and Related Specifications" discusses compatibility with PROLST, ASC/X12 TS101, CEN/TC331 address standards, UPU POST*CODE project deliverables, ECCMA International Address Element Codes, etc. Note: GCA is now IDEAlliance. [source, IDEAlliance]

Joe Lubenow (Lubenow Associates) serves as Chair of the IDEAlliance ADIS Project and Chair of the Addressing/Distribution Committee.

An ADIS tutorial [taught by Joe Lubenow] was offered in connection with the IDEAlliance 2002 Addressing/Distribution Conference (A/D 2002). March 19-21, 2002. Sheraton Sand Key Resort, Clearwater Beach, FL, USA.

From May 2001 presentation of Mabel Grein (United States Postal Service, Information Technology): "Where Does ADIS Fit In? The GCA ADIS standard is being developed to support address element technology and to support the common line by line addressing style most companies are using today. ADIS also incorporates information that printers require. It is fully compatible with the domestic EDI address standard TS-101. ADIS can support PROLST: PROLST is a fully parsed address format. If the data is parsed in ADIS then ADIS and PROLST are also fully compatible. The difference between PROLST and ADIS: The ADIS standard transmits not only name and address information but printer oriented information as well. Functionally, TS-101 and PROLST were vehicles for exchanging name and address list information..."

"The Graphic Communications Association (GCA) is working on an international address standard, Address Data Interchange Specification (ADIS). The ADIS project shares the CEN goals and objectives, with an additional focus on non-address related postal information that may appear on a mail piece." [UPU resolution 2001]

HR-XML Consortium Cross-Process Objects Schemas

The HR-XML Consortium Cross-Process Objects Workgroup was chartered "to develop a common HR vocabulary and model for the Consortium and to develop schemas for common HR objects used across the Consortium's domain-specfic workgroups (Recruiting and Staffing, Benefits Enrollment, Payroll, etc.) The Cross-Process Objects Workgroup oversees teams that work on models and schemas for common HR objects, such as the many attributes of the Person object that must be handled consistently by different HR processes. The first two objects defined by the CPO and approved by the HR-XML Consortium's membership are PersonName and PostalAddress... [CPO web page]

References for V2.2:

PostalAddress 1.2. HR-XML Consortium Recommendation 2001-Oct-16. Version: PostalAddress-1_2. Edited by Kim Bartkus, Paul Kiel, and Mark Marsden. Authors and contributors from the HR-XML Cross-Process Object work group. 27 pages. HR-XML PostalAddress 1.2 [2001-Oct-16] "prescribes the form of the PostalAddress object used in HR-XML specifications. This update provides a version in XML Schema as well as in DTD. The document provides all necessary documentation for PostalAddress, including schema/DTD, definitions, and examples... The Postal Address schema attempts to create a generalized container that will allow business processes to pass address information reliably and completely, and in a format that can be efficiently processed. To this end, the container is to be designed to clearly house the various sections that make up a postal address as it is used from country to country, while allowing the country code to indicate to the business process how the address is to be formatted, according to local postal rules. Scope: The project will define the Postal Address, which may be used to globally send mail to individuals or organizations; The deliverable will be a schema, which may be transformed by a system to a format required for mailing; Internal routing will not be defined as separate elements. Information such as mail stop will be included as part of Recipient; the project will not define a location or geo code -- these codes typically define latitude and longitude locations; Effective dating will not be addressed within this proposal -- when effective dating is resolved, this proposal will be re-evaluated to assess the impact; this proposal does not recommend nor imply how an address should be stored in a database; it also does not address sorting or reporting formats for an address." See:

PersonName 1.2. HR-XML Consortium Recommendation 2001-Oct-16. Version: PersonName-1_2. Edited by Kim Bartkus, Paul Kiel, and Mark Marsden. Authors and contributors from the HR-XML Cross-Process Object work group. 25 pages. HR-XML PersonName 1.2 [2001-Oct-16] "prescribes the form of the Person Name object used in HR-XML specifications. This update provides a version in XML Schema as well as in DTD." The document "provides all necessary documentation for PersonName, including XML Schema, definitions, and examples... The design goal was to "create a schema design for a person's name that is flexible enough to be a global standard, which may be used within other HR-XML Consortium schemas... Almost all HR Business processes pass information regarding individuals, the most common data being the person's name. Names have many components, and these components may vary by country or ethnicity -- a Latin American name is very different from a Chinese name. Names may vary by purpose as well. For example, a resume for a performer may contain both a professional name and a legal name. Many business processes today either treat names as a monolithic string, or force names into first/middle/last components. This PersonName schema attempts to represent names for a broad array of cultures and purposes so that business processes can pass names reliably and completely, and in a format that can be efficiently processed..." See:

ISO/TC 211/WG 7 Project 19160 Addressing

"ISO 19160 Addressing, [was initiated as] a stage zero project for preliminary work on address standardization was proposed and approved, and a first project meeting was held in November 2009 in Québec, Canada. The project has two objectives: (1) Investigate and formulate requirements in relation to addressing (2) Make recommendations on whether standards should be developed and if so, how this should be done. The project's justification points out that addresses lie between geographic information, electronic business and postal systems, amongst others, and therefore, quite a few stakeholders are involved. Most of these either participate in, or are aware of, ISO 19160... Addresses are one of the most common ways of describing a location and because of the network of similarities, there is ample room for misunderstanding. The objective of ISO 19160 is to make recommendations on how to eliminate these misunderstandings. One solution could be an overarching abstract address standard comprising different parts, each addressing a different set of similarities, thus enhancing the understanding of these similarities and improving interoperability..." And compare the summary document.

ISO 19160 Methodology: Review address standards; List addressing standardization requirements; Review address standards against these requirements; Assess international standardization requirements; Propose international standardization requirements.

Provisional (draft) recommendations: ISO Standard for Addressing reference model (Terms and definitions; conceptual model in UML; ensure mapping from one implementation to another is possible creation and maintenance of address datasets). Implementations of the addressing reference model may include (a) addressing schema based on the reference model, (b) how to create and maintain a dataset based on this schema...

ISO/TC 211 addresses "standardization in the field of digital geographic information. This work aims to establish a structured set of standards for information concerning objects or phenomena that are directly or indirectly associated with a location relative to the Earth. These standards may specify, for geographic information, methods, tools and services for data management (including definition and description), acquiring, processing, analyzing, accessing, presenting and transferring such data in digital/electronic form between different users, systems and locations..."


Linking and Exploring Authority Files (LEAF)

LEAF (Linking and Exploring Authority Files) "is a three year project, started in March 2001, co-funded by the European Commission Information Society Technologies Programme and is developing a model architecture for a distributed search system harvesting existing name authority information aiming at automatically establishing a user needs based common name authority file in a specific sector highly relevant to the cultural heritage of Europe. The project results will be implemented by extending an existing, fully functional, international online Search and Retrieval service network of OPACs that provides information about modern manuscripts and letters, the MALVINE project, and to extend this into a global multilingual and multimedia information service about persons and corporate bodies based on user needs. The model architecture is intended to be applicable to other kinds of cultural/scientific objects and data, ensuring through the use of authority file information that the representation of the objects in question is one of high quality... LEAF is participating in the development of an XML format for authority records and archival context information - EAC (Encoding Archival Context). Results from testing the first version of EAC within LEAF will contribute to the development of the public version, which is expected to be launched in 2002..." Public deliverables include a Report on a Recommended Name DTD, Mapping between the name DTD and a name metadata set, a Report on the XML encoding, and conversion tools for the name data.


OASIS TC Name and Address Standard (xNAL) - Customer Information Quality (CIQ)

OASIS Customer Information Quality Specifications Version 3.0 includes formal definitions for Name (xNL), Address (xAL), Name and Address (xNAL) and Party (xPIL).

[June 27, 2007] In June 2007, OASIS announced that that the Version 3.0 CIQ Specifications had been released for second round of 60-day public review. CIQ Version 3.0 defines Name (xNL), Address (xAL), Name and Address (xNAL), and Party Information (xPIL) specifications. In addition to the specification and schemas, several additional documents are included: Frequently Asked Questions (FAQ); General Introduction and Overview; Package Overview; Release Notes; Technical Overview. CIQ supports party data (names, address and party centric information) irrespective of countries, cultures, races and geographical locations. Flat XML data models are used as opposed to complex hierarchical XML data models with supporting UML models. It provides the ability for user to define semantics to the data to meet their requirements without modifying the data model and thereby, ensuring the represented data conforms to the CIQ XML schema specifications. In CIQ one may use any code lists without modifying the CIQ XML schema specifications using the upcoming open industry standard for Code List, namely the OASIS Code List (Genericode) from the OASIS Code List Representation TC and the UBL Methodology for Code List Value and Validation. CIQ supports the ability to define business rules to constraint the CIQ XML Schema specifications without modifying the CIQ XML schema specifications using industry standard approach and industry standards. This feature enables users to restrict the CIQ data models to their specific needs and at the same time ensuring that the represented data conforms to the CIQ data models. A country can apply this feature to constrain the CIQ Address data model to its specific country address data model without modifying the CIQ Address model. One may use GeoRSS/GML from the Open Geospatial Consortium to represent location coordinates. References for CIQ Public Review Draft 02:

[2002] An "xNAL: Name and Address Standard" is part of the work being done in the OASIS Customer Information Quality TC . The objective of the Technical Committee (TC) on Customer Information Quality (CIQ) is to deliver XML standards for customer profile/information management to the industry. The committee is committed to developing XML Standards to represent Name and Address Data, Customer Information and Customer Relationships that are application independent, vendor neutral, open and importantly, 'Global'." Version 1.0 of xNAL Specification has been adopted by the TC as the Committee Specification.

As of 2002-03, the "xNAL" Name and Address Standard was under development in the OASIS Customer Information Quality Technical Committee. xNAL includes xNL as a Name Standard and xAL as an Address Standard. The 'Name and Address Markup Language (NAML)' was used as the basis for development of xNAL. The group's objective "is to develop a global standard for managing name and address data regardless of country of origin, to simplify things from maintainability point of view... They have broken up xNAL into two XML Languages: [1] xNL: eXtensible Name Language to define the name components, and [2] xAL: eXtensible Address Language to define the address components. This break up provides the flexibility to users of these standards to use one or both these standards depending upon their application environment..."

Development of xNAL is meant to address problems associated with name and address data, for example: "(1) Challenges in the treatment of name and address occur mostly during data entry. (2) Errors and discrepancies in customer information mostly occur during the consolidation of files from different lines of business. (3) The order in which address elements are naturally presented varies from country to country. (4) In some countries the house number is provided before the street name, in other countries the house number is given after the street name. For some countries the house number is essential to determine the postcode, for other countries a simple city input is sufficient. (5) Correct entry of an address in an international environment becomes heavily dependent on the knowledge of the person performing the data entry, or the ability to interpret the appropriate address elements..."

See further description and references in: "xNAL Name and Address Standard (xNL, xAL)."

SAMPLE: Single Administrative Message for Postal Enterprises

SAMPLE is supported by the European Commission IST Programme, Administrations Section. SAMPLE "aims to develop a standard, yet flexible, electronic interface between Posts and Customs authorities, with the potential to accommodate all countries world-wide. The system will provide a standardised method for electronic communication between countries... SAMPLE will specify and develop open-standard procedures and supporting systems for the efficient customs clearance of letter mails and parcels imported into or exported from Europe. The systems will transport, in a timely manner, data describing European in-bound and out-bound consignments from the exporting Post to both importing Post and importing Customs authority. The project will also: (1) implement and field trial these systems during the lifetime of the project, using both conventional (EDI) and emerging technologies such as XML that could, at reasonable cost, facilitate widespread use of the system; (2) actively promote the systems to the world-wide Customs and Postal communities and to international standardisation organisations... A major analysis phase will undertake a detailed study of Postal and Customs business functions to be supported by the system, and the complex international situation - in terms of various standardisation actions and trials - that can have bearing on the solution to be adopted. It will identify the information to be exchanged, its availability, sources of data and how it can be gathered, possible exchange protocols and legal and financial implications. Essential data elements will be mapped to EDI message segments, and the scope of necessary new data requirements will be clearly outlined. In parallel, the capacity of XML and associated internet solutions, including associated benefits and threats, will be analysed... SAMPLE has now analyzed and compared the Data Elements defined by G7, UPU/WCO, STEWOG Also the needs of various Posts, Couriers and Customs and taken these into consideration Combination of the Data Elements has been produced in the SAMPLE project..."

"... As a direct result of the innovations introduced, SAMPLE will produce the following key improvements: (1) facilitation of trade between the EU and the rest of world (2) novel use of XML by Postal and Customs Administrations (3) development of standard (subsets of) messages for XML and EDIFACT implementation, enabling easier transitions for new EU member countries.

A DIFFUSE report of November 2001 ("Information Society RTD Standards Implementation Report") said: "The IST SAMPLE project have developed a CUSDEC-compliant EDIFACT message for the interchange of customs information on packages imported and exported through standard postal channels. It is expected that the draft EDI standards produced by the project team will be fed into the standardization processes at UPU and WCO and then into ISO via CEN TC331 with the aim of obtaining formal approval and publication of the standard." See also the SAMPLE description from DIFFUSE.

"Message Specifications. CUSDEC for Postal traffic V1.0." Draft 5. Message Development Guide. Document release date: 21 November 2000. "This draft message specification is the result of a joint UPU/WCO effort to establish EDI standards with regards to Postal/Customs information exchanges. It is the intention that these draft EDI standards will be fed into the standardisation processes of the respective organisations, with the aim of obtaining formal approval and publication of the standard. It is furthermore the intention of the WCO and the UPU to enshrine this joint development eventually in a Memorandum of Understanding. This MoU should describe the intentions of both organisations to promote the usage of EDI exchanges between postal and customs partners in general, and the CUSDEC for postal traffic in particular... [refs G7 data element names]

Text Encoding Initiative

"The Text Encoding Initiative (TEI) Guidelines are an international and interdisciplinary standard that facilitates libraries, museums, publishers, and individual scholars represent a variety of literary and linguistic texts for online research, teaching, and preservation...

"... Personal Names: The core <rs> and <name> elements can distinguish names in a text but are insufficiently powerful to mark their internal components or structure. To conduct nominal record linkage or even to create an alphabetically sorted list of personal names, it is important to distinguish between a family name, a forename and an honorary title. Similarly, when confronted with a referencing string such as 'John, by the grace of God, king of England, lord of Ireland, duke of Normandy and Aquitaine, and count of Anjou', the analyst will often wish to distinguish among components giving some hint as to the status, occupation or residence of the person to whom the name belongs..."

Partial model:

  • persName contains a proper noun or proper-noun phrase referring to a person, possibly including any or all of the person's forenames, surnames, honorifics, added names, etc. - attr type describes the personal name more fully using an open-ended list of words or phrases which help to indicate the function, e.g. 'married name', 'maiden name', 'pen name', 'religious name', etc.
  • surname contains a family (inherited) name, as opposed to a given, baptismal, or nick name
  • forename contains a forename, given or baptismal name
  • roleName contains a name component which indicates that the referent has a particular role or position in society, such as an official title or rank
  • addName contains an additional name component, such as a nickname, epithet, or alias, or any other descriptive phrase used within a personal name
  • nameLink contains a connecting phrase or link used within a name but not regarded as part of it, such as van der or of
  • genName contains a name component used to indicating generational information, such as Junior, or a number used in a monarch's name


UK GovTalk Address and Personal Details Fragment

UK Online -- Information Architecture. Address and Personal Details Fragment. Version: 1.1. 1-March-2002. UK GovTalk/GSG/01. 18 pages. By UK Cabinet Office, Office of the e-Envoy. Edited by Adrian Kent (Office of the e-Envoy). Status: Under Test. Document Type: Specification. Includes support for BS7666. These Schemas are undergoing a 6 month test (until 1-August-2002). [source .DOC]

[May 26, 2003] UK GovTalk Address and Personal Details Schema. Status: Agreed Schema. Version 1.2. May 26, 2003. Filename: APD-v1-2. "A set of Address and personal details schema, including BS7666 version 1.2. These XML Schemas have undergone public consultation and have been agreed by the Office of the e-Envoy." Comments to See the file list. Sources: see the reference URL, ZIP archive [cache], and Address and Personal Details. Schema Changes 15-March-2003. Local display copies:

From the March 2002 APD document:

The Information Architecture Fragment defined here covers a Citizen's address and some basic personal details. Historically, it has been designed to specifically support a transaction in the life episode 'Moving House' called 'Change of Residence'. It may be used by one or more messages in that transaction. Also, some or the entire architecture fragment may be re-used in transactions relating to other life-episodes, and may be extended or updated to achieve this. This includes new residence, e.g., first time buyers, people moving to the UK from abroad and people giving up their homes, without any new address. Change of Residence details emanating from other sources, e.g., from line of business transactions within government, are not yet covered by this architecture.

Structure: The notational basis for the schemas used for the UK Government's UK Online information architecture is given directly, and by reference, in the introductory document to this series. It recommends the use of UML to represent the data and its relations, and the use of a mapping to the W3C XML Schema Definition Language (XSDL - W3C Schema). These XML schemas are used in turn for the representation of this information architecture in a syntactical form that can be used in the specification of messages that realise the interchange of data.

Usage: This fragment of the overall Information Architecture includes data structures for address, name, email and other contact details, plus some of the identifiers used by government departments such as unique tax reference, National Insurance number and several others. It is, therefore, expected to be widely used in the construction of messages for use within the UK Online system (plus any other systems that adopt the e-Government Information Architecture). It should be referenced and the data structures imported into messages wherever the data items covered in this fragment are required.

The UK Government is establishing the means for citizens and businesses to be able to transact business with the Government electronically. This will use a variety of delivery mechanisms such as the Internet, public kiosks', mobile equipment, and interactive television. This series of documents specifies the general information architecture for the overall system. This document specifies that part of this information architecture that is relevant to services and transactions, which involve change of address details for a citizen, and any others that require postal address, contact details and / or some of the common identifiers used by government departments and agencies and local authorities." [from the 'Fragment' specification 1.1]

The XML Schemas can be found in separate files; they have undergone a quality assurance check in accordance with the "Schema Guideline -- Best Practice Advice" document. Metadata has been included in these Schema between the <appinfo> tags.

The eGIF draft View Council Tax Account 'Schema Description' references the 'APD' namespace and markup models for name and address data. See (1) the XML Schema, (2) the requirements, (3) the description, and (4) example instances ex. 1, ex.2.

XML schemas for address components:

  1. AddressTypes_v1_0.xsd for Non-BS7666 and compound addresses. Uses the APD namespace
  2. PersonalDetailsTypes_v1_0.xsd for General data types relating to a citizen. Uses the APD namespace
  3. CitizenIdentificationTypes_v1_0.xsd for the various citizen references (such as electoral roll number) used in the public sector. Uses the APD namespace
  4. BS7666_v1_0.xsd for BS7666 address types. Uses the BS7666 namespace
  5. CommonSimpleTypes_v1_0.xsd for general types with relevance across the public sector; this Schema will in time become a core of re-usable types across e-government
  6. ContactTypes_v1_0.xsd for phone, email and fax data types.

Universal Postal Union (UPU)

The 189 member countries of the Universal Postal Union (UPU) form the largest physical distribution network in the world. Established in 1874 with its Headquarters in the Swiss capital Bern, the UPU is the second oldest international organisation after the International Telecommunications Union (ITU). UPU's goal is to ensure the organization and improvement of postal services throughout the world; it encourages international cooperation in the postal field, and provides technical assistance in all postal sectors as requested by its member-countries..." By virtue of its international status, UPU is the locus of significant standardization activity. The Standards Board (SB) "is the UPU's standards definition, approval, and maintenance authority in the area of postal standards. Its objectives are to provide strategic direction and to plan, develop and maintain standards aimed at improving postal telematics communications... the goal of the SB is to promote the interoperability and compatibility of all UPU and international postal telematics initiatives through the use of common standards." The POST*Info information database of the Postal Technology Centre (PTC) provides information about UPU's Telematics and technology activities and projects.

[June 17, 2003]   Universal Postal Union Publishes Approved International Address Standard UPU S42-1.    A communiqué from Joe Lubenow describes the publication of International Postal Address Components and Templates by the Universal Postal Union (UPU) as Standard S42-1. The specification had been approved by the UPU Standards Board for further testing in November, 2002. As summarized in Lubenow's overview document, the UPU address standard defines elements, address templates, and rendition instructions. Based upon CEN's "Components of Postal Addresses" specification the UPU standard defines a comprehensive list of name and address elements corresponding to "the smallest meaningful parts of names and addresses. This set of elements has been extended as necessary to cover additional situations, but so far has been sufficient to represent names and addresses in a number of non-European countries, including the US, taking account of some terminological differences." The UPU address templates define "unique combinations and orderings of elements, or in more general terms, address types, within a country. Templates in UPU S42 are described both in natural language and using an XML format known as the Postal Address Template Description Language (PATDL). Rendition instructions govern "the production of addresses on an output medium such as an address label or a computer display screen. Included in the standard is a registry of rendition instructions, which can be formatting rules for final presentation, including abbreviation and prioritization of data elements when there are constraints on available space." An IDEAlliance ADIS work group is developing an implementation of the UPU S42 standard within the broader context of business mail; ADIS allows address data to be described in XML and provides additional user options/extensions, while supporting all the elements of UPU S42 and the PATDL template description language.

[January 02, 2003] A 2002-11 communiqué from Joe Lubenow summarizes action taken by the Universal Postal Union (UPU) Standards Board on November 4, 2002: "[UPU has] approved testing of an international postal addressing standard developed with the contributions of the European standards organization CEN, the UPU POST*Code project, the UPU Direct Mail Advisory Board, the USPS sponsored International Address Templates Working Group (IATWG), and the IDEAlliance Address Data Interchange Specification (ADIS) project. The standard is being edited for publication and will soon be available from the UPU..." See also the Direct Mail Advisory Board Update (November 12, 2002) noting that the UPU Standards Board has given 'Status 0' approval for the UPU International Postal Address Standard, supported by the UPU Direct Mail Advisory Board (DMAB). This standard will identify and describe "all international address elements and structures." Contact Joe Lubenow, Chair of the DMAB Address Management Project Team [cache]

[April 26, 2002] "Postal Address Template Description Language (PATDL): A Contribution To An International Postal Addressing Standard." By Joe Lubenow (Industry Co-Chair, UPU DMAB Address Management Project Team). February 20, 2002. 27 pages. Included in a 2002-04-26 posting "Postal Address Templates" to the OASIS Customer Information Quality TC. With three appendices: Appendix I: The DTD defines version 1.0 of the Postal Address Template Description Language (PATDL). Preceding the main body of the DTD are comments that explain a number of technical matters not documented elsewhere, such as the syntax of the trigger conditions and the rules governing how they are interpreted. Appendix II: PATDL version of the template designed by Mabel Grein of USPS to represent the street address format using ECCMA codes and ADIS rendition instructions It has been validated using the Postal Address Template Description Language (PATDL) DTD. Appendix III: An annotated example designed to show many of the features of PATDL. It uses ADIS and ECCMA element codes and ADIS rendition instructions. There is an example of natural language element names with a CEN TC 331 element definer. It has been validated using the Postal Address Template Description Language (PATDL) DTD. -- "The intention of this paper is to discuss criteria that are relevant to achieving the goals laid down in these two [previous UPU] resolutions, to examine certain areas of progress in this effort, and to introduce the XML-based Postal Address Template Description Language (PATDL) that demonstrates how many of these goals might be met...The proposed Postal Address Template Description Language (PATDL) is currently expressed as an XML Document Type Definition (DTD). The core features of PATDL, such as the description of templates in terms of elements, the set of rendition instructions, and the trigger conditions, are presented in sufficient detail to support the development of a prototype reference implementation. Other features, such as the specification of character sets and external tables, are indicated but not developed..." Note from Joe Lubenow: 'This is a proposal made to the] Universal Postal Union (UPU) POST*Code project on postal address templates... The UPU seeks to define address templates on a country by country basis, and given lists of address elements, to determine whether actual addresses can be parsed into the elements, and passed though the templates, to constitute deliverable addresses. This method of describing templates also covers rendition instructions which are used to edit the addresses to fit into a vertically or horizontally constrained space such as an address label, called for as a second step in the UPU project. It is intended to support both single piece mail and business mailings. Elements and rendition instructions from multiple sources, such as OASIS, ECCMA, ADIS, etc., or natural language tags, can be used within the same template... comments or suggestions are very welcome.' [source]

In January 2001, the Standards Board of the Universal Postal Union (UPU) approved two resolutions "pertaining to the development of an international postal addressing standard. One calls for developing lists of address elements (the smallest meaningful parts that make up postal addresses, including individual and company names) as well as patterns, or templates, in which these elements are typically arranged. The second calls for developing standards for sending address data between parties using either traditional Electronic Data Interchange (EDI) or the newer World Wide Web based standard, Extensible Markup Language (XML). These resolutions have Status P, corresponding to a work proposal that must be more fully defined in order to move forward to the next status level." Bibliographic details are given below. [adapted from "International Address Management Issues Are Focus of a Global Effort," by Joe Lubenow]

UPU discussion from Mabel Grein's presentation May 2001: "Universal Postal Union Efforts: In January 2001 the USPS and Joe Lubenow representing the GCA and the UPU-DMAB joined forces, prepared and presented documents for two standards proposals (Status P) for the UPU. The purpose of these proposals was to: (1) Collect address elements; (2) Create EDI and XML messages. To begin the work on collecting address elements a survey was sent by the UPU POST*Code Technology task force led by Mike Murphy of the USPS to all member posts of the UPU. The purpose was to determine which countries had already identified address elements and to determine which countries desired assistance with developing this information.... [status May 2001: International address elements are being collected; US address templates have been developed; US address elements are in the ECCMA web site tables; US templates will soon be available in the ECCMA web site tables; White paper is in a draft state."

Summary of the January 2001 UPU [Brussels] proposals (supplied by Joe Lubenow): "The first resolution calls for the UPU POST*Code team to 'identify address and other related elements and apply standard definitions to these elements to facilitate the collection and exchange of International Name and Address Information. In the body of the resolution the goal of 'automatic formatting of addresses' is described. Some of the benefits of the project are briefly mentioned. The statement of scope calls for identifying and defining name and address elements. It next proposes an 'element by element order of presentation for each country', listing optional and mandatory elements. It then proposes that 'address element abbreviations and rendition instructions by country' and 'preferred and acceptable character sets' be specified. The second resolution was sponsored by the USPS and the Address Management Project Team of the UPU Direct Mail Advisory Board (DMAB). It calls for developing an 'EDI and XML message and procedure to facilitate the exchange and final presentation of International Name and Address Information. This resolution calls for a 'standard order of presentation or template for each country', using 'preferred and acceptable character sets'. This may take the form of 'EDI and XML messages to provide standard protocols for data transmission', but the resolution notes how EDI is evolving in the direction of XML. A goal is to allow 'printing rules and rendition instructions to allow formatting of addresses when constraints exist on available space'. It is further proposed to develop a 'reference implementation to illustrate the functions of the standard operations'. A technique is sought to evaluate address data sets 'in terms of completeness and correctness when measured against external data files', and to measure the proportion of addresses which meet quality standards..."

Proposal to Identify and Define Address Elements. Universal Postal Union Reference: CEP GAN 2001.1-Doc 3a (POC SB 2001.1-Doc 3a). Brussels, 30 January 2001. From the Post Operations Council Post*Code Project Team and the Post*Code "Technology Development" Sub-project Team Chaired by United States Postal Service (USPS). 4 pages. Summary/excerpt follows:

"A proposal for the acceptance of a standard to identify and define address elements to facilitate the collection and exchange of international name and address information as a new work item (Status P). This project includes identifying and defining international name and address information in consultation with the CEN, UN/EDIFACT subcommittees, UPU Standards Board, members of the UPU Direct Marketing Advisory Board (DMAB) and other interested member nations and parties... This document contains a proposal for the identification and definition of address elements and other related work items contained within UPU Congress Resolution C87 and tactic 4.3.3 of the Unions Strategic Plan to facilitate name and address information exchange as a new work item The POST*Code 'Technological Development' Sub-Project Team submits that this proposal supports the goal to make POST*Code more functional in relation to addressing by allowing the automatic formatting of addresses."

"Efforts are currently underway to create an international address standard in both the UN/EDIFACT Subcommittee and in the CEN as well as other efforts by the UPU's POC POST*Code Project team. To be inclusive and complete, all such efforts will require input from the members of the UPU. Therefore, it seems appropriate to formalize this project's status within the UPU standardization process and combine our efforts with those of the CEN and UN/EDIFACT.

This project proposes to: (1) Identify and define international address elements; (2) Define an element by element order of presentation for each country; (3) Note optional and mandatory address information; (4) Specify address element abbreviations and rendition instructions by country; (5) Determine by country the preferred and acceptable character sets.

Rationale: "With the advent of the Internet, companies that had been solely domestic enterprises have suddenly found themselves involved in international commerce. Cross-border mail is increasing substantially. Companies that developed customer databases based upon domestic addressing requirements are suddenly finding these databases entirely inadequate for the storage of multinational address information. To complicate the matter, international address information is not readily available, and what is available is frequently not maintained in a timely manner. This standard, developed by the UPU, would serve as a guideline for companies and posts to look to for assistance not only in maintaining international name and address information but also with exchanging and printing international address information. The mere fact that so many organizations are trying to develop international name and address standards is indicative of the need for the information."

[Implications of the standard for mailing operations:] "Instead of receiving address files on a line by line basis, with little certainty as to what data is to be found in any particular location, the data would be marked or 'tagged' with codes, so that the recipient always knows the structure and format. The data then is reassembled, using the templates and rules known as 'rendition instructions' to produce a particular address format for a specific job. This makes it easier to combine multiple files into one, and mailings for any number of countries can be handled in a single process. There are also advantages for mail production in this approach. The task of merging and purging addresses becomes simpler when all the data elements are identified in advance. When the space on a mailpiece is limited, quality can be maintained by sacrificing the less important elements and abbreviating others so as to preserve deliverability. Instead of creating a definite label or ink jet format that can no longer be easily modified, the data can be stored in a standardized format until the last moment, allowing for late modifications and increased flexibility." (from Joe Lubenow's IMAG article)

Proposal to Develop Standard EDI and XML Messages for Name and Address Information Exchange. Universal Postal Union Reference: CEP GAN 2001.1-Doc 3b.Rev 1 (POC SB 2001.1-Doc 3b.Rev 1). Brussels, 30 January 2001. From the United States Postal Service (USPS) and the Address Management Project Team of the UPU Direct Marketing Advisory Board. 5 pages. Summary/excerpt follows:

A proposal "for the acceptance of a standard to transmit international name and address data, defined as separate identified elements, among parties, including final presentation on a mail piece, as a new work item (Status P). This project will utilize address elements determined as the output from a separate work item led by a POST*Code team working in conjunction with the CEN, UN/EDIFACT subcommittees and members of the UPU Direct Marketing Advisory Board (DMAB).

"This document is a proposal for a new work item (Status P) to develop standard EDI and XML messages to facilitate name and address information exchange, including final presentation on a mail piece. The goal is to provide standard messages that utilize address elements defined and identified as the output of a separate work item to allow for greater clarity about the nature and characteristics of the name and address information to be transmitted. The standard messages will provide the capability for intelligent rendition of the name and address elements even when the mail piece cannot represent all the available information, in such a way as to preserve address quality and maintain mail piece deliverability. This work item falls within the scope of current efforts to create a comprehensive international address standard in both the UN/EDIFACT Subcommittee and in the CEN. The comprehensive standard includes definition and identification of named address elements, transmission of data between parties, rules for presenting data on the mail piece, validation of the address data, and procedures for converting data currently retained in block or line by line formats to the new element by element formats. To be inclusive and complete, both of these efforts will require input from the member posts of the UPU. Therefore, it is appropriate for this effort to be carried out under the overall auspices of the UPU standardization process in conjunction with the work of the CEN and UN/EDIFACT."

"The project aims to develop messages using two distinct protocols, which we designate as EDI and XML respectively, recognizing that in a generic sense both of these are forms of Electronic Data Interchange, or EDI... The reasons for using both EDI in the specific sense indicated and XML as protocols deserve further explanation. EDI in the specific sense is best suited for the transmission of data among parties with complex data processing infrastructures. On the other hand, when name and address data or mailing job data are currently transmitted, even between large companies, this is often done without reference to rigorous standards of any kind. It is unclear whether development of an EDI message in the specific sense will result in adoption rates that are sufficient for a widely accepted standard. At the same time, XML is achieving rapid growth in the area of Internet data transfers and is becoming a de facto standard in that arena. The best evidence for this is that EDI in the specific sense is starting to evolve in the direction of XML, taking the form of a hybrid often referred to as EDI/XML. However, native XML offers several advantages not available from translation of current EDI messages to work in an XML environment. These advantages include improved ability to constrain data values, better application portability, the availability of inexpensive or free development tools, and the existence of executable functions under XSLT that are defined wholly within the larger XML standard. For these reasons, it is advantageous to define the proposed standard using both the EDI protocol, which will allow for conversion in a straightforward manner to EDI/XML, and in a native XML protocol, incorporating XSL and XSLT for added functionality."

General References


From a January 2001 presentation of Mabel Grein (United States Postal Service, Information Technology): "Work commenced on the international address standard, PROLST, in 1999. PROLST was modified as a result of the input from the Paris meeting and was resubmitted at the Taiwan EWG meeting. PROLST was promoted to a UN/EDIFACT Message In Development (MID) status in September 2000. The UN/EDIFACT subcommittee has stipulated that the element codes for PROLST will be maintained by the Electronic Commerce Code Management Association (ECCMA). This enables the rapid turnaround that electronic commerce requires. The International Address Element Code (IAEC) tables used by PROLST have been propagated with all the US domestic, and some international, elements..."

2001-05 overview: "The USPS and mailing industry leaders began work on the international address standard, PROLST, in 1999. [The group presented its work] for the first time at the UN/EDIFACT meeting in March 2000 at the Paris EDIFACT Work Group (EWG) meeting. PROLST was approved as a UN/EDIFACT Message In Development (MID) in March 2000. The 'Electronic Commerce Code Management Association (ECCMA) - International Address Element Code (IAEC)' tables used by PROLST have been propagated with all the US domestic, and some international, elements. The eight templates identified for USPS addresses are outlined in the White Paper published on the ECCMA web site." [adapted from report of Mabel Grein, United States Postal Service, Information Technology: report 2001-05]

"PROLST is a UN/EDIFACT Message In Development (MID) for international name and address lists. PROLST is designed to simplify the collection and storage of multinational address information in one database in a manner that enables validation of many of the address components... An address is a structure composed of elements: house numbers, streets, Post office boxes, directions, street types, cities, countries, Post codes, states, provinces and so on. The good news is that the vast majority of addresses are composed of elements that are common worldwide. The challenge is to identify and define these elements in a common manner, then format templates can be designed for each country, for every type of address within each country... The codification of the individual elements allows the editing for content, or the abbreviation of the content. Each individual element may be placed in the appropriate position on the output medium (label, envelope, or file) based upon the country specific address format template. Codification facilitates an intelligent rendition of an address when the number of address lines or length of an address line exceeds the space available. Rendition Instructions will define how to consolidate and/or abbreviate address information to avoid truncation. This insures that the summarized address information retains the necessary information for the proper delivery of the mail piece and displays the address information in a manner that meets the local Post requirements... [from the Technical Report"]


  • "Why a Global Address Standard is Critical to Success in Direct Mail Marketing and Electronic Commerce. Using the UN/PROLST Version 1.1." UN/PROLST White Paper. May 2001. 21 pages. The United States Postal Service Publication 28 was utilized as a starting point for the IAEC naming convention for the tag labels; the codes in the International Address Element Codes (IAEC) were developed and propagated, using the names and definitions from publication 28. This document presents 8 templates for US domestic addresses: USA TEMPLATE 001 - Street Style Address; USA TEMPLATE 002 - PO BOX Style Address; USA TEMPLATE 003 - Rural Route Style Address; USA TEMPLATE 004 - Military Style Address; USA TEMPLATE 005 - Dual Address PO Box Primary/Street Secondary; USA TEMPLATE 006 - Dual Address Street Primary/PO Box Secondary; USA TEMPLATE 007 - Dual Address PO Box Primary/Rural Route Secondary; USA TEMPLATE 008 - Dual Address Rural Route Primary/PO Box Secondary. [source]
  • See also ECCMA International Address Element Code

US FGDC Address Data Content Standard

From the FGDC Summary: Street Address Data Standard of November 2006:

The United States Street, Landmark, and Postal Address Data Standard (formerly the Street Address Data Standard) is a draft data processing standard for United States address information. The draft standard defines and specifies elements and structures for creating and organizing address data, defines tests of address data quality, and facilitates address data exchange. An address, as defined in the draft standard, specifies a location by reference to a thoroughfare or landmark; or it specifies a point of postal delivery. The draft standard has four parts: Data Content, Data Classification, Data Quality, and Data Exchange.

The Data Content part defines the simple and complex data elements that comprise an address, and the attributes that describe those elements. Categories of data elements include: address number, street name, occupancy, landmark names, place names, and postal delivery points such as post office boxes. Attributes describe the address and comprise the record-level metadata for addresses. Categories of attributes include address identifiers, geospatial coordinate systems and values, address descriptors, address schema, dates of origin and retirement, data set, and address authority identifiers. For each element and attribute, XML tags and syntaxes are provided. The Data Content part also defines simple and complex elements. Simple elements are those defined independently of all other elements. Complex elements are combinations of simple or other complex elements...

The Data Exchange part defines an XML schema document (XSD) to provide a template for the data and metadata needed for address data exchange. It also provides information on preparing data for transmittal (normalizing and packaging) and receipt (unpackaging and localizing). Exchange modes are provided for monolithic (complete dataset) exchange and transactional (adds and deletes) exchanges. XML is used to make address data exchange simpler, more flexible, and more reliable.

The United States Street, Landmark, and Postal Address Data Standard has been drafted by the Urban and Regional Information Systems Association (URISA) Address Standard Working Group, with support from the National Emergency Number Association and the U.S. Census Bureau, for submittal to the U.S. Federal Geographic Data Committee. [archive/cache]

[May 07, 2003] "Address Data Content Standard Public Review Draft." Subcommittee on Cultural and Demographic Data, [US] Federal Geographic Data Committee (FGDC). Version 2. April 17, 2003. 41 pages. "Addresses provide a means of locating people, structures and other spatial objects. More specifically, addresses are used to reference and uniquely identify particular points of interest, to access and deliver to specific locations, and as a means for positioning geographic data based on location. Most organizations maintain address lists or have databases or datasets that contain addresses. In many organizations, the primary purpose for creating and maintaining address lists and address information is mail delivery. Organizations often have detailed specifications about the structure of their address information without defining the content, i.e., the elements that constitute an address within their system. Knowledge of both structure and content is required to successfully share information in a digital environment. The purpose of this standard is to facilitate the exchange of address information. The Address Data Content Standard (the Standard) simplifies the address data exchange process by providing a method for documenting the content of address information... The objective of the Standard is to provide a method for documenting the content of address information. As a data usability standard, the Standard describes a way to express the content, applicability, data quality and accuracy of a dataset or data element. The Standard additionally codifies some commonly used discrete units of address information, referred to as descriptive elements. It provides standardized terminology and definitions to alleviate inconsistencies in the use of descriptive elements and to simplify the documentation process. The Standard establishes the requirements for documenting the content of addresses. It is applicable to addresses of entities having a spatial component. The Standard does not apply to addresses of entities lacking a spatial component and specifically excludes electronic addresses, such as e-mail addresses. The Standard is to be used only in the exchange of addresses. The Standard places no requirement on internal organization of use or structure of address data. However, the principles of the Standard can be extended to all addresses, including addresses maintained within an organization, even if they are not shared..." [source PDF, also in HTML and .DOC format]

[December 2000] The Address Data Content Standard from the US Federal Geographic Data Committee [Subcommittee on Cultural and Demographic Data] represents the collaborative work of several US agencies in the development, use, sharing, and dissemination of geographic data. The purpose of the standard "is to facilitate the sharing of address information. The Address Data Content Standard (the Standard) accomplishes this by providing a method for documenting the content of address information and simplifies the documentation process by recognizing some commonly used discrete units of address information... The objective of the Standard is to provide a method for documenting the content of address information. The Standard is a Federal Geographic Data Committee (FGDC) data usability standard. Data usability standards describe how to express the applicability or essence of a dataset or data element and include data quality, assessment, accuracy, and reporting or documentation standards. The Standard additionally standardizes some commonly used discrete units of address information, referred to as 'descriptive elements'. It provides standardized terms and their definitions to alleviate inconsistencies in the use of the descriptive elements and to simplify the documentation process."


  • Street Address Data Standard. This standards project replaces the Address Data Content Standard project, which has been discontinued.
  • Overview of Draft Street Address Standard [cache]
  • [October 2006] Street Address Data Standard. Or: United States Street, Landmark, and Postal Address Data Standard. Executive Summary. Produced by the Address Standards Working Group (ASWG) through collaboration on a Wiki [TWiki.ADDRstandard] hosted by Statial Focus. October 2006. Final Draft. Reference: '06-09-17.ASWG.ExecSumm.Rev4a.doc'. 6 pages. Background: "This standard builds on the United States Postal Service (USPS) Publication 28, and on the Address Data Content Standard previously proposed by the Federal Geographic Data Committee (FGDC), Public Review Draft, April 17, 2003. The FGDC effort led the Urban and Regional Information Systems Association (URISA) to propose, with the support of the National Emergency Number Association (NENA) and the U.S. Bureau of the Census, the convening of a Street Address Standards Working Group to include representatives from a range of interested federal, state, regional, and local government agencies, the private sector, and professional associations. The proposal was accepted by the FGDC Standards Working Group on April 13, 2005. The draft standard is a product of the efforts of URISA and supporting organizations and individuals. See also the XML Schema [v0.3 source, v0.2]

    "Street addresses are the location identifiers most widely used by state and local government and the public. Street addresses are critical information for administrative, emergency response, research, marketing, mapping, GIS, routing and navigation, and many other purposes. Because they have evolved over many decades, under the control of thousands of local jurisdictions, in many different record and database formats, and to serve many purposes, different address formats and types pose a number of complex geoprocessing and modeling issues. As a consequence, government agencies struggle with these issues as they seek to integrate large, mission-critical files into master address repositories... The Street Address Data Standard provides, in four separate parts, data content, classification, quality, and exchange standards for street, landmark, and postal addresses: (1) Data Content specifies and defines the data elements that may appear in or describe street, landmark, and postal addresses. This part also specifies and defines attributes of addresses and their components. (2) Data Classification defines classes of addresses according to their syntax, that is, their data elements and the order in which the elements are arranged. (3) Data Quality defines quality tests of address data accuracy, currency, lineage. (4) Data Exchange describes how to exchange standardized address data between agencies and systems... This standard covers United States addresses that specify a location by reference to a thoroughfare, or a landmark; or that specify a point of postal delivery...

    Part 4 "Address Data Exchange" provides a template for the XML documents and metadata that will move addresses between systems, and it provides information on packaging and unpackaging street address data for exchange. The data exchange format will be in XML. XML was selected because: FGDC standards requires its use; XML protects content producers and content consumers from changing data; Field order is unimportant; Missing fields don't prevent exchanges; Extra fields don't prevent exchanges; XML is extensible — users can add other information for specific purposes..."

  • "U.S. Federal Geographic Data Committee (FGDC) Draft Address Data Content Standard for Public Review." Announcement May 2003.

  • "Address Data Content Standard." From: Federal Geographic Data Committee, Subcommittee on Cultural and Demographic Data. Public Review Draft. December 2000. 34 pages. [source .DOC]

  • Draft Proposal for a National Spatial Data Infrastructure Standards Project

US Postal Service

Mabel Grein of the USPS (United States Postal Service, Information Technology) has been involved in several address database projects (UN/PROLST, ECCMA) and is an editor of the ADIS 01-1 specification. The United States Postal Service contributed to two proposals made to the Universal Postal Union in January 2001: (1) Proposal to Identify and Define Address Elements; (2) Proposal to Develop Standard EDI and XML Messages for Name and Address Information Exchange. These proposals are referenced above.

Earlier summary from a 2001 conference on "Addressing Standards In The New Millennium": "[towards] a unique solution where all name and address information can be easily stored in a single, simple, standard format. The implications of this new standard are far reaching and will affect all systems that store and manipulate name and address data... Companies who create, maintain and have need to exchange name and address lists have, most often developed their own internal and unique formats. This causes difficulty when there is a need to exchange name and address information between trading partners and inhibits any realistic attempt to automate the exchange of this information... The U.S. Postal Service, ResolveNet and Triplex began work on a solution that resulted in the creation of an American National EDI Standard ASC X12.101 designed to facilitate the exchange of mailing lists and in 1999 the creation of the an equivalent international EDI standard, PROLST. Both standards included the ability to transmit parsed name and address information using the new International Address Element Code (IAEC) maintained by the Electronic Commerce Code Management Association (ECCMA). The IAEC tables include all the US domestic and most international name and address elements. The USPS is beginning work with the UPU to gather information regarding international elements and to define country-specific templates and sub templates. As international address element information is gathered by the UPU these elements will be added to the ECCMA IAEC tables and shared with organizations and standards bodies worldwide..."

See especially "Postal Addressing Standards -- Contents." Publication 28. November 2000. 129 pages. USPS Publication 28 was used as a starting point for developing the UN/PROLST standard.

vCard: Electronic Business Card

According to a vCard Overview, the vCard 'electronic business card' is "a powerful new means of Personal Data Interchange (PDI) that is automating the traditional business card. Whether it's your computer (hand held organizer, Personal Information Manager (PIM), electronic eail application, Web Browser) or telephone, the vCard will revolutionize your personal communications. Features: (1) vCards carry vital directory information such as name, addresses (business, home, mailing, parcel), telephone numbers (home, business, fax, pager, cellular, ISDN, voice, data, video), email addresses and Internet URLs (Universal Resource Locators). (2) All vCards can also have graphics and multimedia including photographs, company logos, audio clips such as for name pronunciation; (3) Geographic and time zone information in vCards let others know when to contact you; (4) vCards support multiple languages; (5) The vCard spec is transport and operating system independent so you can have vCard-ready software on any computer; (6) vCards are Internet friendly, standards based, and have wide industry support..."


General References


Contacts (address formats):

  • Mike Garner (United States Postal Service, Address Management)
  • Mabel Grein (United States Postal Service, Information Technology) [ECCMA, UPU]
  • Ram Kumar (MSI Business Solutions Pty. Ltd) [CIQ]
  • Joe Lubenow (Lubenow Associates) [ADIS, UPU]
  • Holger Wandt (Human Inference GmbH) [CEN]

  • [June 24, 2010] "What Address Standards Tell Us About Addresses." By Serena Coetzeea, Antony K Cooperb, Piotr Piotrowskic, Morten Lindd, Martha McCart Wellse, Ed Wellsf, Nick Griffithsg, Michael J Nicholsong, Ram Kumarh, Joe Lubenowc, Joe Lamberti, Carl Andersonj, Sara Yurmane, and Ruth Jonesk. From ISO Focus+ Section on ISO Online, Online Bonus Articles, June 2010. 29 pages. With condensed version: "More Than Location: What Address Standards Tell Us About Addresses." [alt location] In ISO Focus June 2010, Column "360° PDF file format, as cited in the OASIS CIQ TC list archives.

    Abstract: "An address is most often used to direct people to a delivery point. Standardizing addresses streamlines the delivery process, whether this delivery is for postal mail, emergency response, utilities (water, electricity, sewerage, etc.), financial services, or any other kind of service. Address standards have been developed and are being developed by a number of countries and organizations. The objectives of this paper are to present a number of address standards, to share experiences and lessons learnt from developing, as well as using, these address standards, and to analyze the standards systematically in order to better understand what an address is and what the purpose and benefits of different address standards are. We believe that such an analysis will contribute towards the understanding of what an address is and what the purpose of an address standard is; and we hope that the paper will also assist relevant stakeholders in developing and using address standards..."

    From the condensation: "We all use addresses to provide direction to a delivery point. In fact, the word address comes from the Latin directus, to direct. Postal systems for transporting written documents have been around since the invention of writing. In these early systems, letters were hand delivered from source to destination. In Europe, street addresses were first assigned in the 18th century when urban expansion created a need to identify individual buildings. An address can be considered the description of a location, not only for postal delivery, but for all kinds of distribution, ranging from physical services such as utilities, goods and emergency dispatch, to more abstract services such as credit applications, tax collection and land administration. Standardizing addresses streamlines the delivery process, with well-documented benefits for the economy, society and governance. Its benefits are not limited to interoperability of existing address data, but also provide guidelines to countries that are still developing addressing systems... We conclude that addresses do not have a single common feature but rather a complicated network of similarities overlapping and criss-crossing : sometimes overall similarities, sometimes similarities of detail...

    In 2008, ISO/TC 211 arranged a workshop, hosted and sponsored by the Danish National Survey and Cadastre, which looked at issues related to the development of an International Standard for addresses. Subsequently, ISO 19160, Addressing, a stage zero project for preliminary work on address standardization was proposed and approved, and a first project meeting was held in November 2009 in Quebec, Canada. The project has two objectives: (1) Investigate and formulate requirements in relation to addressing (2) Make recommendations on whether standards should be developed and if so, how this should be done. The project's justification points out that addresses lie between geographic information, electronic business and postal systems, amongst others, and therefore, quite a few stakeholders are involved. Most of these either participate in, or are aware of, ISO 19160... Addresses are one of the most common ways of describing a location and because of the network of similarities, there is ample room for misunderstanding. The objective of ISO 19160 is to make recommendations on how to eliminate these misunderstandings. One solution could be an overarching abstract address standard comprising different parts, each addressing a different set of similarities, thus enhancing the understanding of these similarities and improving interoperability..." [cache/archive]

  • [June 23, 2010] "Draft Review Summary of Project 19160, Addressing." ISO/TC 211. Geographic information/Geomatics. ISO reference number: 19160. Source: ISO/TC 211/WG 7/PT 19160. 2010-06-22. 53 pages.

    "Scope: This review summary is a report of the work done as part of the ISO 19160, Addressing, stage zero project, which served to enable formal collaboration among addressing stakeholders in order to reach the two objectives stated in the project's proposal (ISO/TC 211 document number N 2737): Objective 1: Investigate and formulate requirements in relation to addressing. Objective 2: Make recommendations on whether standards should be developed and if so, how this should be done. Thus, to confirm: the objective of this project is not to write an address standard, but rather to review existing address standards in order to identify international addressing standardization requirements and to make recommendations on how these should be developed.

    Introduction: "Addresses are one of the most common ways of describing a location. Addressing systems vary from country to country: in many Euro-centric countries reference to a road network in the address is common, while addresses in countries such as Japan comprise a hierarchy of administrative areas without reference to a thoroughfare. Addresses are used for a wide variety of purposes: postal delivery, emergency response, customer relationship management, land administration, utility planning and maintenance, etc.

    Sometimes a geographic overview of addresses at a large scale is required, e.g. land administration and utility planning and maintenance. For mail delivery or emergency response planning, accurately identifying individual delivery points in a suburb or street is priority. In a customer analysis, individual delivery points are sometimes completely discarded and only the place name in the address is of relevance, while for mail delivery and customer analysis addresses tend to also include names of parties and are constrained by the formatting rules (address label). Standardization of such formatting rules has a great impact on the efficiency of address label rendition (writing) and recognition (reading) and therefore on the overall efficiency of the delivery process..." [cache/archive]

  • [September 17, 2008] "Towards an International Address Standard." By Serena Coetzee (University of Pretoria, South Africa), Antony K. Cooper (CSIR, Pretoria, South Africa), Morten Lind (National Survey and Cadastre Denmark), Martha McCart Wells (Spatial Focus, United States), Sara W. Yurman (Spatial Focus, United States), Ed Wells (Washington Metropolitan Area Transit Authority, Washington, DC, United States), Nick Griffiths (Intelligent Addressing, United Kingdom), and Michael J. Nicholson (Intelligent Addressing, United Kingdom). Paper presented at the Tenth International Conference for Spatial Data Infrastructure (GSDI-10, 25-29 February, 2008; University of the West Indies at St. Augustine, Trinidad and Tobago). 30 pages. See Program TS 21: Data Models and Metadata Standards. Published under a Creative Commons License 'Attribution 3.0 United States'. See the abstract and PDF source, with presentation slides. See also the associated OASIS CIQ TC posting about converting the conference paper into a journal paper.

    "Address standards have been developed and are still being developed by a number of countries (eg: South Africa, Australia, New Zealand, United Kingdom, Denmark and the United States of America) and international organizations — e.g., Universal Postal Union (UPU), International Organization for Standardization (ISO) and the Organization for the Advancement of Structured Information Standards (OASIS). More recently, these standards have tended to include geospatial components and to cater for other forms of service delivery and not just postal, such as goods delivery, connecting utilities, routing emergency services and providing a reference context for presenting other information. The time is right for bringing these various initiatives together to develop one, common international address standard. Such a standard will promote interoperability and reusability of address-related software tools, by providing one common framework for their developers. The standard will facilitate the development of spatial data infrastructures (SDIs), particularly those that span national borders, and facilitate data discovery through geospatial portals. An international address standard will help developing countries without widespread addressing systems speed up the process of assigning addresses and maintaining address data bases.

    An international address standard will have significant benefits for global business as well as for government and international organizations. For example, a common standard would improve address management and quality for online retailers and courier companies that deliver all over the world. Also, a standard enables seamless access to address information across regional and national boundaries, which is vital in disaster management and emergency situations. We present here a comparison of current address-related standards, highlighting their commonalities and differences. Drawing from current experiences with these standards, we highlight the benefits of an international address standard to the economy, society and governance. Finally, we explore the different options for developing such a standard and propose a potential scope the standard..."

    [Table 11 describing ten addressing standards, "Overview of issues addressed in the address standards", shows that] most of the address standards: include geo-referencing by coordinates; describe all kinds of addresses (as opposed to only postal addresses); provide data models; use UML to describe their data models; and use XML as an encoding format. Some of the standards include metadata and a few of the standards include data quality, though the trend is to specify data quality measures in a separate standard.

    The authors believe that the best approach is to develop a new international address standard within ISO/TC 211, as addresses are a fundamental geospatial data theme, and because developing the standard within ISO will allow the broadest participation from governments, academia, industry, NGOs, civil society and international organizations such as UPU and OASIS. Particularly, involvement by relevant organizations will be encouraged to get the broadest possible participation. However, developing the international address standard within ISO implies that copies of the standards must be bought, and we propose to either develop an abstract standard with regional profiles or to develop the standard jointly with an organization that makes their standards available for free. This will help ensure that the standard gets to the local authorities who ultimately have to implement the standard in their areas of jurisdiction..."

  • [September 17, 2008] "Developing a Comprehensive Address Data Standard for the United States." Produced by members of the U.S. Address Standard Working Group: Martha McCart Wells (GISP, Spatial Focus Inc., Chair); Carl Anderson (Fulton County, Georgia, US, Co-chair); Hilary Perkins (GISP, Data Transfer Solutions, Inc., Co-chair); Ed Wells (GISP, Washington DC, US Metropolitan Area Transit Authority, Co-chair); Sara Yurman (Spatial Focus, Inc., Co-Chair). Contact: Martha McCart Wells (Spatial Focus, Inc., Birmingham, Alabama, US). Paper presented at the Tenth International Conference for Spatial Data Infrastructure (GSDI-10, 25-29 February, 2008; University of the West Indies at St. Augustine, Trinidad and Tobago). 12 pages. See the abstract and source PDF. Published under a Creative Commons License 'Attribution 3.0 United States'. "This paper describes the U.S. National Address Data Standard in detail, and further discusses the process of development, which was broadly inclusive of address creation and maintenance agencies (primarily local governments), address aggregators, and state and federal bodies. In 2005, the United States Federal Geographic Data Committee (FGDC) authorized URISA (The Urban and Regional Information Systems Association) to take on primary development of a national Address Data Standard. URISA formed an Address Standard Working Group, and invited broad participation from URISA members, and from other professional geospatial and local government organizations and private interests. The Working Group prepared a draft standard, which was widely circulated in August-September of 2005, followed by a second draft (based on over 150 comments received) that was posted for public comment in December 2005 and January 2006. Since that time, the Working Group has been developing the standard further, by responding to additional comments, and creating additional material. To date the Working Group has prepared three drafts, incorporated over 250 comments, and is in the process of finalizing the final version for submittal to the Federal Geographic Data Committee. The United States Street, Landmark, and Postal Address Data Standard is a draft data standard for United States address information. The draft standard defines and specifies elements and structures for organizing address data, defines tests of address data quality, and facilitates address data exchange. The draft standard has four parts: Data Content, Data Classification, Data Quality, and Data Exchange. The Address Standard as now drafted goes well beyond existing postal and assignment standards in several respects... (1) It proposes a new definition for addresses: 'An address specifies a location by reference to a thoroughfare or landmark; or it specifies a point of postal delivery.' (2) It defines address elements as they are needed for database records, data validation and documentation, and data exchange, as well as for creation of mailing lists. (3) It classifies addresses by their internal syntax, rather than their business purpose. (4) It provides a simple, complete taxonomy of US address patterns. (5) It introduces the idea of an address scheme (a set of local rules by which new addresses are assigned and old ones checked within a specific area). (6) It explicitly requires an address identifier for each different address. (7) It provides attributes that comprise record level metadata about an address including identifiers, classification, feature type, accuracy, spatial referencing, lineage, and assignment authorities. (8) It incorporates a comprehensive set of data quality tests for address data, including SQL-based pseudocode. (9) It incorporates a comprehensive Extensible Markup Language (XML) data model to unambiguously exchange and transfer data..."

  • [May 25, 2008] "Proceedings of the ISO Workshop on Address Standards: Considering the issues related to an international address standard." Meeting held Sunday, 25 May 2008, National Survey and Cadastre, Rentemestervej 8, 2400 Copenhagen NV, Denmark. See the Call for Participation [source]. A special interest meeting held under the auspices of Working Group 7, Information Communities, of ISO/TC 211, Geographic information/Geomatics, and is sponsored and hosted by the National Survey and Cadastre, Denmark (KMS-DK). The purpose of this workshop is to consider the issues related to an international address standard: (1) What is an address? What is the definition of an address in current national address standards? (2) What is the scope of current national address standards? (3) Why do we need a national address standard? (4) Can we benefit from an international address standard? From the "Overview of an Address and Purpose of The Workshop", by Antony Cooper: "An address should be considered more broadly than just a set of directions for delivering post. An address is also used for a wide range of public and private service delivery, including goods delivery, connecting utilities, billing, emergency dispatch and household surveys. Addresses are also needed for opening bank accounts, buying on credit, securing an identity document, voting, obtaining employment, etc. Coetzee et al. compared the definitions of 'address' used in several standards. All these definitions have one aspect in common, namely: a location (site, building, plot of land, point or addressee). All but one of them have another aspect in common, namely: a reference (label, description, identification, textual, specification or information). Several include uniqueness (definite, unambiguous, precise, without searching or without there being any doubt). Other aspects included are common (conventional), structured, completeness, and service delivery (access). One definition also points out that an address does not exist only when some form of service delivery takes place, but is needed for potential service delivery. Combining these together could give the following definition of an address: 'A structured, unique, complete, common reference for actual or potential service delivery to a location.'..."

  • [December 7, 2007] "Thai Personal Names." By James Clark. Blog. December 7, 2007. "There's an election coming up in Thailand on December 23rd and the streets are lined with election posters. As a bit of an i18n geek, I find it interesting that the posters almost all make the candidates' first names at least twice as big as their last names. If you're also an i18n geek, your reaction might well be: "it must be because Thais write their family name first, followed by their given name". But you would be wrong. Thais have a given name and a family name; the given name is written first, and the family name last. The correct explanation that given names play a role in Thai culture that is similar to the role that family names play in many Western cultures. The polite way to address somebody is with an honorific followed by their given name. The Thai telephone book is sorted with given names as the primary key and family names as the secondary key... I have to say that this has led me to question what I perceive to be the i18n orthodoxy that it's more i18n-ly correct to talk of given name/family name than first name/last name. Why does it matter whether a name is a family name or a given name? Surely what matters is the cultural role that the name plays...."

  • [July 09, 2007] "Personal Names Around the World (Part 1). By Richard Ishida. See also part 2. "People who create web forms, databases, or ontologies in English-speaking countries are often unaware how different people's names can be in other countries. They build their forms or databases in a way that assumes too much on the part of foreign users.... If designing a form or database that will accept names from people with a variety of backgrounds, you should ask yourself whether you really need to have separate fields for given name and family name. This will depend on what you need to do with the data, but obviously it will be simpler to just use the full name as the user provides it, where possible. Note that if you have separate fields because you want to use the person's given name to communicate with them, you may not only have problems due to name syntax, but there are varying expectations around the world with regards to formality also that need to be accounted for. It may be better to ask separately, when setting up a profile for example, how that person would like you to address them. If you do still feel you need to ask for constituent parts of a name separately, try to avoid using the labels 'first name' and 'last name', since these can be confusing for people who normally write their family name followed by given names. Be careful, also, about assumptions built into algorithms that pull out the parts of a name automatically..."

  • [February 10, 2003] International Conference on Authority Control. Florence, Italy; February 10-12, 2003. "Authority control is the process which would assure the formal homogeneity of each entry (author, title, corporate body, subject heading) chosen as access authority control is an integral part of the cataloguing architecture, it is inseparable from the concept of catalogue. The control of the morphology contributes to avoiding conflicts with other entries already available or which can be presumed will be present in the catalogue. The authorized form can be considered 'standard' according to cataloguing conventions which themselves are built on a cultural tradition. Authority control is a technique, established by the cataloguer, who is the child of his time and a member of a reality and of a cultural community already defined, but developing and changing at the same time. Authority control is, in conclusion, the identification process of different manifestations of a name or of a title which guarantees the heading's stability..."

  • [February 10, 2003] "FRANAR: A Conceptual Model for Authority Data." By Glenn E. Patton (OCLC). Presented at the International Conference on Authority Control (Florence, Italy; February 10-12, 2003). "...In particular, the [FRANAR] Working Group has spent considerable time commenting on the activity of ISO/TC46/SC9 Working Group 3 and the evolving International Standard Text Code (ISTC). In the case of the ICA Committee on Descriptive Standards, a joint meeting of IFLA and ICA members in Beijing in 1995 had laid the groundwork for a mutual liaison relationship, which has continued during that group's work on revisions to the International Standard Archival Authority Record for Corporate Bodies, Persons, and Families. The work of the indecs project is currently carried on by INTERPARTY. IFLA is a project partner in INTERPARTY as is the British Library, with the Library of Congress and OCLC acting as 'unfounded' partners, so Working Group members have many opportunities to keep up with INTERPARTY activity as well as to share news of FRANAR work. In addition, other authorities-related projects have come to the Working Group's attention during the course of our activities. Recent meeting agendas and postings on the group's electronic discussion list have also included reports of the activities of the MALVINE (Manuscripts and Letters via Integrated Letters in Europe) and LEAF (Linking and Exploring Authority Files) Projects, the DELOS/NSF Actors and Roles Working Group, the Dublin Core Agents Working Group, the HKCAN (Hong Kong Chinese Authority Name Work Group), the HKUST XML Name Access Control Repository, the MACS (Multilingual ACcess to Subjects) Project, METAPERS, the AFNOR Working Group on Authority Metadata, and the Virtual International Authority File (VIAF) Proof of Concept Project..."

  • [April 29, 2002] "Address Structure Harmonization." By David RR Webber (XMLGlobal). Also available in PDF format. In a message posted to the OASIS CIQ TC. April 27, 2002. ['... ideas on using Schema technology to build layers of deeping complexity with address formats -- tied explicitly to business use criteria'] "[The] Objective is to provide layers of address granularity tailored to business use Address use levels: [Level 0 = handwritten postal address -- machine parsed; Level 1 = in country simple postal address -- legacy; Level 2 = extended postal address -- advanced features; Level 3 = shipping / delivery address -- large organization; Level 4 = facilities management -- universal / exotic / global]. Share common noun, definitions, share validation rules and quality factors, Provide means to manage the quality of address content, provide global language and format support." Technology: Use W3C Schema to provide layers of increasingly refining definitions based on business use; Use OAGIS V8 methods to restrict syntax to best-practice techniques; Enable use of ebXML AssemblyDoc technology; Provide migration from legacy address formats; Harmonization of existing and emerging standards to single common base noun dictionary and use templates..."

  • [April 26, 2002] "Postal Address Template Description Language (PATDL): A Contribution To An International Postal Addressing Standard." By Joe Lubenow (Industry Co-Chair, UPU DMAB Address Management Project Team). February 20, 2002. 27 pages. See the summary above.

  • [March 19, 2002] IDEAlliance 2002 Addressing/Distribution Conference (A/D 2002). March 19-21, 2002. Sheraton Sand Key Resort, Clearwater Beach, FL, USA. Theme: "The Changing Postal Landscape." Presented by IDEAlliance (formerly the Graphic Communications Association) with the Alliance of Nonprofit Mailers, the Association of Postal Commerce (PostCom), Graphic Arts Technical Foundation/Printing Industries of America, and the Gravure Association of America. Will include a tutorial on the (ADIS) Address Data Interchange Specification.

  • [March 15, 2002] ['Field Level Analysis for CIQ/ECCMA/USPS-Domestic/HR-XML/X12-Based XML Postal-Address']. CIQ posting of 2002-03-15 from David RR Webber (XMLGlobal). See the .XLS spreadsheet [cache .xls, generated HTML]

  • [March 12, 2002] "Progress Report: Toward An International Addressing Standard." By Joe Lubenow (Lubenow and Associates). Presented at Open Publish 2002. March 12, 2002. PDF document from 25 slides. [Slide #15] "Basic Approach of Address Element Technology: (1) The address is not the same as the address label; (2) The address is a structure of elements; (3) Elements are the smallest meaningful parts of addresses; (4) Addresses in each country can be classified in terms of one or more templates; (5) Templates are orderings or sequences of address elements; (6) The label is merely one rendition of the address; (7) Rendition instructions can make the presentation consistent and repeatable; (8) The label must preserve address deliverability even when address space is limited." [Slide #20] "Templates: (1) Address instances reflect basic patterns; (2) Some basic patterns are applicable to many countries; (3) Country based templates are being defined; (4) Language of presentation must be specified; (5) A template can be thought of as a sequential ordering of lines and elements; (6) Address format varies if mailing is internal vs. external; (7) Usable for single country applications without external knowledge; (8) Templates need to support variations in formats: one way is to support conditional logic, another way is to allow subtemplates." [source .PPT, cache]

  • [CEN] European Address Standard, Part1. Flash presentation. From Holger Wandt, Vorsitzender der CEN Arbeitsgruppe 'Address Database'.

  • [January 30, 2002] "International Address Standardization: Features, Technologies and Formats." By Joe Lubenow. Presentation given to the International Address Template Work Group [including USPS, US industry, and European attendees], Fort Myers. January 30, 2002. 21 slides. A "summary of the overall situation with respect to address element technology." Referenced from OASIS CIQ mailing list. See original sources: source .PPT [cache]

  • [December 13, 2001] "Piecing Together the Address Puzzle." By Mabel Grein (Senior Computer Systems Analyst, USPS, Information Technology). Outline of 21 slides. Presented December 13, 2001 at the Second Annual ECCMA General Membership Conference. December 12-13, 2001. Santa Clara Convention Center, Santa Clara, CA. Similar presentation given April 16, 2001 at the GCA Spring 2001 Addressing/Distribution Conference. Generated from the original Powerpoint document. On the GCA meeting: GCA Spring 2001 Addressing/Distribution Conference. April 17-20, 2001, The Westin Riverwalk Hotel, San Antonio, Texas. See the conference schedule. Spring Conference Chair Joe Lubenow (Vice President, Postal Affairs, Experian). See the session 'Addressing issues and standards -- domestic and international'. Speaker: Michael Murphy (Manager, Address Management, US Postal Service). Moderator: Joe Lubenow, Experian. Panelists: Peter Benson (President, ResolveNet), Mabel Grein (Business Systems Analyst, US Postal Service, Information Technology), and Phil Thompson (Business Resource Manager, Quad/Graphics).

  • "International Address Management Issues Are Focus of a Global Effort." By Joe Lubenow. In The CROSS-BORDER Report Volume 3 Number 3 (Fall 2001). "The International Mailers Action Group (IMAG), along with related groups such as the Universal Postal Union (UPU) Direct Mail Advisory Board, has taken an active role in promoting worldwide address standardization... The UPU, which has 189 postal administrations as members, develops standards through its Standards Board, historically composed only of postal representatives, but opened up in the last year to industry observers, including IMAG and DMAB members. Two resolutions were passed by the UPU Standards Board in January, 2001. One calls for developing lists of address elements -- the smallest meaningful parts that make up postal addresses, including individual and company names -- as well as patterns, or templates, in which these elements are typically arranged. The second calls for developing standards for sending address data between parties using either traditional Electronic Data Interchange (EDI) or the newer World Wide Web based standard, Extensible Markup Language (XML). This work of standardization requires both postal and industry cooperation as well as parallel efforts in different regions. In the United States, the USPS has helped develop EDI transactions which communicate postal addresses, and the IDEAlliance (formerly the Graphic Communications Association) has published an Address Data Interchange Specification (ADIS) in XML and relational database formats. Participants in both of these efforts are working together under the auspices of the USPS National Customer Support Center to ensure compatibility at the address element level. The Electronic Commerce Code Management Association (ECCMA) has agreed to serve as a Web-based repository for the address element lists and to sponsor an advisory board that votes on proposed additions. In Europe, the regional standardization organization CEN will soon publish a list of address elements applicable throughout the European Union. At the UPU, the POST*Code project has published a CD-ROM with address elements and templates from 189 member countries. Through the UPU, efforts such as these may be coordinated in order to achieve the goal of a single worldwide standard that can be expressed using a variety of technological protocols..." Contacts: [1] Mike Garner of United States Postal Service, Address Management; [2] Mabel Grein of USPS, Information Technology; [3] Joe Lubenow (President, Lubenow Associates, Chicago, IL; Tel +1 773-478-2249).

  • [May 3, 2001] "Piecing Together The Address Puzzle." By Mabel Grein (United States Postal Service, Information Technology). May 3, 2001. Santa Clara, California. Presentation at the ECCMA Meeting: "Addressing Standards in the New Millennium." 28 slides in Powerpoint presentation. Topics Covered: Why the USPS became involved; Quick history; Where we are today with ECCMA; ADIS. Source:

  • [May 3, 2001] "Address Data Interchange Specification (ADIS). An Industry Standard For Domestic and International Address Management and Mail Production Using Address Element Technology." By Joe Lubenow (Vice President, Postal Affairs, Experian; Chair, GCA Addressing/Distribution Committee; Chair, GCA ADIS Project). Email: May 3, 2001. Presented to ECCMA Conference: "Addressing in the New Millennium". Santa Clara, California. Source: (Powerpoint, .ZIP format).

  • [April 2001] "Das Ende des Europäischen Adress-Babylon?" Die neuesten Entwicklungen in Sachen internationaler Adress-Standard." By Heidrung Brüning, Human Inference GmbH. April 2001. Overview of the 5-part proposed CEN standard from TC/331 WG 3.

  • [January 31, 2001 ] XML Schema Definition for 'Party'. From a posting of Martin Bryan. "... an illustrated tree for the [Party] model... I have deliberately used attributes to record the role/type/purpose of an element as these properties can be replaced in message specific names (e.g Buyer and Seller in place of Party and HomeTelNumber, BusinessFaxNumber in place of CommunicationPoint). I have also defined abstract elements for all elements that are, in my opinion,likely to be used independently of Party details." [cache]

  • [November 2000] "Postal Addressing Standards -- Contents." Publication 28. November 2000. 129 pages. cache]

  • Anglo-American Cataloguing Rules. 1998. Prepared under the direction of the Joint Steering Committee for Revision of AACR, a committee of the American Library Association, the Australian Committee on Cataloguing, the British Library, the Canadian Committee on Cataloguing, the Library Association, the Library of Congress Edited by Michael Gorman and Paul W. Winkler. Second edition, 1998 revision. ISBN (one of several): 0-8389-3486-2. The AACR2 volume dedicates a full 100 pages (chapters 22-24, pages 379-479) to the topic of personal, corporate, and geographic names, offering guidelines for sub-element decomposition and aggregation adequate to support name authority control in a bibliographic context. Electronic editions are also available, incorporating amendments. "The Amendments 1999 were approved by the Joint Steering Committee (JSC) in 1999 and include rule revisions concerning punctuation and numbering within series titles. The Amendments 2001 were approved by the JSC in 2000 and include a revised Chapter 9 on electronic resources, a new appendix for Initial Articles, and a number of other revisions."

  • [April 23, 2002] "Representing People's Names in Dublin Core." By Andrew Waugh. Dublin Core Metadata Initiative. DCMI Note. 1998-02-03. ['This note provides some guidance on representing people's names in metadata.'] "... a name may be written down in many different ways... the name may be written in full or components of the name can be abbreviated or omitted ... names may be extended by titles or honorifics ... complexity is added by the fact that people frequently do not use their 'official' name... some people prefer to use their second name instead of their given name ... another dimension of complexity occurs when names from many cultures must be handled. Appendix A summarises the name forms of some of the cultures commonly found in Australia. The range of different components which can be found in names is astounding, as is the number of ways these components can be ordered. To make handling names even more difficult, it is common for migrants to alter their name when integrating into another culture..." [cache]

  • ISAAR(CPF): International Standard Archival Authority Record for Corporate Bodies, Persons and Families. International Council On Archives [Conseil international des archives]. Prepared by the Ad Hoc Commission on Descriptive Standards. Paris, France. 15-20 November 1995. ISBN 0-9696035-3-3. 28 pages. "The primary purpose of this document is to give general rules for the establishment of archival authority records that describe the corporate bodies, persons, and families that may be named as creators in descriptions of archival documents. It is expected that records that result from the implementation of the rules can serve both to standardize the form of the name of a records creator and to describe fully the attributes of the creator needed to appreciate the context of creation of a body of archival documents... An archival authority record that conforms to this standard may also serve to control the form of name and identity of a corporate body, person, or family named in an access point that is the subject of a unit of description." Supplies guidelines for recording personal names, as relevant to library applications. ISAAR(CPF) is also available online in HTML format. See the Descriptive Standards list from the International Council on Archives. [cache]

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: