The Algorithm that builds keys and search ranges for Person Names is invoked by a calling SSANAME3 by passing

FIELD=Person_Name

in the

Controls

parameter of the

get keys

or

get ranges

calls.

The

Person_Name

Algorithm is designed to overcome the error and variation that would be typically found in a person’s full name. This may include salutations and honorifics, special characters, embedded spaces, nicknames, different word orders, use of initials, spelling errors, concatenated words, localized words, foreign words, etc.

An application should pass the full person name to SSA-NAME3 functions. The word order, that is the position of the first name, middle names and family names, should be the normal word order used in your data population. For example, in English speaking countries, the normal word order would be:

First Name + Middle Name(s) + Family Name(s)

Depending on your table design, your application may have to concatenate these separate fields into one field before calling SSA-NAME3.

While SSA-NAME3 includes Search Strategies that overcome word order variations, the word order does have some significance in the quality of Narrow and Typical searches, and when matching using the Purposes "same Household", "same Family" or "same Wide_Household".

The application (or SSA-NAME3) may pass multiple names (such as a married name and a former name) in the one call to SSA-NAME3.

The

Person_Name

algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit RuleWizard.

The Algorithm that builds keys and search ranges for Organization Names is invoked by a calling application by passing

FIELD=Organization_Name

or

FIELD=Organisation_Name

in the

SSANAME3 Controls

parameter of the

get keys

or

get ranges

calls.

The

Organization_Name

algorithm is designed to overcome the error and variation that would be typically found in a business, company, institution or other organization name. The algorithm also caters for multiple names in the one field, and a mixture of Organization and Person names in the data population. The error and variation may include different legal endings, abbreviations, salutations and honorifics, special characters, embedded spaces, nicknames, different word orders, missing and extra words, spelling errors, concatenated words, use of initials, mixed use of numbers and words, foreign words, localization, etc.

This field supports matching on a single name, or a compound name (such as a legal name and its trading style).

The application (or SSA-NAME3) may also pass multiple names (such as a current name and a former name) in the one call to SSA-NAME3.

The

Organization_Name

algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit Rule Wizard.

The algorithm that builds keys and search ranges for Addresses is invoked by a calling application by passing

FIELD=Address_Part1

in the

SSA-NAME3 Controls

parameter of the

get keys

or

get ranges

calls.

The

Address_Part1

algorithm is designed to overcome the error and variation that would be typically found in addresses. The error and variation may include the presence of care of information, abbreviations, special characters, embedded spaces, different word orders, spelling errors, concatenated words and numbers, use of initials, mixed use of numbers and words, foreign words, missing words, extra words and sequence variations, etc.

An application should pass the part of address up to, but not including, the locality "last line". The word order, that is the position of the address components, should be the normal word order used in your data population. These should be passed in one field. Depending on your table design, your application may need to concatenate these attributes into one field before calling SSA-NAME3.

For example, in the US, a typical string to pass would comprise of:

Care-of + Building Name + Street Number + Street Name + Street Type + Apartment Details

But not including City, State, Zip, Country.

The application (or SSA-NAME3) may pass multiple addresses (such as a residential address and a postal address) in the one call to SSA-NAME3. See the

API REFERENCE

guide for more details.

The

Address_Part1

algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit Rule Wizard.

The code fields are a group of fields that support numeric or alphanumeric values. The code fields include the following fields:

Code
Telephone_Number
Date
CreditCard
VIN
ISBN10 or ISBN13

The code fields support the following Match Purposes:

CC_Owner
CC_Issuer
VIN_Owner
VIN_Manufacturer
AuthorISBN
PublisherISBN

Pass

FIELD=<Code Fields>

to SSA-NAME3 in the Controls parameter of the get_keys or get_ranges calls, where

Code Fields

can be one or more of the supported code fields. It invokes the algorithm that builds the keys and search ranges for the code fields. Identity Resolution passes the value to the

KEY-LOGIC

and

SEARCH-LOGIC

Controls parameters.

The algorithms of the code fields overcome any errors or variations that are common across the code entities, such as missing digits, different digit orders, and special characters.

Identity Resolution can pass multiple code fields as one code field in the form of a match purpose to SSA-NAME3.

For example, if you search for a credit card to find the customer name and the credit card issuer, you can use the

CC_Issuer

purpose.

The

Code

field matches any numeric or alphanumeric data. The algorithms of the

Telephone_Number

,

Date

,

VIN

,

ISBN10

or

ISBN13

, and

CreditCard

fields are specific to their processing domain. They carry less overhead than the generic

Code

field. However, the

Code

field algorithm reduces the overhead associated with the creation and maintenance of separate indexes. The application simplifies the search experience by not categorizing the search data.

The Population Override Manager or the Edit Rule Wizard can override the Edit-List rules of the algorithm that uses the

Code

field.

Pass

Field=Geocode

to SSA-NAME3 in the Controls parameter of the get_keys or get_ranges call to build keys and search ranges based on the latitude and longitude geographic coordinates. You can pass the Geocode field in the

KEY-LOGIC

and

SEARCH-LOGIC

Controls parameter.

The Geocode field matches the location or creates a search range based on the geographic coordinates that you specify.

You can specify the latitude and longitude geographic coordinates with an optional elevation. Specify the elevation value with its unit after the geographic coordinates. The supported units are feet (ft), kilometer (km), and meter (m). Negative elevation represents depths below the sea level.

For example, -23.399437,-52.090904, 203m

Use one of the following formats to specify the geographic coordinates:

-23.399437,-52.090904, 203m
40:26:46.302N 079:56:55.903W 192ft
40°26'47"N 079°58'36"W 0.203km
40d 26' 47" N 079d 58' 36" W 203
40.446195N 79.948862W
40.446195 -79.948862
40° 26.7717, -79° 56.93172
N40:26:46.302 W079:56:55.903
N40°26'47 W079°58'36"
N40d 26' 47" W079d 58' 36"
N40.446195 W79.948862

The Population Override Manager or the Edit Rule Wizard can override the Edit-List rules of the algorithm that uses the

Geocode

field. Define a geocode override rule as a character rule, which replaces or removes strings or numbers that include special characters or delimiters.

Pass

FIELD=Product_Name

to SSA-NAME3 in the Controls parameter to match the names of products. The

Product_Name

and

Product_Description

fields use word pairs or a bigram to search, match, and handle additional variations between product names and description. The

Model_Number

field is a matching field that compares two strings.

You can use the following optional search fields for a product:

Product_Description
Model_Number
Company_Name
ID
Code
Attribute1
Attribute2