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).

References:

• Update to BS7666 Address Schema. "Schema for British Standard BS7666 address types." 2002-02-05. [cache]
• XML Schema for British Standard BS7666 address types. Namespace: http://www.govtalk.gov.uk/people/bs7666. Last modified: 2002-01-16. Project use: Govtalk Development of Address and Personal Details Schema.
• BS7666 Address data. From UK Government Data Standards Catalogue.
• Schema for British Standard BS7666 address types. Namespace: http://www.property.gov.uk/schemas/bs7666/BS7666Schema.xsd Source: http://www.property.gov.uk/schemas/bs7666/BS7666Schema.xsd. Provides a definition of basic BS7666 types and constructs; includes a definition of a basic BS7666 Address; the simple and complex types are as defined in BS7666:2000.
• BS7666 and Compatibility with xAL. From Robert James. See the CIQ mailing list 2002-03-12. [source]
• BS7666 [Description]. NLPG Briefing Notes Pack Sheet 8. Version 3.0
• See: "British Standard BS7666 for Geographical Referencing."

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)."

References:

• CEN Technical Committee 331: Postal Services. Official Web Site. [Also www.nni.nl/cen331]
• CEN/TC 331 Newsletter. Available from the European Commission website.
• Memorandum of Understanding between UPU and CEN
• European Address Standard, Part 1. Flash presentation. From Holger Wandt, Convenor of the Workgroup 3 activity 'Address Database'.
• "European Standardization of Address Data." Memo, September 2000.
• International address standardization developing rapidly." March 2001.
• "Physical Representation of Address Components December 2001. [Physische Repräsentation von Adresskomponenten]
• Address Standard website from Human Inference Enterprise B.V. See also the web sites in German and Dutch.
• Comparing Postal Address Data of CEN/TC331/WG3 and xNAL Framework (source?)

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."

References:

• 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 eccma.antarcti.ca webserver is a demonstration of Antarcti.ca 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..."

References:

• Graphic Models of Representative EAC Elements: person description, person name group, http://xml.coverpages.org/EAC-GraphicModel-identity.jpg
• "Encoded Archival Context Initiative (EAC)" - Local references.
• Encoded Archival Context (Beta) Revised: 29-November-2004 or later.
• Encoded Archival Context (EAC). Yale University Library.

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.

References:

• EURopean ADdresses INfrastructure (EURADIN) Abstract. Apparently from María Cabello (Trabajos Catastrales, S.A.). 5 pages. Word .DOC format also available. [cache]
• EURopean Addresses INfrastructure (EURADIN). INSPIRE Implementing Rules. Spatial Data Interest Community Description. [cache]
• EURADIN kicks off! Announcement June 1, 2008.
• EURADIN Poster
• EURADIN Flyer
• European Addresses Infrastructure: Work Package 9 (Networking and Dissemination). From the kick off meeting, June 16-17, 2008.
• Email contact: euradin@eurogi.org

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:

• HR-XML Projects
• Person Name. Prescribes the form of Person Name used in HR-XML specifications. See also the XML schema. [cache]
• Postal Address. Prescribes the form of the PostalAddress used in HR-XML specifications. See also XML schemas for PostalAddress and OnlineAddress. [cache]
• HR-XML Consortium web site

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:

• PostalAddress 1.2 prose documentation
• XML DTD [cache]
• XML Schema [cache]
• ZIP package

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:

• PersonName 1.2 prose documentation
• XML DTD [cache]
• XML Schema [cache]
• ZIP package

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..."

References:

• ISO/TC 211 Geographic information/Geomatics
• The ISO Addressing Project 19160
• Address standards: A collection of information on address standards
• Contact: Serena Coetzee (University of Pretoria home page and publications)

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.

See:

• "Linking and Exploring Authority Files (LEAF)"
• "Encoded Archival Context Initiative (EAC)"

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:

• Specification
• Technical Overview
• General Introduction and Overview
• XML Schemas
• Frequently Asked Questions (FAQ)
• Package Overview
• Release Notes

[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

References:

• "Text Encoding Initiative - XML for TEI. Local references.
• Text Encoding Initiative -Chapter 20: Names and Dates
• Core: Names, Numbers, Dates, Abbreviations, and Addresses

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 govtalk@e-envoy.gsi.gov.uk. 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:

• AddressTypes-v1-2
• BS7666-v1-2
• CitizenIdentificationTypes
• CommonSimpleTypes
• ContactTypes
• PersonalDetailsTypes

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 http://www.govtalk.gov.uk/people/AddressAndPersonalDetails
2. PersonalDetailsTypes_v1_0.xsd for General data types relating to a citizen. Uses the APD namespace http://www.govtalk.gov.uk/people/AddressAndPersonalDetails
3. CitizenIdentificationTypes_v1_0.xsd for the various citizen references (such as electoral roll number) used in the public sector. Uses the APD namespace http://www.govtalk.gov.uk/people/AddressAndPersonalDetails
4. BS7666_v1_0.xsd for BS7666 address types. Uses the BS7666 namespace http://www.govtalk.gov.uk/people/bs7666
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

• UPU Technical Standards
• UPU International Bureau Address Elements. See excerpt. [cache]
• UPU postal addressing formats
• Universal Postal Union (UPU) website
• Overview: UPU S42 Standard on International Postal Address Components and Templates. By Joe Lubenow. See the news item "Universal Postal Union Publishes Approved International Address Standard UPU S42-1." [source PDF]
• "Progress Report: Toward An International Addressing Standard." Presented at Open Publish 2002. March 12, 2002.

UN/PROLST

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"]

References:

• "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."

References:

• 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.

ASTM E2182: Names in Healthcare Records

[TBD] Personal names in the E2182-02 Standard Specification for Clinical XML DTDs in Healthcare.

References:

• ASTM E2182 Clinical Header XML DTD [cache]
• RELAXNG Compact version of the ASTM E2182 standard for names. Referenced by Jonathan Borden on XML-DEV 2004-01-30.
• Clinical Header namespace description (RDDL) [cache]
• E2182-02 Standard Specification for Clinical XML DTDs in Healthcare. Developed by Subcommittee: E31.28.
• Draft ASTM XML Healthcare DTDs
• ASTM XML Document Type Definitions (DTDs) for Health Care

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..."

References:

• vCard and the vCard XML Schema
• "vCARD in XML and RDF."
• vCard and vCalendar. Internet Mail Consortium web site.
• vCard and CardDAV (vcarddav) Working Group, in the IETF Applications Area.
• vCard MIME Directory Profile. IETF RFC 2426. September 1998.
• "An Ontology for vCards.". By Harry Halpin, Brian Suda, and Norman Walsh. W3C Memo. November 14, 2006. "This ontology attempts to model a subset of vCards in RDF using modern (circa 2005) RDF best practices. The subset selected is the same subset that the microformats community has adopted for use in hCard."