This document provides a quick and general introduction and overview about the CIQ Technical Committee (TC) and the specifications it has developed for industry

Status:

This document was last revised or approved by the OASIS CIQ TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/ciq.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (www.oasis-open.org/committees/ciq/ipr.php.

The non-normative errata page for this specification is located at www.oasis-open.org/committees/ciq.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “CIQ”, “xNL”, “xAL”, xNAL”, “xPIL”, “xPRL”, “xCIL”, “xCRL” , “Genericode”, and “UBL” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction.. 5

2 Name, Address, Party, and Party Relationship.. 6

2.1 Definitions. 6

2.2 General Applications of Party Information.. 6

2.3 Problems due to lack of an industry standard to interoperate/exchange/manage party related data.. 7

2.4 OASIS CIQ TC Specifications to address party data related issues. 8

2.5 What are not defined in CIQ Specifications?. 9

2.6 CIQ TC’s Formula for Successful Data Interoperability.. 9

2.7 Using Party Related Data - Use Case Scenarios. 10

3 OASIS Customer Information Quality (CIQ) Technical Committee. 11

3.1 Goals of CIQ TC.. 11

3.2 Evolution of CIQ TC specifications. 12

3.2.1 Evolution of xNL, xAL and xNAL Specifications. 12

3.2.2 Evolution of xCIL/xPIL Specifications. 13

3.2.3 Evolution of xCRL/xPRL Specifications. 14

4 CIQ TC and its contributions to Industry.. 15

4.1 CIQ TC Specification Versions Released.. 15

4.2 Extensible Name Language (xNL) 15

4.3 Extensible Address Language (xAL) 16

4.4 Extensible Name and Address Language (xNAL) 17

4.5 Extensible Party Information Language (xPIL) 17

4.6 Extensible Party Relationships Language (xPRL) 18

4.6.1 Person to Person Relationships. 18

4.6.2 Person to Organisation Relationships. 18

4.6.3 Organisation to Organisation Relationships. 18

5 CIQ TC Specifications – Industry adoption and comparison with other similar initiatives 19

5.1 Adoption of CIQ TC Specifications by Industry Types. 19

5.2 Industry Applications using CIQ TC Specifications Family.. 19

5.3 Other Relevant Initiatives in Industry.. 20

A. Acknowledgements.. 22

B. Intellectual Property Rights, Patents, Licenses and Royalties.. 23

C. Revision History.. 24

1 Introduction

This document provides a general introduction, overview and history of OASIS Customer Information Quality Technical Committee (CIQ TC) and the specifications it has produced for industry namely,

· xNL : extensible Name Language

· xAL: extensible Address Language

· xNAL: extensible Name and Address Language (combines xNL and xAL)

· xPIL: extensible Party Information Language (formerly known as extensible Customer Information language (xCIL)), and

· xPRL: extensible Party Relationships Language (formerly known as extensible Customer Relationships Language (xCRL))

The main goal of this document is to provide any type of reader (business or technical) with sufficient general understanding about the CIQ TC specifications.

2 Name, Address, Party, and Party Relationship

2.1 Definitions

Name

Name of a person or an organisation

Address

A physical location or a mail delivery point

Party

A Party could be of two types namely,

· Person

· Organisation

An Organisation could be a company, association, club, not-for-profit, private firm, public firm, consortium, university, school, etc.

Party data consists of many attributes (e.g. Name, Address, email address, telephone, etc) that are unique to a party. However, a person or organisation’s name and address are generally the key identifiers (but not necessarily the unique identifiers) of a “Party”. A “Customer” is of type “Party”.

Party Relationship

A state involving mutual dealing between Parties

2.2 General Applications of Party Information

Party specific data are commonly and widely used entities across different domains. We broadly categorise the applications of party specific data as follows:

Point to point data exchange

Organisation A exchanges data with Organisation B. Both organisations have different data models for Party, but they agree on the way they map their data models to the schemas to minimise the implementation effort.

Organisation A captures stores and uses party data in many different ways to meet various business requirements. To uniquely identify a party within the organisation, the organisation synchronises party data between various applications through a common data model for party information.

Open data exchange

A number of diverse organisations exchange data in an open fashion. All systems are different, but still can be mapped to party schemas. All participants rely on the original TC specification, but some restrictions and modifications are still possible to suit the application and locale.

Database modelling

Party schemas and the data models they reflect can be used as a reference for design and implementation of relational or XML databases in regard to party entities.

Reuse by other standards and schemas

All party schemas are built for reuse. They can be included in other schemas when describing party details. Party data could be a subset of broader data sets that meet specific business requirements such as health, retail, finance, travel, human resources, customer relationship management, etc.

Party Profile Management

Party schemas significantly assist in Party/User profile management. Party/User profile management is very important, and sometimes is the only direct contact a stakeholder has with the organisation. It must provide efficient access to various applications and information through the numerous stages from the beginning to the end of a party’s association with the enterprise.

2.3 Problems due to lack of an industry standard to interoperate/exchange/manage party related data

Following are some of the key problems due to the lack of a standard to manage party related data in organisations. The aim of CIQ Specifications is to assist organisations in minimising these problems:

· Party data and in particular, name and address, as a data type, is very difficult to manage. This data is often volatile… customers/parties come and go, addresses change, names change. Name and address is subjective…it can be written in a number of different ways and still convey the same meaning. This problem is further compounded by the different ethnic backgrounds impacting name and address data in a global market. Organisations collect party data in various formats for various purposes namely, marketing, sales, billing, security, data matching, data exchange, etc.

· Today’s increasing security requirements at the national and international level due to cross border (global) terrorism and other unlawful activities around the world requires party profile (e.g. person of interest) data exchange between countries, high reliability in party identity screening and verification, regardless of country, language, culture and geographical boundaries. Federated identity – the sharing of party profile information between organisations - is a new distributed model gaining credence in the security world. Party industry standards play a significant role to meet this serious, but important requirement.

· Party data plays a critical role in uniquely recognising/identifying a person/organisation in order to get a complete, clear and consistent understanding of the person/organisation to provide effective and efficient services to the party. To date this is an outstanding critical issue for most organisations as they have multiple information systems and databases capturing and representing party data in many different ways. As a result, the systems and databases are either poorly integrated, or in many cases, not integrated at all. This fragmentation creates a major barrier to ever achieving a consolidated view of the each party – the foundation for successful Party Relationship Management (e.g. CRM), Business Intelligence (BI), data warehousing and other party-centric initiatives.

· Challenges in the treatment of party name and address and key party profiles occur mostly during data entry particularly in a global e-commerce environment. For example, the order in which address elements are naturally provided varies from country to country. 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. 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. Lack of a standard way of capturing and representing international addresses compounds this problem further.

· Organisations want to exchange and manage party related data between different applications using a standard set of data interfaces. For example, one might want to move all the party related data and relationships from one application to another.

· A party-centric “Global” or “International” organisation could use its party details data for some or all of the following applications:

· Party Profiling/Management

· Party Marketing initiatives

· Party recognition/identification and relationship management initiatives

· Data Quality initiatives covering,

· Name and address parsing, searching, matching, de-duping and validation

· Initiatives for Bulk Mail discounts (Postal services)

· E-commerce (purchase, shipment, invoicing, etc)

· Fraud Detection and Management

· Managing Party/User profile in a consistent and efficient manner within an organisation is a complex, but critical challenge for any organisation dealing with party data. Party/User profile management is very important, and sometimes is the only direct contact a stakeholder has with the organisation. It must provide efficient access to various applications and information through the numerous stages from the beginning to the end of a party’s association with the enterprise. Being able to effectively administer users, their access to resources, the profile details is crucial to keeping the enterprise secure, whilst also keeping operational costs under control.

With a global world as the market for an organisation such as the above, the serious problems faced are multiple formats to represent party data to meet application specific requirements, and point to point integration to exchange party data between applications resulting in numerous interfaces that are expensive to maintain.

2.4 OASIS CIQ TC Specifications to address party data related issues

Party data standards ensure the consistency, accuracy, integrity and validity that are critical to the success of party related IT initiatives of an organisation.

Some of the key issues with capturing, representing, using and managing party data are evident in the earlier section. But despite the realisation by organisations on the importance of these issue and party information management particularly in a global e-business environment, no XML specifications specifically concentrating on party profile/information management and importantly, independent of specific application requirements have been developed.

Though there are a number of XML specifications/standards addressing party data and in particular name and address available throughout the world, to a large extent, these specifications/standards have been designed with a particular business requirement in mind. For example, the expedient delivery of a piece of mail, purchasing, invoicing, shipment, tax, accounting, human resources, health, exchange of party related data in an e-business environment, etc. While the particular standard is appropriate for the purpose for which it was designed, frequently it is not suitable for a variety of other purposes. This puts pressure on organisations dealing with customers at a global level to capture and represent party data via more than one party standard.

The best strategic solution is to use a single standard throughout the organisation to capture, represent and exchange core party data (such as name, address and key identifiers) that can then be extended to support multiple application requirements. For example, organisations implementing an enterprise wide common information/data model to integrate many applications can use CIQ specifications for party related data as part of its common information model. This common information model can be used to map the model with the transactional system(s)/application(s) data models. This avoids point to point mapping of party data between different transactional systems and at the same time enables consistent exchange of party data within an enterprise.

When XYZ Ltd uses different industry standards to meet specific application requirements, say, human resources management, purchasing and invoicing, customer views, customer identification, etc, it is forced to implement party related components of the standards it uses for the listed applications, more than once. But CIQ Specifications help to avoid this duplication by enabling XYZ Ltd to implement one single standard (CIQ Specification) to represent party related data once throughout the organisation and then implement application specific standards around this CIQ Specifications by reusing it. This is due to the fact that CIQ specifications are independent of vertical industry applications. This is the key differentiator between the CIQ family of specifications and similar initiatives (in particular, name and address specifications) in industry that are designed for a specific application requirement:

There is a definite need for a single, global and open party (includes name and address) industry standard/specification, implemented using XML schemas to address and manage the above discussed issues with party data. This is the precise objective of OASIS CIQ TC that led to development of the CIQ Specifications.

2.5 What are not defined in CIQ Specifications?

CIQ Specifications deal only with representation of party related data (limiting to party name, address, party centric attributes and relationships) in a standard format, and does not deal with:

· Transactional "customer/party information" such as recent purchases, payment history, etc.

· Message envelopes that carry CIQ payload

· Formatting of the CIQ represented data

· Privacy and security issues connected to exchanging and storing personal information

· Data exchange methods and procedures for party information

· Messaging protocol for exchange of party information

· Validation/verification of party information

· Formatting, labeling, or sorting of party information

· API specifications

CIQ specifications are not a quality enhancing process as commonly understood or akin to a certificate of test results against some objective specification.

2.6 CIQ TC’s Formula for Successful Data Interoperability

OASIS CIQ TC defines data/information interoperability as follows:

“Get the right data to the right place at the right time in the right format with the right quality with the right security in the right context and with the right governance to applications, processes, or users”

We at OASIS CIQ TC strongly believe in the following “Data Interoperability Success Formula”:

Data Interoperability = Open Data Architecture + Open Data Integration + Data Quality + Open Data Standards + Data Semantics + Data Security + Data Governance

All components on the right hand side of the above formula are important for successful data interoperability. It is important to emphasis here that the quality of any information management/processing system or any data exchange/interoperability system is only as good as the quality of the data it processes/stores/manages. To structurally represent the data, understand the semantics of the data to integrate and interoperate the data, quality of the data is critical. CIQ specifications have been designed with the above formula in mind. The term “Open” used here indicates artifacts that are independent of any proprietary solution (e.g. open industry artifacts or artifacts that are open within an enterprise).

2.7 Using Party Related Data - Use Case Scenarios

Numerous use case scenarios can be listed to demonstrate how party data is used in organisations to conduct business as any sort of business involves one or more party associated with it, and they could be employee, customer, prospect, buyer, supplier, partner, contractor, etc. The following diagram provides few of the many broad categories of subject areas where party related data plays a critical role. Each category can have numerous applications with each have many use case scenarios.

3 OASIS Customer Information Quality (CIQ) Technical Committee

Customer Information Quality (CIQ) technical committee was formed under OASIS in 2000 to address the party data management problems discussed above. The first face to face meeting of the committee was held at the XML Conference in Washington, USA in December 2000.

Mastersoft, a customer information management solutions organisation from Australia founded this technical committee with its Chief Architect, Ram Kumar, as the founding chairman. Mastersoft provided the initial contribution to the committee in the form of Name and Address Markup Language (NAML), Customer Identity Markup Language (CIML), and Customer Relationships Markup Language (CRML) XML specifications. AND Solutions, a global address data management company from The Netherlands provided its Global Address data XML specifications to the committee.

These specifications were used as the initial reference models for discussion to develop the party information standards under the CIQ TC.

3.1 Goals of CIQ TC

The goals of the CIQ TC to develop specifications for party profile/information are to be

· application independent

· platform independent

· vendor neutral

· truly “open”, meaning

· free of royalties

· free of patents

· free of licenses

· free of Intellectual Property Rights (IPRs)

· freely available for public to download and implement the specifications without any restrictions, and importantly

· developed in an open process environment

· independent of language, cultural and geographical boundaries

· have the ability and flexibility to represent global party data and specifically with the ability to handle

· about 36+ party name formats

· addresses of 240+ Countries

· about 130+ Address Formats, and

· 5,000+ languages (dialects)

3.2 Evolution of CIQ TC specifications

In this section, we summarise the evolution of OASIS CIQ TC Specifications.

3.2.1 Evolution of xNL, xAL and xNAL Specifications

The diagram below summarises the evolution of xNL, xAL and xNAL Specifications since 1999.

3.2.2 Evolution of xCIL/xPIL Specifications

The diagram below summarises the evolution of xCIL/xPIL Specifications.

3.2.3 Evolution of xCRL/xPRL Specifications

The diagram below summarises the evolution of xCRL/xPRL Specifications.

4 CIQ TC and its contributions to Industry

The CIQ TC has delivered the following approved committee specifications to the industry since its inception in 2000:

· Extensibile Name and Address Language (xNAL) Version 2.0

· Extensibile Name Language (xNL) Version 2.0

· Extensibile Address Language (xAL) Version 2.0

· Extensible Customer Information Language (xCIL) Version 2.0, and

· Extensible Customer Relationships Language (xCRL) Version 1.1

xCIL is renamed as extensible Party Information Language (xPIL) and xCRL as extensible Party Relationships Language (xPRL) in Version 3.0.

4.1 CIQ TC Specification Versions Released

Following are the different versions of specifications (CIQ technical committee approved) released by the CIQ TC since its inception in 2000.

	xNL	xAL	xNAL	xCIL/xPIL	xCRL/xPRL
Version 1.0	May 2001	May 2001	May 2001	May 2001	Dec.2001
Version 1.1	Sept.2001	Sept.2001	Sept.2001	Sept.2001	July 2002
Version 2.0	July 2002	July 2002	July 2002	July 2002	-
Version 3.0	June 2007	June 2007	June 2007	June 2007	Last Quarter 2008

4.2 Extensible Name Language (xNL)

xNL defines an XML format to represent party name information. A party name could be a “Person” or an “Organisation”. An “Organisation” could be educational institutions like school, university, college, etc, clubs, associations, industry groups, not-for-profit bodies, consortiums, user groups, etc.

xNL is designed to handle international name data that are culture- and geography- specific. For example, the concept of given name and family names do not exist in some countries such as India (some regions), so the traditional FirstName/LastName or GivenName/FamilyName approach is not always applicable.

xNL is designed to support party names in over 36 formats internationally.

4.3 Extensible Address Language (xAL)

xAL defines an XML format to represent address data. An address could be any of the following address types and xAL has been carefully designed (based on use cases and address structures around the world) to handle them. Following are some of the key address types that xAL can be used to represent:

· Airport	· Business/Commercial Parks	· Caravan Parks
· Community Developments	· Dual (Primary and Secondary)	· Educational institutions
· Entertainment/Recreation Parks	· Hospitals	· Large Mail Users (e.g. Hospitals, industrial zones)
· Marinas	· Military	· Ports
· Postal Delivery Points (e.g. P.O.Box, Mailbag, Mail Stop, Pigeon Holes)	· Retirement Villages	· Resorts
· Royal Highness	· Rural (with land, air and water access)	· Sporting Venues
· Territories	· Tribal	· Simple Urban
· Complex Urban	· Utility Urban	· Ranged Urban
· Villages	· Canals	· Banks
· Vacant lands (e.g. Lot)	· Location type reference addresses	· Landmark based reference addresses

xAL is designed to support addresses of 240+ countries of the world and in over 130 formats, and represent them as fully parsed, semi-parsed and unparsed data.

4.4 Extensible Name and Address Language (xNAL)

xNAL defines XML specifications to represent party name and address data together. xNAL uses xNL and xAL specifications. An example of xNAL could be:

Attention: Mr. Ram Kumar

CEO

XYZ Corporation

23 Archer Street

Chatswood, NSDW 2067

Australia

4.5 Extensible Party Information Language (xPIL)

xPIL defines XML specifications to represent party centric data. Party centric data includes:

· Name

· Address

· Electronic address identifier details (including VoIP)

· Contact numbers (Mobile, Pages, Fax, Landline, etc)

· Identification details (e.g. passport, license number, identification card, etc)

· Vehicle details

· Account details (e.g. bank account, club account, etc)

· Hobbies

· Reference Contacts

· Birth details

· Qualification details

· Physical details

· Revenues

· Relationships

· Nationality details

· VISA details

· Membership details

· Key event details,

· Preferences,

· Communication Language details

· Person characteristics (e.g. marital status, physical status), and

· Organisation characteristics (e.g. Registration details, business nature)

4.6 Extensible Party Relationships Language (xPRL)

xPRL defines XML specifications to represent implicit and explicit party relationships. Party relationships could be:

· Person to Person relationships

· Person to Organisation relationships, and

· Organisation to Organisation relationships

4.6.1 Person to Person Relationships

Some examples of Person to Person relationships are:

· Mrs Mary Johnson and Mr.Patrick Johnson, where Mary is the "Wife" of Patrick and Patrick is the "Husband" of Mary

· Mrs Mary Johnson and Mr.Patrick Johnson "IN TRUST FOR" Mr.Nick Johnson, where Mary and Patrick are the trustees of Nick and Nick is the beneficiary

· Mrs. Mary Johnson, Care of Mr.Patrick Johnson, where Mary is dependent on Patrick

· Complete Organisation Structure (Employee-Employee Relationship)

4.6.2 Person to Organisation Relationships

Some examples of Person to Organisation relationship are:

· Mrs. Mary Johnson and Mr.Patrick Johnson "DOING BUSINESS AS" Johnson & Associates, where Mary and Patrick are persons who are jointly doing a business under the name of a company called Johnson & Associates.

· Mrs and Mr. Jonhson "IN TRUST FOR" Mr.Patrick Johnson "DOING BUSINESS AS" Jonshon & Associates

· Mrs and Mr. Venkatachalam "IN TRUST FOR" Mr Ram Kumar and Mr Laxmana Samy "ADMINISTRATORS OF" Sakthisoft Pty. Ltd "TRADING AS" Mantra Corporation

· Mr. Ram Kumar, Care of Sakthisoft Pty. Ltd, where Ram is the person and Sakthisoft Pty. Ltd is the company.

· Organisation structure

4.6.3 Organisation to Organisation Relationships

Some examples of Organisation to Organisation relationship are:

· Company A "TRADING AS" Company B

· Company A is the subsidiary of Company B

· Company A is the parent of Company B

· Company A, Company B and Company C are the subsidiary companies of Company D

5 CIQ TC Specifications – Industry adoption and comparison with other similar initiatives

Party information and in particular, name and address is the widely used data in industry. Wherever a party is associated with an application, name and address data plays the leading role. In the following sections, we look at other similar initiatives (in particular, name and address specifications) around the world and how CIQ Specifications are different to them.

The goal of OASIS is not to ask interested parties to register their interest to use the specifications. The specifications in OASIS are for anyone to download without the need to register. This results in potential users to download the specifications and use the specifications without any restrictions. Therefore, it is not possible for CIQ TC to track the use of CIQ specifications in industry. However, over time, the CIT TC has received feedback and information about the use of CIQ Specifications in industry. This information have been collated and presented in this section.

5.1 Adoption of CIQ TC Specifications by Industry Types

CIQ TC specifications have been widely adopted by different groups around the world and some of the key types of groups are as follows (for confidentially reasons, we are not in a position to publish the names of the groups):

· Governments, including e-Government

· Insurance Companies

· Banks

· Solution providers

· Telecommunication companies

· Product Vendors

· Retail companies

· Standard Bodies/Groups/Consortiums

· OASIS Technical committees (e.g. Election and Voter Services, HumanMarkUp, UBL, DITA, Emergency Management, Tax XML)

· Address Map Providers

· Open Source Community for CRM

· Postal Companies

· Manufacturing companies

· Financial Service Providers (e.g. credit cards)

· Automotive industry

· Justice Sector

· Health

5.2 Industry Applications using CIQ TC Specifications Family

Following are a selection of some of the key broad categories of applications that have implemented CIQ TC Specifications:

· Single Party View

· Address Maps (geo spatial information)

· Party recognition/identification

· Enterprise party data management

· Data Quality (e.g. parsing, matching, de-duping, verification, validation and enhancement)

· Party profiling

· Purchase orders, invoicing and shipping

· Party relationships management

· Party services

· Postal services

· Election services

· Justice, Legal and Corrective services

· Business Intelligence

· Party data interoperability frameworks

· Front end data capture

· Party data synchronization

5.3 Other Relevant Initiatives in Industry

CIQ TC is not the only group to attempt to create a set of standards for representing Party details. Though CIQ is the first group that is dedicated to create a global XML standard for party name, address, and party centric data, a number of other efforts are underway around the world to either define party related specifications/standards that is part of a particular application standard effort and not dedicated to defining specifications for party details from a global perspective. Following are the some of the other key industry initiatives that define party name/address/party details specifications/standards as part of its overall objective that were analysed by CIQ TC:

· British Standard 7666

· Address Data Interchange Specification (ADIS)

· HR-XML, Human Resource Markup Language

· UK GovTalk Address

· Universal Postal Union (UPU)

· Address Data Content Standard

· Australia-New Zealand Standard for Client Information Exchange (AS 4590)

· HL7

· OASIS UBL Library Subcommittee

· UN/CEFACT Core Components, TBG 17 Working Group

· ISO 11180:1993

· CEN WG331

· USIRA Address Standard

· STAR

· ACORD

· OAG

· ROSETTANET

· XBRL

· OTA

· IETF – vCard

· GJXDM

· FOAF

All the above standards/specifications were analysed by CIQ TC in terms of their support for name and address and party data models and their global, industry and application independence nature. CIQ specifications were also tested to see whether there are any data sets in the above specifications that could not be handled.

All of these standards/specifications have been designed with a particular business requirement or application in mind, for example, the expedient delivery of a piece of mail, invoicing and purchasing, health, and human resources, etc. or specifically designed for a country or a group of countries. This has generally meant that while the particular party standard/specification is appropriate for the purpose for which it was designed, it is frequently not suitable for a variety of other purposes across the different industries and different types of applications and importantly, on a global scale. For example, a standard might be suitable to represent party name and address data for postal purposes, but may not be suitable to use it for a data cleansing and data quality application which may require all name and address fields to be captured in its atomic form.

CIQ TC is the only dedicated international standards group that concentrates specifically on developing “international party specifications” for the industry that is not tied to or is part of any particular industry application specifications (e.g. supply chain, human resources, health, accounting, postal services, e-commerce, CRM, Geospatial, etc) . CIQ TC is also the first standards group to build party “name” and “address” XML specifications for industry that is truly “global”, “open”, and “application independent”. This enables CIQ specifications to be reused across all types of industries and applications that use party centric data.

A. Acknowledgements

The following individuals have participated in the creation of version 3.0 of CIQ specifications and are gratefully acknowledged:

Participants:

Colin Wallis	New Zealand Government	Voting Member, CIQ TC
David Webber	Individual	Voting Member, CIQ TC
Fulton Wilcox	Colts Neck Solutions LLC	Voting Member, CIQ TC
Graham Lobsey	Individual	Voting Member, CIQ TC
Joe Lubenow	Individual	Voting Member, CIQ TC
John Glaubitz	Vertex, Inc	Voting Member, CIQ TC
Michael Roytman	Vertex, Inc	Voting Member, CIQ TC
Ram Kumar	Individual	Chair and Voting Member, CIQ TC
George Farkas	XBI Software, Inc	Former Member, CIQ TC
Hidajet Hasimbegovic	Individual	Former Member, CIQ TC
John Putman	Individual	Former Member, CIQ TC
Mark Meadows	Microsoft Corporation	Former Member, CIQ TC
Max Voskob	Individual	Former Member, CIQ TC
Robert James	Individual	Former Member, CIQ TC

OASIS CIQ Technical Committee (TC) sincerely thanks the public (this includes other standard groups, organisations and end users) for their continuous feedback and support that helps the TC to work toward improving the CIQ specifications.

Special thanks to Mr.Ken Holman, Chair of OASIS Code List TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=codelist) for his support, guidance and genericode implementation assistance to the TC in releasing the OASIS Code List version of CIQ V3.0 XML Schemas.

Special thanks to Mr.Hugh Wallis, Director of Standards Development of extensible Business Reporting Language (xBRL) International Standards Group (http://www.xbrl.org) for working closely with the CIQ TC in jointly implementing W3C xLink specification that is now used by both xBRL and CIQ Specifications to enable interoperability between the two specifications.

Special thanks to Mr.Carl Reed, Chief Technology Officer of Open Geospatial Consortium (OGC – http://www.opengeospatial.org) for his guidance and assistance to the TC in referencing the work of OGC on GeoRSS and Geo-Coordinates for addresses/locations as part of CIQ Address Specifications.

OASIS CIQ TC also acknowledges the contributions from other former members of the TC since its inception in 2000.

B. Intellectual Property Rights, Patents, Licenses and Royalties

CIQ TC Specifications (includes documents, schemas and examples^{1 and 2}) are free of any Intellectual Property Rights, Patents, Licenses or Royalties. Public is free to download and implement the specifications free of charge.

¹xAL-AustralianAddresses.xml

Address examples come from AS/NZ 4819:2003 standard of Standards Australia and are subject to copyright

²xAL-InternationalAddresses.xml

Address examples come from a variety of sources including Universal Postal Union (UPU) website and the UPU address examples are subject to copyright.

xLink-2003-12-31.xsd

This schema was provided by the xBRL group in December 2006.

C. Revision History

Revision	Date	Editor	Changes Made
V3.0 PRD 01	13 April 2006	Ram Kumar and Max Voskob	Prepared 60 days public review draft from Committee Draft 01
V3.0 PRD 02	15 June 2007	Ram Kumar	Prepared second round of 60 days public review draft from Committee Draft 02 by including all public review comments from PRD 01. Also included is implementation of OASIS Code list specification
V3.0 PRD 02 R1	18 September 2007	Ram Kumar	Inclusion of comments from Public Review 02
V3.0	15 November 2007	Ram Kumar	Final Version
V3.0 CS02	15 September 2008	Ram Kumar	Final Version