1 Name, Address and Party

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

While RFC2119 permits the use of synonyms, to achieve consistency across specifications, "MUST" is used instead of "SHALL" and "REQUIRED", "MUST NOT" instead of "SHALL NOT", and "SHOULD" instead of "RECOMMENDED" in this specification. To enable easy identification of the keywords, uppercase is used for keywords.

1.2 Definitions

Following are the core entities and its definitions used by CIQ TC:

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 (e.g. Name, Address, email address, telephone, etc) that are unique to a party. However, a person or organization's name and address are generally the key identifiers (but not necessarily the unique identifiers) of a "Party". A "Customer" is of type "Party".

2 Schema Design Approach in Version 3.0

Name, Address and Party schemas of version 3.0 share the same design concepts. The commonality should simplify understanding and adoption of the schemas. The xNAL schema design concept varies slightly as it is only a simple container for associating names and addresses.

Name, Address and Party schemas are designed to bring interoperability to the way these most "common" entities are used across all spectrums of business and government.

2.1 Version 3.0 Schema Files

Following are the different schemas produced for version 3.0:

Schema File name	Description	Comments
xNL.xsd	Entity Name	Defines a set of reusable types and elements for a name of individual or organisation
xNL-types.xsd	Entity Name Enumerations	Defines a set of enumerations to support Name entity
xAL.xsd	Entity Address	Defines a set of reusable types and elements for an address, location name or description
xAL-types.xsd	Entity Address Enumerations	Defines a set of enumerations to support address entity
xNAL.xsd	Name and Address binding	Defines two constructs to bind names and addresses for data exchange or postal purposes
xNAL-types.xsd	Name and Address binding Enumerations	Defines a set of enumerations to support name and address binding
xPIL.xsd (formerly xCIL.xsd)	Entity Party (organisation or individual)	Defines a set of reusable types and elements for a detailed description of an organisation or individual
xPIL-types.xsd	Entity Party (organisation or individual) Enumerations	Defines a set of enumerations to support party information entity
CommonTypes.xsd	Common Data Types and Enumerations	Defines a set of commonly used data types and enumerations in the CIQ Schemas
xLink-2003-12-31.xsd	xLink attributes	Defines a subset of xLink attributes as XML schema
*.gc files	Entity Party, Name, and Address	Defines a set of enumerations/code lists in genericode

2.2 Formal Design Requirements for Version 3.0

Following are the formal design requirements taken into consideration for version 3.0 schemas:

· Data structures SHOULD be described using W3C XML Schema language

· Data structures SHOULD be separated into multiple namespaces for reuse of the main fundamental entities (e.g. Person Name, Organisation Name, Address)

· Data structures SHOULD be able to accommodate all information types used for data exchanges based on previous versions of the CIQ Specifications

· Data structures SHOULD be extensible (also, allow reduction in complexity) to provide enough flexibility for point-to-point solutions and application-specific scenarios

· Data structures SHOULD allow organisation-specific information to be attached to entities without breaking the structure.

· Implementation complexity SHOULD be proportional to the complexity of the subset of data structures used by the implementer

2.3 Major CIQ Specification Entities

The entire party information space is divided into a number of complex information types that are viewed as basic entities. This enables re-use of the basic entities as required. Following are the basic CIQ specification entities:

· Name (Person or Organisation - see xNL.xsd)

· Address (see xAL.xsd)

· Name and Address combined (see xNAL.xsd)

· Personal details of a person (see xPIL.xsd)

· Organisation specific details (see xPIL.xsd)

· Party Relationships (see xPRL.xsd [not available in this release] and xLink-2003-12-31-revised.xsd)

These major entities are supported by code lists to add "semantics" to the data they represent. We categorise the major entities of CIQ Specifications into three namely,

· Name

· Address, and

· Party Centric Information

2.4 Common Design Concepts used in the Specifications

The design concepts of name, address and party schemas are very similar in terms of the way semantic information (e.g. Semantic information for a person name is "Given Name, "Middle Name' Surname" etc, i.e. adding semantics to the data) is represented.

All the common design concepts used in the CIQ Specifications (e.g. using code lists, customizing CIQ entity schemas, extending CIQ entity schemas, referencing between entities, defining business rules to constrain CIQ entity schemas) are equally applicable for all key entities of CIQ specifications namely, Name, Address and Party. These common concepts are explained in detail in section 3 (Entity "Name"). Users SHOULD study that section in detail before proceeding to other entities namely, Address and Party, as these concepts are applicable to these entities also.

2.5 Namespaces

Entity	Namespace	Suggested Prefix	Schema Files
Name	urn:oasis:names:tc:ciq:xnl:3	xnl or n	xNL.xsd xNL-types.xsd
Address	urn:oasis:names:tc:ciq:xal:3	xal or a	xAL.xsd xAL-types.xsd
Name and Address	urn:oasis:names:tc:ciq:xnal:3	xnal	xNAL.xsd xNAL-types.xsd
Party	urn:oasis:names:tc:ciq:xpil:3	xpil or p	xPIL.xsd xPIL-types.xsd
Party Relationships	urn:oasis:names:tc:ciq:xprl:3	xprl or r	xPRL.xsd
xLink	http://www.w3.org/1999/xlink	xLink	xLink-2003-12-31.xsd

2.6 Other Industry Specifications Used

This document contains references to XML Linking Language (XLink) Version 1.0, W3C Recommendation 27 June 2001 available at http://www.w3.org/TR/xlink/ . The CIQ TC strongly recommends readers to read the xLink specification from W3C if they want to use this supported feature in CIQ Specifications.

This document contains references to Code List version 1.0, OASIS Committee Specification, May 2007 at http://www.oasis-open.org/committees/codelist. The CIQ TC strongly recommends readers to read the code list specification if they want to use this supported feature in CIQ Specification.

GeoRSS 2.0 (georss.org) from Open Geospatial Consortium (http://www.opengeospatial.net) has been referenced in this specification as it is critical to assuring interoperability with a variety of geospatial technologies, such as GIS, Spatial Data Infrastructures, Location Services, and the GeoWeb.

3 Entity "Name"(extensible Name Language)

Entity "Name" has been modelled independent of any context as a standalone class to reflect some common understanding of concepts "Person Name" and "Organisation Name".

3.1 Semantics of "Name"

Name schema is separated into two parts: a structural part (xNL.xsd) as shown in the XML schema diagram below and separate enumeration/code list files (code lists defined in an XML schema (xNL-types.xsd) and also, code lists represented in genericode format as .gc files) supporting the structure. "Genericode" will be discussed in later sections. The structural part (xNL.xsd) SHOULD remain unchanged over the course of time while the code list/enumeration files (xNL-types.xsd and .gc files) MAY be easily changed to meet particular implementation needs.

In the schema structure above (xNL.xsd), "NameElement" stores the name of a party and the supporting enumeration lists referenced as attributes in the schema structure (see the xNL.xsd schema for the list of attributes or the HTML documentation of the schema), provide the semantic meaning of the data.

The structure allows for different semantic levels based on the following paradigm:

· A simple data structure with minimum semantics SHOULD fit into the schema with minimal effort

· A complex data structure SHOULD fit into the schema without loss of any semantic information

3.1.1 Example 1 - No Semantics (Unstructured/Free Text Data)

A typical database does not differentiate between a person and an organisation name where only one field has been allocated for storing the entire name information (unstructured data). This database can be mapped to xNL as follows:

<n:PartyName>

<n:NameLine>Mr Jeremy Apatuta Johnson</n:NameLine>

</n:PartyName>

In this example, information related to party name, resides in NameLine element. It has no semantic information that MAY indicate what kind of name it is and what the individual name elements are (i.e., the data has not been parsed into first name, last name, title, etc.). What is known is that it is a name of some party, be it a person or an organisation. This is the maximum level of complexity. Data in this free formatted text form is classified as "poor quality" as it is subject to different interpretations of the data and will cause interoperability problems.

Many common applications fall under this "No Semantics" category.

3.1.2 Example 2 - Minimal Semantics (Partially Structured Data)

The medium level of complexity is when a database differentiates between person and organisation name. In this case, names are placed in the appropriate elements namely, PersonName or OrganisationName inside the structure.

Person Name:

<n:PartyName>

<n:PersonName>

<n:NameElement>Mr Jeremy Apatuta Johnson</n:NameElement>

</n:PersonName>

</n:PartyName>

This example shows that name information belongs to an individual, but the semantics of the individual name elements (e.g. what are the meanings of "Mr", "Jeremy", etc.) are unknown.

Organisation Name:

<n:PartyName>

<n:OrganisationName>

<n:NameElement>Khandallah Laundering Ltd.</n:NameElement>

</n:OrganisationName>

</n:PartyName>

This example is similar to the previous one, except that the name belongs to an organisation.

Many common applications fall under this of "Minimal Semantics" category.

3.1.3 Example 3 - Full Semantics (Fully Structured Data)

The maximum level of complexity is when a database differentiates between person and organisation name and also differentiates between different name elements within a name. The data is structured.

<n:PartyName>

<n:PersonName>

<n:NameElement Abbreviation="true" ElementType="Title">Mr</n:NameElement>

<n:NameElement ElementType="FirstName">Jeremy</n:NameElement>

<n:NameElement ElementType="MiddleName">Apatuta</n:NameElement>