A common need for combining multiple expressions is in the use of exact match "filters" to cause candidate records to be rejected early, usually based on the value of some flag.

There are nine (9) pre-defined Filters that can be used with special reserved names Filter1, Filter2,. . . Filter9. Multiple filters are provided in case the Matching need requires to filter on more than one field. The filter values are normally expected to be flags, usually single-characters; however they can be any length up to 255 characters The matching done on filters is an exact match, with no editing, which is why they are more suited to codes and flags.

There is another control that is used to return a score of 0% when one or both of the fields used for the Filter are empty or blank.

FILTER_OPTIONS=A|B|Y|E|S|F|N

A =

Search or file must be blank.

B =

Both search and file must be blank.

Y =

Same as E (Either).

E =

Search and file may be blank.

S =

Search is blank.

F =

File is blank.

N =

Both search and file must match.

I =

Turns on case insensitive match. You can use

I

with other filters or as a standalone filter.

The default is to return 100% if both fields are blank.

For example, consider a name file that includes both person and company names. This name file also includes a name type ("P" for person and "C" for company). The business needs to be able to search across both name types in the one search (to avoid missing a match if the name type is wrong), but would also benefit from a search within each name type (a "Person" search and a "Company" search).

For this example, a single unpartitioned SSA-NAME3 Key index would be built. (Partitioning by name type would make searching across name types difficult). Such an index would typically use the

Organization_Name

algorithm as it supports a mixture of personal and organization names.

To support the searching within name type, the matching can use the Filter syntax (a

Filtern

Purpose in combination with the real Match Purpose.)

In this example, to cause a Match function to accept only Typical Matches about "People", using the Purpose "same Organization", the following Controls syntax might be used:

PURPOSE=(Filter1 AND Organization(Typical))

An example of the corresponding

Search Data

would be:

*Filter1*P*Organization_Name*<search name>***

And the

File Data

would look similar:

*Filter1*<Name type flag from file>*
Organization_Name*<name from file>***

This will filter out candidates that have a name type of "C".

Of course, this only makes sense if the search application has control over injecting the correct name type into the search record.

The format of the

Filtern

in the

Search Data

and

File Data

can one of the following:

a) *Filtern*<single value>*
(b) *Filtern*<value1>*Filtern*<value2>*...
*Filtern*<valuen>*
(c) *Filtern*List(value1,value2,... valuen)*

In another example that uses a

Person_Name

index, filtering may be required on two flags, say on Name Type and on Archive Status (a flag that is set to "A" if the record has been archived).

An example of the corresponding

Search Data

would be:

*Filter1*List(P,I)*Filter2*A*Person_Name*
<search name>*Address_Part1*
<search street address>*Address_Part2*
<search locality line>***

And the

File Data

would appear as:

*Filter1*<Name type flag from file>*Filter2*
<Archive Status flag from file>*Person_Name*
<name from file>*Address_Part1*
<street address from file>*Address_Part2*
<locality line from file>***

The List and repeating field formats may be used for both Search and File Data. If this is the case, the matching done will be many-to-many (i.e. not positional).

The Filter construct is particularly useful for IIR systems and DCE projects, where the user does not have control over the

SELECT

statement in candidate selection. For simple SSA-NAME3 Applications, the programmer could achieve the same effect by hard-coding a WHERE into the

SELECT

clause. However, for cases where dynamic lists are used for filtering, it may be easier for the SSA-NAME3 programmer to string these into the

PURPOSE

Control of the

ssan3_match

call.

When running Clustering projects, remember that there is not a concept of search and file record, i.e. the clustering process is about grouping file records. Therefore, using the Filter construct in clustering is restricted to using whatever flags are in the file data. This is useful for adding some additional requirements for a record to join a cluster. For example, in the first example in this section, if the mixed person and company file were to be clustered, using filtering would make it possible to ensure only records with the same name type were grouped together.

You can use the FILTER_SEARCHVAL control to specify a fixed value for the FilterN field. When you use FILTER_SEARCHVAL=value, the value must match both the search and file records.

The following example matches as the FILTER1 values for the search and file record are the same and FILTER_SEARCHVAL is not specified:

Controls: 'PURPOSE=(FILTER1 AND PERSON_NAME)'
Search data: '*filter1*A*Person_Name*Mike Taylor***'
File data: '*filter1*A*Person_Name*Mike Taylor***'
Score: '100'                                                                               
Decision: 'A'

The following example does not match as the FILTER1 fields do not match the value specified by the FILTER_SEARCHVAL control:

Controls: 'PURPOSE=(FILTER1 AND PERSON_NAME) FILTER_SEARCHVAL=B'
Search data: '*filter1*A*Person_Name*Mike Taylor***'
File data: '*filter1*A*Person_Name*Mike Taylor***'
Score: '000'                                                                               
Decision: 'R'

The following example matches as both FILTER1 fields are the same and they match the value specified by the FILTER_SEARCHVAL control:

Controls: 'PURPOSE=(FILTER1 AND PERSON_NAME) FILTER_SEARCHVAL=B'
Search data: '*filter1*B*Person_Name*Mike Taylor***'
File data: '*filter1*B*Person_Name*Mike Taylor***'
Score: '100'                                                                               
Decision: 'A'

Another use for combining multiple expressions will be to achieve Multi-Purpose Matching.

When multiple Purposes are used, it is important to note the following:

The Multi-Purpose expression is evaluated in a strict left to right order;

Early exit from the match process is only possible after evaluation of the first Purpose;

All Purposes in the expression share the same data as passed in the Search Data and File Data fields.

If two Purposes share the same field and both Purposes need to be evaluated, that field will be evaluated twice (as it may been defined with different match options depending on which Purpose it is in).

One example of Multi-Purpose matching is to create an early exit condition that is likely to improve performance. This would be either an early "accept" where Purposes are joined by an OR, or an early "reject" in the case of an AND. Again, note that early exit from the match process is only possible after evaluation of the first Purpose.

For example, if in a typical Resident purpose it is logically possible to reject on the basis of "Address" not passing a Conservative match, the following might be used:

PURPOSE=(Address(Conservative) AND Resident(Typical))

If the Address purpose receives a "Reject" decision from the Conservative match, the Resident Purpose is not evaluated as the AND has failed. However, if the Address purpose does not result in a Reject condition and the Resident purpose is thus evaluated, note that the address data will be re-matched as part of the Resident purpose, in addition to the

Person_Name

field.

In the above example overall performance (i.e. the run-time of a batch job, or the overall performance of an online system) improves the more often early-exit occurs. Conversely, performance can decrease the more often both Purposes need to be evaluated (because the address field must be evaluated for each Purpose).

Another example of Multi-Purpose matching is to return a super-set of matches, such as:

PURPOSE=(Individual OR Resident)

This will cause matches to be accepted where either the same Individual (Name + (Date of Birth or ID Number)) OR the same Resident (Name + Address) is present. In this example, the

Match_Level

Control will be used to apply to both Purposes.

A third example is for mixing Match Levels. For example:

PURPOSE=(Contact(Typical) OR
Wide_Contact(Conservative))

This will accept matches if either

Person_Name

,

Organization_Name

and

Address

match at the

Typical

level, or

Person_Name

and

Organization_Name

match at the Conservative level.

In the above two examples, again note the performance impact of both Purposes being evaluated (i.e. based on the fact that certain fields would be evaluated twice).

When combining Purposes with

<and, or, not>

, the Purposes are evaluated in a left-to-right order. If the score/decision from the first Purpose invalidates the expression, then no further processing is done and the process returns with that Purpose’s score/decision.

If all Purposes are evaluated, the score/decisions are combined in the following manner:

<expression a> and <expression b>

If <expression a> decision =	and <expression b> decision =	Final decision / Score
Reject	N/A	Reject / <exp. a> Score
Undecided	Accept	Undecided / Score=lowest
Undecided	Undecided	Undecided / Score=lowest
Undecided	Reject	Reject / Score=lowest
Accept	Accept	Accept / Score=lowest
Accept	Undecided	Undecided / Score=lowest
Accept	Reject	Reject / Score=lowest

<expression a> or <expression b>

not <expression>