Customer Information Quality (CIQ)
Specifications Version 3.0 – General Introduction and Overview
Public Review Draft 02
15 June 2007
Specification URIs:
This
Version:
http://
docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-introduction-v3-prd2.html
http://docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-introduction-v3-prd2.doc
http://docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-introduction-v3-prd2.pdf
Previous
Version:
N/A
Latest
Version:
http://docs.oasis-open.org/ciq/v3.0/supp/ciq-introduction-v3.html
http://docs.oasis-open.org/ciq/v3.0/supp/ciq-introduction-v3.doc
http://docs.oasis-open.org/ciq/v3.0/supp/ciq-introduction-v3.pdf
Technical
Committee:
OASIS Customer Information
Quality TC
Chair(s):
Ram Kumar
(kumar.sydney@gmail.com)
Editor(s):
Ram Kumar
(kumar.sydney@gmail.com)
Related
work:
This version of the CIQ
specifications replaces or supercedes:
·
OASIS CIQ extensible Name Language (xNL) V2.0 Committee
Specification
·
OASIS CIQ extensible Address Language (xAL) V2.0 Committee
Specification
·
OASIS CIQ extensible Name and Address Language (xNAL) V2.0
Committee Specification
·
OASIS CIQ extensible Customer Information Language (xCIL) V2.0
Committee Specification
Abstract:
This document provides a quick and general
introduction and overview about the CIQ 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.
Copyright ©
OASIS® 1993–2007. All Rights Reserved.
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.
1
Introduction.. 5
2
Name, Address and Party.. 6
2.1 Definitions. 6
2.2 General Applications of Party
Information.. 6
2.3 Problems due to lack of an industry
standard to 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?. 8
2.6 CIQ TC’s Formula for Successful
Data Interoperability..
9
2.7 Using Party Related Data - Use Case Scenarios. 9
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 Organization Relationships. 18
4.6.3 Organization to Organization 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
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.
Name
Name of a person or an
organization
Address
A physical location or a mail delivery
point
Party
A Party could be of two types
namely,
·
Person
·
Organization
An Organization could be a company,
association, club, not-for-profit, private firm, public firm, consortium,
university, school, etc.
Party data consists of many attributes.
However, a person or organization’s name and address are the key identifiers
of a “Party”. A “customer” is of type
“Party”.
Party specific
data are very 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 organization, the
organization synchronizes 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 easily included in other schemas when
describing party details.
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 terrorism and other unlawful activities
around the world requires party profile data exchange between countries, high
reliability in party identity screening and verification, regardless of country,
language, culture and geographical boundaries. Party industry standards play a
significant role to meet this serious, but important requirement.
·
Party data plays a critical role in uniquely
recognizing/identifying a person/organization in order to get a complete, clear and
consistent understanding of the person/organization to provide effective and
efficient services. To date this is an outstanding critical issue for most
organizations 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 customer – the foundation for successful Party Relationship
Management (e.g. CRM), Business Intelligence (BI), data warehousing and other
party/customer-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.
·
Organizations 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” organization could use its party details data for
some or all of the following applications:
·
Party/Customer Profiling/Management
·
Party/Customer Marketing initiatives
·
Party/Customer 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
With a global world as the market for an
organization 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.
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 organizations 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, organizations 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.
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.
We at OASIS CIQ TC strongly believe in the
following “Data Interoperability Success Formula”:
Data Interoperability = Open Data
Architecture + Data Integration + Data Quality + Open Data Standards + Data
Semantics + 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).
Numerous use
case scenarios can be listed to demonstrate how party data is used in organizations
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.
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 to develop the party information standards under the 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)
In this section, we summarise the
evolution of OASIS CIQ TC Specifications.
The diagram below summarises the evolution
of xNL, xAL and xNAL Specifications since 1999.
The diagram below summarises the evolution
of xCIL/xPIL 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.
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
|
-
|
xNL defines an XML format to represent
party name information. A party name could be a “Person” or an
“Organization”. An “Organization” 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 party names names in
over 36 formats internationally.
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.
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
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)
xPRL defines XML specifications to
represent implicit and explicit party relationships. Party relationships could
be:
·
Person to Person relationships
·
Person to Organization relationships, and
·
Organisation to Organization 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 Organization Structure (Employee-Employee
Relationship)
Some examples of Person to Organization
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.
·
Organization structure
Some examples of Organization to
Organization 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
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.
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)
·
Address Map Providers
·
Open Source Community for CRM
·
Postal Companies
·
Manufacturing companies
·
Financial Service Providers (e.g. credit cards)
·
Automotive industry
·
Justice Sector
·
Health
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
CIQ TC is not
the only body to attempt to create a set of standards for representing Party
details. Though CIQ was the first to create a global XML standard for party name
and address 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:
·
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 analyzed by CIQ TC in terms of their support for name and address and party
data models and their global, industry and application independence
nature.
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
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
quality application which may require all name and address fields to capture 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”.
The following
individuals have participated in the creation of this specification and are
gratefully acknowledged:
Participants:
|
John Glaubitz
|
Vertex, Inc
|
Member, CIQ TC
|
|
Max Voskob
|
Individual
|
Former Member, CIQ TC
|
|
Hidajet Hasimbegovic
|
Individual
|
Member, CIQ TC
|
|
Robert James
|
Individual
|
Member, CIQ TC
|
|
Joe Lubenow
|
Individual
|
Member, CIQ TC
|
|
Mark Meadows
|
Microsoft Corporation
|
Member, CIQ TC
|
|
John Putman
|
Individual
|
Former Member, CIQ TC
|
|
Michael Roytman
|
Vertex, Inc
|
Member, CIQ TC
|
|
Colin Wallis
|
New Zealand Government
|
Member, CIQ TC
|
|
David Webber
|
Individual
|
Member, CIQ TC
|
|
Graham Lobsey
|
Individual
|
Member, CIQ TC
|
|
George Farkas
|
XBI Software, Inc
|
Member, CIQ TC
|
OASIS CIQ
Technical Committee (TC) also wishes to acknowledge contributions from former
members of the TC since its inception in 2000. Also, the TC would like to express
its sincere thanks to the public in general (this includes other standard groups,
organizations and end users) for their feedback and comments that helped the TC to
improve the CIQ specifications.
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.
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 assistance to the TC in releasing the OASIS Code List version of CIQ V3.0
XML Schemas.
Last but not
least, the TC thanks all users of the CIQ TC specifications in real world and for
their continuous feedback and support.
CIQ TC
Specifications (includes documents, schemas and examples1 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.
1xAL-Australia.XML
Address examples come from AS/NZ
4819:2003 standard of Standards Australia and are subject to copyright
2xAL-International.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.
|
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
|
