Querylet References

In some query situations, it might be necessary to repeat the same querylet multiple times. This most often comes up in record matching situations where multiple cases are available that indicates that a record matches. See the examples of this in the Match Case Score Combiner section. Because it can be time consuming to evaluate a querylet, unnecessary evaluations should be avoided. Referencing querylets provides a means of doing this when there are repeated querylets.

Points to note about querylet references:

•

References are by name. To create a reference to a querylet the querylet that will be referenced must have a name.

•

The referenced querylet must exist in the query tree. The reference is essentially a pointer to another querylet on the tree. If the referenced querylet is not on the query tree, the ibi Patterns - Search server returns an error.

•

Any type of querylet can be referenced, except for other querylet references. References can be to entire sub-trees within the query tree, not just to the score generators.

•

Circular references are not allowed. The query will be rejected by the ibi Patterns - Search server if it contains a querylet reference that references one of its ancestors.

•

There are no order dependencies. A reference can be to another querylet anywhere on the query tree as long as it does not create a circular reference.

The following is the example from the Match Case Score Combiner example but modified to use querylet references:

// Querylets for each category (implementation not shown.)
NetricsQuery name_cat;        // Name category querylet.
NetricsQuery street_cat;       // Street category querylet.
NetircsQuery location_cat;     // Location category querylet.
NetricsQuery phone_cat;        // Phone category querylet.
NetricsQuery dob_cat;          // Date of Birth category querylet.
// We create references on the category querylets.  To do that
// they must be named.
name_cat.setName(“NameCategory”);
street_cat.setName(“StreetCategory”);
location_cat.setName(“LocationCategory”);
phone_cat.setName(“PhoneCategory”);
dob_cat.setName(“DateOfBirthCategory”);
NetricsQuery []cat_qlets = new NetricsQuery[] {
        name_cat, street_cat, location_cat, phone_cat, dob_cat
};
// Now create a category array using references.
NetricsQuery []cat_ref_qlets = new NetricsQuery[] {
        name_cat.getReference(),
        street_cat.getReference(),
        location_cat.getReference(),
        phone_cat.getReference(),
        dob_cat.getReference()
};
// Match Case querylet for rule 1.
NetricsQuery rule_1 = new NetricsQuery.MatchCase(
        cat_qlets,   // One of these must have the original
                     // querylets so they can be referenced.
        0.8,         // This is the match strength,
                     // this is a moderately strong match case.
        // This defines the thresholds for both core categories and
        // supporting categories.  A negative value indicates it is
        // a core category.  The threshold is the absolute value.
        new double [] { -0.70, -0.80, -0.75, 0.85, 0.60 },
        // This serves double duty, for the core categories it is a
        // weighting factor, similar to the weight on an AND combiner.
        // for a supporting category it is the supporting strength.
        // Phone number is a weak supporter, DOB is a very strong supporter.
        new double [] {  1.0,   0.80,  0.80, 0.15, 0.40 },
        // This is the refuting strength for a supporting category,
        // entries for core categories are ignored.
        // phone number is a very weak refuter, DOB is a very strong refuter.
        new double [] {  0.0,   0.0,   0.0,  0.05, 0.50 }
        );
// Match Case querylet for rule 2.
NetricsQuery rule_2 = new NetricsQuery.MatchCase(
cat_ref_qlets,// All following rules should use the references.
        0.85,        // This is the match strength,
                     // this is a slightly stronger match case.
        // Notice we set the threshold for categories slightly lower when
        // using them as a core categories.  Remember it can still be
        // rejected if the combination of scores is below our overall
        // cut off score.  So a little leeway helps pick up cases that
        // will be strengthened by strong matches in other categories. 
        new double [] { -0.70, 0.85, 0.80, -0.80, -0.50 },
        // street and location are fairly strong supporters.
        new double [] {  1.0,  0.35, 0.35,  0.60,  0.90 },
        // but street and location are very weak refuters.
        new double [] {  0.0,  0.10, 0.10,  0.0    0.0 }
        );
// The full query
NetricsQuery full_query =
    NetricsQuery.Or(null, new NetricsQuery[] { rule_1, rule_2 }) ;

In this example, there are only two rules. When more than two match rules using the same set of querylets, it is a good practice to use querylet references for all but the first rule. As the original querylets are named, and names must be unique, the original querylets must be used only once.

Consider using a reference querylet whenever an identical querylet is repeated two or more times in a query tree. Querylet references have the biggest impact when:

•

The repeated querylet is a complex query with several Simple, Cognate, or Variable Attribute querylets.

•

The repeated querylet has a large query string for a Simple, Cognate, or Variable Attribute query.

•

It is a joined search using single-parent mode.

•

The return set is large, or the prefilter output is large.

Did you find this helpful?

Yes No