Design Guide

10.5 HotFix 2
- 10.5 HotFix 1
- 10.5
- 10.2 HotFix 1
- 10.2
- 10.1
- 10.0 HotFix 1
- 10.0

Back Next

Score-Logic

Score Logic is defined in the Search-Definition. It specifies how the Search Server will select records to be returned from the set of candidates. Score-Logic facilities are provided by a SSA-Name3 Standard or Custom Population.

PRE-SCORE-LOGIC

is used to define an optional "light weight" scoring scheme that is processed before the normal

SCORE-LOGIC

. Its purpose is to make a fast, inexpensive decision to accept or reject the current record to avoid passing it to the more costly

SCORE-LOGIC

. Refer to the

Reducing Scoring Costs

section for details.

Syntax


[PRE-]SCORE-LOGIC=SSA,
						System (system),
						Population (population),
						Controls (controls),
						Matching-Fields (field-list)

where

system

is the System Name of the Population Rules DLL.

population

defines the population name from the DLL.

controls

defines the controls to be used for this Score-Logic. Refer to the

STANDARD POPULATIONS

guide for a detailed description of these fields. Controls should specify the desired

PURPOSE

and

MATCH_LEVEL

field-list

is a comma-separated list of the form

field_name:data_type

where

field_name

is the name of a field in the IDT and the

data_type

is the data type that this field represents, as defined in the Population Rules.

Repeating Fields

The

field_list

defines which IDT fields will be used for matching and the type of data they represent (

data_type

). Matching will use repeat logic when two or more fields of the same

data_type

are specified. A run-time error will occur if a data_type defined as mandatory for the

PURPOSE

has not been specified in the

field_list

. Optional data_types may be omitted.

For example,


SCORE-LOGIC=SSA,
				System(default), Population(test),
				Controls("PURPOSE=Person_Name MATCH_LEVEL=Loose"),
				Matching-Fields("LastName:Person_Name,Alias:Person_Name")

When using a Group of repeating fields (or flattened fields) for matching, you must list each individual field name. For example, the following source definition,

test.person.nameName [5] C(20)

generates a Group in the File-Definition of this IDT, which is subsequently expanded to the following list of field names:


FIELD=Name, C, 20
FIELD=Name_2, C, 20
FIELD=Name_3, C, 20
FIELD=Name_4, C, 20
FIELD=Name_5, C, 20

The Matching-Fields parameter must list the fields

Name

Name_2

Name_3

Name_4

and

Name_5

It is also possible to use the shorthand method of describing repeating fields. For details refer to the Key Logic section. For Example:


SCORE-LOGIC=SSA,
				System(default), Population(test),
				Controls("PURPOSE=Person_Name MATCH_LEVEL=Loose"),
				Matching-Fields("Name[1-3]:Person_Name")

is equivalent to:


SCORE-LOGIC=SSA,
				System(default),
				Population(test),
				Controls("PURPOSE=Person_Name MATCH_LEVEL=Loose"),
				Matching-Fields("Name:Person_Name,"
				"Name_2:Person_Name,"
				"Name_3:Person_Name")

Decision Processing

The Population module returns a Score and a Decision. The Score is a number between 0 and 100, with 100 representing a perfect match. The score is used to sort records prior to returning them to the user. The Decision specifies whether the match was:

good (Accepted), or

bad (Rejected), or

somewhere in between (Undecided).

It is set by the Population DLL depending on the

MATCH_LEVEL

requested in the Controls (or specified as an override in the Search API).

The Search Server will return both Accepted and Undecided records in response to a search request.

SSA-NAME3 v1

Parameters supporting SSA-NAME3 v1 are no longer documented in this guide, as SSA-NAME3 v2 (or later) is the recommended version to use with IIR. Please refer to a previous version of this guide if you require information on deprecated parameters.