OASIS Customer Information Quality TC

FAQ

The following common questions were collected from public who raised them with OASIS CIQ TC since its inception in 2000.

What is the need for CIQ specifications?
When CIQ TC was formed in 2000, there was no open industry specification/standard available to represent, exchange, and manage international party related data despite these being the key attributes for any global e-business/e-commerce. For further details, please read "CIQ TC — General Introduction and Overview" document.
Who should use CIQ Specifications?
Any organization dealing with party related data that has to be represented in a standard consistent manner in the organization and/or exchanged between internal applications and systems and with external partners in a standard and consistent manner that is not proprietary in nature and is an industry standard.
Who should be involved in the development of CIQ Specifications?
- Any organization/individual dealing with party related data should consider CIQ as a standard way of representing and exchanging party data between applications.
- Any organization/individual with an interest in helping to produce a common standard for exchanging party information between various processes, applications and systems that are not tied to specific industry, culture, country, or geographical boundaries.
Who will benefit from this work and how?
- Any organization that is planning to define a common standard for party information across its various lines of business and its various applications.
- Any organization that wants to leverage their party information in a B2B environment.
- Any organization that processes party information differently for different applications (e.g. simple customer registration/point of contact to name and address validation).
- Any organization that deals with global customers
- Any organization that wants to have a consistent and standard representation of party data
- Any organization that wants to represent party data by using an open industry standard with one or more of the following characteristics:
  - Open
  - Vendor Neutral
  - Can represent international party data
  - Application independent
  - Industry independent
  - Developed in an open process environment
  - Free of any IPRs, licenses, royalties, patents, etc
  - Readily available to use without any restrictions
  - Developed by global experts in party information management
  - Developed by public for the public
What does CIQ Specifications not cover?
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
- Quality enhancing process
Why developing Party information standard is such a "big deal"?
This is the statement we commonly hear from people who look at it. But the main point they miss is that they look at say, Party Name and Address from a specific context such as from a specific application perspective or a cultural perspective or a geographical perspective. A standard for Party Name and Address should deal with the following constraints and this is what OASIS CIQ Specifications has achieved that no other standard is able to:
- Represent names and addresses of 241+ Countries that are specific to race, religion, ethnicity, culture and geography/location
- Name and addresses represented in 5,000+ languages/dialects
- With 130+ Address Formats, and
- With 36+ Personal Name formats
- Independent of specific applications. For example, an application might just need Address Line 1, Address Line 23 and Address Line 3 to represent an address, while some other application might need to store and manage quality data by breaking down the address into street details, Premises details, suburb, post code, state, etc.
- Industry independent. For example, not to just deal with postal related services or Customer Relationship Management initiatives
We are living in a world of global commerce/business where anyone can do business with anyone on this earth without having to deal with each other physically. Party data is the key to any global commerce/business and exchange of party data between global parties and handling global party data within your applications and systems in a standard and consistent manner, and importantly not proprietary or application specific is becoming increasingly important. This is what CIQ specifications achieve. Global terrorism and crime is another major issue and one way of dealing with it is to exchange the right information at the right time to the right place in the right format and in the right context between the appropriate parties, and CIQ Specification provides the opportunity to exchange party related data (here, terrorists and criminal related data) in a standard and consistent manner.
What are the criteria and business value to an organization for selecting CIQ over the other similar standards in defining the organizations baseline architecture?
If your organization wants to use name and address not for just postal services, but also for other purposes as well (e.g. customer profile management, contact management, employee information, CRM application, customer identification, name and address parsing and validation, etc), then CIQ is the best choice as it is designed to accommodate all these applications.

If your organization wants to use name and address standard that can be extended to other party information (e.g. telephone, fax, email, URL, customer id, customer relationships, etc.) that are unique to the customer, then CIQ is the best choice.
What are the specifications produced by OASIS CIQ TC?
The following committee specifications have been produced by OASIS CIQ TC so far since its inception in 2000:
- extensible Name and Address Language (xNAL) to represent party name and address together
- extensible Name Language (xNL) to represent party name only
- extensible Address Language (xAL) to represent party address only
- extensible Party/Customer Information Language (xPIL/xCIL) to represent party centric data that uniquely identifies a party (in addition to name and address)
- extensible Party/Customer Relationships Language (xPRL/xCRL) to define party to party relationships
The specifications are modular, i.e. users can pick what specifications they want as they are independent of each other. For example, a user can just decide to use CIQ Specification for defining party name only and ignore the rest.
How does this work compare with related efforts at other standards organizations?
Numerous groups that work on party data standards in some form have been studied by CIQ TC. It is clear that OASIS CIQ TC is the only international standards group that is specifically dedicated to build party information standards that are application and industry independent and importantly, developed from a global/international perspective (i.e., not limited to a particular country or group of countries (e.g. western world). Other groups develop party information standards from a specific application or industry perspective (e.g. Postal addressing, human resources, health, billing, shipping, purchasing, travel).
What are the major entities defined by CIQ Specifications for Party Information?
CIQ Specifications are based around the following three party entities (person or organization) namely,
- Name
- Address, and
- Party Centric Information
How did CIQ TC manage to produce a global specification and was it tested?
It took over 2 years for the CIQ TC just to build the address specification to handle 241+ countries that is application and industry independent. Extensive research work and involvement of address management experts and contributions from end user community enabled the TC to produce this work.

Numerous use of the specification all over the world has been reported and any feedbacks provided have been used to improve the specifications. The TC continues to test the specifications with international data.
Are there any IP, Patent or Royalty issues for CIQ Standards?
CIQ Standards are free of any IP issues, Patent, License, or Royalty. It is free of any licensing/commercial issues. Anybody can download and use the CIQ standards for free. It is advisable to read the OASIS Copyright notice and policy on IP.
Is CIQ TC working with other similar standard groups?
CIQ TC is committed to collaborative work. CIQ TC continues to strive hard all these years to foster alignment with other similar standard initiatives. Given that CIQ has already done the important base work of defining standards that are global and application independent, it makes life easier for other groups to extend the standard for domain specific applications such as postal services. CIQ and OASIS in general, are open for any collaborative work in an "open" process manner to ensure that there is no duplication of work.

CIQ is speaking and has spoken to many groups and most of the time. CIQ TC has initiated this process. It is hard to collaborate politically, but it is easier technically.
Are CIQ Standards such as xNAL designed for the CRM world only?
Definitely not. They have been designed to be application independent. Let us say, for example, in an organization or a government sector, there are many applications dealing common data such as name and address. The applications using say, name and address could be a CRM, user registration on web, billing, marketing, sales, name and address cleansing and quality, etc. The optimal way to interoperate name and address data is to store the name and address information in a common format that can be applied or reused across different applications. But organizations often end up storing name and address data in many different formats specific to the applications and hence, are unable to integrate different applications to meet business needs (e.g. integrate applications to get all info. about a party). To store name and address information in a common format, you need a standard that is flexible enough to be applied to different requirements of the application. This is precisely what CIQ standards have been defined for and this is why it is flexible to store simple user registration data (e.g. address line 1, address line 2, city, state, postcode, country) to detailed level of data for complex applications like name and address parsing and matching which requires detailed level of elementization of the name and address data.
Why did you decide to release a new version (3.0)?
Earlier version of CIQ that had the following limitations and issues:
- ambiguous by providing multiple options for representing the same information
- offering a complex model for simple representation of name and address data
- difficult to implement as an object model
- perceived as being complex for many applications that required minimal representation
- semantically incorrect for many country name and address data that are bound by its culture and geographical boundaries
- no means of putting constraints on the specifications, but at the same time ensuring conformance to the specifications
For further information, see "CIQ TC Technical Overview (version 3.0)" document.
Is version 3.0 of CIQ Specifications backward compatible with version 2.0?
No, version 3.0 of CIQ Specifications is not backward compatible with version 2.0 of CIQ Specifications. However, any party related data represented in version 2.0 can be represented in version 3.0.
I feel that CIQ Specifications are very rich to handle complex name and address structures. I want something that provides a simple representation of name and address. Can CIQ provide me this?
Yes, definitely. CIQ V3.0 has been designed to enable users to extend or customize the CIQ XML Schemas to meet their specific application requirements. Users have been provided the following features in the specifications:
- Restrict the use of different elements and attributes defined in the CIQ specifications
- Add more semantics to the data that is represented using CIQ specifications
- Add more attributes from non target namespaces to extend the schemas
- Write business rules outside of the CIQ schema to constrain the grammar of the CIQ schemas
- Extend the schema by adding more attributes from non target namespaces
So, for example, if a user wants to represent an address structure with address lines only, or a combination of address lines with structured data fields, or by using only structured data fields, CIQ provides these capabilities using the approaches outlined above. This features also assists users to customize CIQ name and address XML schemas to be specific to their country name and address structure.

A simple address example is shown below:

Simple Representation of an Address (Unstructured)

16 Patterson Street, OCEAN REEF, WA
```
<a:Address>
    <a:FreeTextAddress>
       <a:AddressLine>16 Patterson Street</a:AddressLine>
       <a:AddressLine>OCEAN REEF</a:AddressLine>
       <a:AddressLine>WA</a:AddressLine>
    </a:FreeTextAddress>
</a:Address>
```
Semi Complex Representation of an Address (Semi Structured)

16 Patterson Street, OCEAN REEF, WA
```
<a:Address>
    <a:FreeTextAddress>
       <a:AddressLine>16 Patterson Street</a:AddressLine>
    </a:FreeTextAddress>
    <a:AdministrativeArea a:Type="State">
       <a:NameElement>WA</a:NameElement>
    </a:AdministrativeArea>
    <a:Locality a:Type="Suburb">
       <a:NameElement>OCEAN REEF</a:NameElement>
    </a:Locality
</a:Address>
```
Complex Representation of an Address (Structured)

16 Patterson Street, OCEAN REEF, WA
```
<a:Address>
    <a:AdministrativeArea a:Type="State">
        <a:NameElement>WA</a:NameElement>
    </a:AdministrativeArea>
    <a:Locality a:Type="Suburb">
        <a:NameElement>OCEAN REEF</a:NameElement>
    </a:Locality>
    <a:Thoroughfare a:Type="Street">
        <a:Name>Patterson</a:Name>
        <a:Number>16</a:Number>
    </a:Thoroughfare>
</a:Address>
```
See "CIQ TC - Name, Address and Party Specifications" document and "CIQ Technical Overview" document of version 3.0 specifications that explain how to customise the schemas to meet your requirements.
How can I customise Name and Address CIQ Specifications, i.e., I want a simplified version (light weight) of xNL and xAL specifications?
Version 3.0 of CIQ xNL and xAL specifications have been designed to be lightweight compared to Version 2.0. See "CIQ TC - Name, Address and Party Specifications" document of version 3.0 specifications that explains how to customise the schemas to meet your requirements.
Is there any reason why enumeration lists are used extensively in place of fixed element names, like FirstName, MiddleName, LastName for party names and for other specifications of CIQ in version 3.0?
CIQ specifications have been designed from a global/international perspective where cultural and geographical boundaries determine how party names and addresses are represented. Earlier versions of CIQ specifications made it harder for countries to implement CIQ that is semantically correct in terms of the "terms" used. For example, the concept of First Name, Middle Name, Last Name, SurName or Family Name does not exist in many cultures. Earlier versions forced those countries to use these concepts defined in CIQ specifications though they are not semantically correct. This is the reason why it was decided in CIQ V3.0 to allow users to define the semantic meaning of the data that is represented using CIQ. Enumeration lists provide the semantics to the data and is customisable by users.
Does CIQ have any working relationship with xBRL?
Yes, CIQ party data can be interoperated with xBRL. The xLink schema used in CIQ (xLink-2003-12-31.xsd) was jointly developed by CIQ TC and xBRL to achieve interoperability when it comes to linking party data.
Does CIQ have any working relationship with OGC?
Yes, CIQ Specifications reference the work of Open Geospatial Consortium (OGC — http://www.opengeospatial.org) for defining location coordinates and this work was done with the assistance of OGC.
Does CIQ have any working relationship with OASIS Code List Representation Technical Committee?
Yes, CIQ Specifications use the work of OASIS Code List Representation TC (http://www.oasis-open.org/committees/codelist) to define genericode based approach for code list representation and for two pass validation. CIQ TC worked closely with the OASIS Code List TC to get this implementation done.
Are there implementations of xLink parsers?
Yes, there are many. For more details, go to http://www.w3.org/XML/Linking
Are CIQ Specifications flexible enough to allow users to customize them to meet their specific requirements?
Yes, CIQ Specifications are flexible and provides the following features to the users to customize them to meet their specific requirements:
- Ability to users to choose the elements and attributes used in CIQ XML Schemas they want to use
- Ability to reuse only the CIQ entities they want as Name, Address, and Party centric information are independent components
- Provides two ways to customize code lists that add semantic meaning to the data. This customization can also be achieved using an industry standard approach without modifying the core CIQ XML Schemas
- Ability to write business rules using an industry standard approach to constrain the core CIQ XML Schemas without modifying the Schemas
By customizing the CIQ Specifications using Code Lists approaches, will this not break compatibility with the specification and interoperability?
Customisation of the specifications without touching the core XML schemas provided the CIQ entities namely, Name, Address and Party does not break the compatibility. But customising the specifications using code lists approaches and business rules, requires agreement with other parties that are involved in data exchange with your application/system that have implemented CIQ specifications to ensure interoperability. One cannot fully automate interoperability without some agreement (e.g. service level agreement, interoperability agreement) between the parties that are involved in data exchange. So, agreement between the parties regarding customisation of CIQ specifications is extremely important to achieve interoperability.
CIQ Specifications are rich and my application does not need such complexity to define, say name and address of a customer. What do I do?
This is the statement we commonly hear from people who look at it. But the main point they miss is that the specification aims at application and industry independency, i.e. not specific to a particular application area, and hence is rich in nature. But version 3.0 allows users the option to customize the specifications to meet their application specific requirements without touching the CIQ core schemas, but at the same time maintain compatibility and conformity with the specifications. For example, take address specification (xAL). If a user wants to just use free text address lines and a few of the address entities (e.g. locality, and postcode), they can define business constraint rules outside of the core schema that ignores the unwanted address entities. See "CIQ TC - Name, Address and Party Specifications" document of version 3.0 specifications that explains how to do this. The following example demonstrates the flexibility provided by CIQ Specifications:

Example - Simple Representation of Party Name and Address Data

Mr H G Guy, 9 Uxbridge Street, Redwood, Christchurch
```
<nal:Record>
    <n:PartyName>
       <n:NameLine>Mr H G Guy</n:NameLine>
    </n:PartyName>
<a:Address>
        <a:FreeTextAddress>
           <a:AddressLine>9 Uxbridge Street</a:AddressLine>
           <a:AddressLine>Redwood</a:AddressLine>
           <a:AddressLine>Christchurch</a:AddressLine>
        </a:FreeTextAddress>
</a:Address>
</nal:Record>
```
Example — Complex Representation of Party Name and Address Data

Mr H G Guy, 9 Uxbridge Street, Redwood, Christchurch
```
<xnal:Record>
    <n:PartyName>
    <n:PersonName>Mr H G Guy
        <n:NameElement n:ElementType="Title>Mr</n:NameElement>
        <n:NameElement n:ElementType="FirstNameInitial">H</n:NameElement>
        <n:NameElement n:ElementType="MiddleNameInitial">G</n:NameElement>
        <n:NameElement n:ElementType="LastName">Guy</n:NameElement>
        </n:PersonName>
    </n:PartyName>
    <a:Address>
        <a:AdministrativeArea>
        <a:NameElement>Christchurch</a:NameElement>
        </a:AdministrativeArea>
        <a:Locality>
        <a:NameElement>Redwood</a:NameElement>
        </a:Locality>
        <a:Thoroughfare>>
        <a:Name>Uxbridge Street </a:Name>
        <a:Number>9</a:Number>
        </a:Thoroughfare>
   </a:Address>
</xnal:Record>
```
Given that xNL and xAL supports all types of international names and addresses, my requirement is only to support a particular country names or addresses. How can I achieve this?
The easiest way to tailor the schema to your requirements is to make changes to the code list/enumerations that are placed in separate files for this purpose and/or define business rules using industry standard approach outside of the CIQ core XML schemas to constrain the schemas. Two types of approaches are provided to customize code lists/enumerations.

Read "CIQ TC - Name, Address and Party Specifications" document of version 3.0 specifications that explains how to customise the schemas to meet your requirements.
Why do I want to represent the party data in parsed format?
If you are required to understand the semantics of party data and ensure that the quality of party data is managed, you need to parse the party data and represent them in parsed format. Parsed data helps in performing data validation and matching against reference data or any other data sets.
I do not want to break/parse the address/name data elements into atomic elements? Can CIQ schemas handle unparsed data elements?
Yes, you do not need to break your data elements to atomic elements to use CIQ schemas. CIQ schemas help you to store parsed/unparsed data elements. However, to enable clean interoperability of your data elements, it is advised to break to unparsed data elements into atomic elements which add semantics to your data elements. This also enables to keep your databases clean with quality information/data. Note that the quality of any information processing/management system is only as good as the quality of the data it stores/processes. Below is an example that demonstrates this:

Example — Unstructured/Not Parsed Simple Name Representation

Dr Jeremy Apatuta Johnson III PhD
```
<n:PartyName>
    <n:PersonName>
        <n:NameLine>Dr Jeremy Apatuta Johnson III PhD</n:NameLine>
    </n:PersonName>
</n:PartyName>
```
Example — Structured/Parsed Complex Name Representation

Dr Jeremy Apatuta Johnson III Phd
```
<n:PartyName>
    <n:PersonName>
        <n:NameElement Abbreviation="true" ElementType="Title">Dr</n:NameElement>
        <n:NameElement ElementType="FirstName">Jeremy</n:NameElement>
        <n:NameElement ElementType="MiddleName">Apatuta</n:NameElement>
        <n:NameElement ElementType="LastName">Johnson</n:NameElement>
        <n:NameElement ElementType="GenerationIdentifier">III</n:NameElement>
        <n:NameElement ElementType="Title">PhD</n:NameElement>
    </n:PersonName>
</n:PartyName>
```
Are CIQ Specifications defined with the aim of achieving interoperability of data?
Absolutely. CIQ TC since its inception has been advocating the importance of data interoperability and data quality. The CIQ TC is of the strong view that data quality plays a significant role in interoperability. The quality of any information management/processing system is only as good as the quality of the data it processes/stores/manages. No matter how efficient your exchange system is, if the quality of data that is interoperated is poor, the business benefit arising out of the information processing system is expected to be poor. Always remember, "Garbage In, Garbage Out".
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. CIQ specifications have been designed with the above formula in mind.
In addition to representing an address using xAL, what other key attributes can be represented using xAL?
You can represent the following using xAL also:
- History (Valid dates of an address, change of address history)
- Type of address
- How the address is used (e.g. for mailing purposes, for communication purposes, etc)
- Postal ID
- Address Usage
- Address Status
- Unique identifier
- Geospatial information
- Quality of address
- Language used to represent address
- Primary and secondary addresses in the same structure
- Multiple delivery points in the same address such as postal and street delivery points (common in many applications)
Do CIQ V3.0 Specifications support geo-coding?
Yes, they do. xAL (the Address Schema) reference GeoRSS from Open Geospatial Consortium and also provide a base set of elements for location coordinates.
I have already implemented version 2.0 of the CIQ Specifications. Do I need to move to version 3.0 of the specifications?
This really depends on your requirements. If there are no requirements for you to move to version 3.0, then stay with your current implementation. Version 3.0 is a much simplified and compact set of schemas to make the life of a developer easier. However, note that V3.0 is not backward compatible with V2.0 CIQ Specifications. The schema structures are different and the design approach is different. But representation of different types of data in V2.0 can also be represented in V3.0.
CIQ Specifications (Version 3.0) meets my requirements. But how do I start implementing the specifications?
First, download the specifications and supporting documents from http://docs.oasis-open.org/ciq.
I am concerned with some of the contents of the CIQ version 3.0 specifications (e.g. missing pieces, errors, etc)? What do I need to do?
OASIS CIQ Specifications are developed in a truly "Open" process environment. We are keen to receive any sort of feedback from public and we look into the feedbacks seriously. This helps us to improve the specifications. So, please, use "Send A Comment" feature on CIQ TC home page (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq)
Do OASIS CIQ Specifications support data quality?
Yes, Version 3.0 of the CIQ specifications provides support for defining the quality of data (e.g. valid, invalid, valid at source, 90% confident, etc) and the date of validity of the quality.

CIQ specifications are not a quality enhancing process as commonly understood or akin to a certificate of test results against some objective specification.
By implementing CIQ Specifications, can I achieve interoperability of Party data between applications/business systems?
Yes you can, provided the exchange is managed properly. No data exchange for interoperability can be automated without some sort of information exchange agreement is in place at application design time. CIQ specifications are powerful in terms of providing the users the flexibility to customize it to meet their specific requirements. Flexibility is indirectly proportional to interoperability. The more flexible the specification is, less the chances are that interoperability will be achieved, because users will tend to implement the specifications in their own ways. This is where information exchange agreements are helpful in managing implementation of the specifications by more than one party involved in the data exchange. With an information exchange agreement in place, CIQ specifications will enable 100% interoperability of party related data between applications/systems.
Are there any restrictions in using the OASIS CIQ Specifications?
No, there are no restrictions in using the OASIS CIQ Specifications (any version). These specifications are free for public to download and use them. There are no Intellectual Property Rights, Licenses, royalties, patents or any "strings" attached to the specifications that limit the use of the specifications.

CIQ Specifications are truly an "international open standard" developed in an "open process" environment. Users of the specifications are advised to read the OASIS Copyright notice.

OASIS CIQ Specifications are developed by the public for the public.
Can I contribute to developing OASIS CIQ Specifications?
Definitely. OASIS CIQ TC is constantly looking for participants. There is no restriction to who can and cannot contribute as OASIS process is truly open. OASIS CIQ Specifications are by the public for the public.
Who have/and are used/using CIQ Specifications?
CIQ TC specifications have been widely adopted by different groups, organisations and end users around the world since its inception in 2000, 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
- Insurance
- Banking
- Retail
What are the applications that have implemented CIQ specifications?
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