How Rules Affect Categorization
There are several variables that work together to determine if a resource can potentially be assigned a particular category. This section introduces the simplest cases; the complexity of any implementation may vary greatly. For a more in depth exploration of these variables, see Advanced Rule Applications. These following table outlines the variables that work together:
| Variable | Description | HOw to Modify |
| Rule Weight | You can assign more than one rule to a category. The rule weight is the relative impact of each rule on potential categorization. | Associating Rules to Categories |
| Match Strength | A numerical representation of how well the content matches the rule. A match strength is set in the rule, and then calculated for the resource when it is processed. The simplest implementation is to use the default match strength of one. | Writing XML Rules |
| Rule Score | The overall value the rule contributes towards categorization. It is calculated by multiplying the match strength and the rule weight. | Not applicable as this is calculated |
| Category Threshold | Defines the point at which a category is applied. The scores of the associated rules must greater than or equal to the threshold. Note: The threshold can only be modified through PowerShell commands. | Editing a Category |
By controlling these variables, you can define the requirements for categorization. The variables work together for a category as follows:
- The rule scores of all rules associated with a category are added up
- This sum is compared to the category threshold
- If the sum is equal to or greater than the category threshold, the category is applied
- If the sum is less than the category threshold, the category is not applied
Mutual exclusivity settings and the order of the categories also impact whether a category can be applied. For example, the rules may indicate that a category should be applied, but if there higher scoring category in a mutually exclusive branch of the taxonomy, the categorization will not occur. For more information, see How Categories Work Together: Mutual Exclusivity, Strict Ordering and Inheritance.
Rule Example using Default Values
The following figure provides an example of a category with two rules associated with it. Each rule has a possible match strength of one, and is associated with the category with a rule weight of one. Using this example, we can examine what happens as you manipulate the category threshold. The diagram indicates the settings on the various elements.
 |
The default category threshold is one. If you left this default, and assigned two rules as shown, only one rule would have to match in order for categorization to potentially occur. The following shows how a resource, would be processed that only matches the first rule:
| Resource Match Strength | Rule Weight | Rule Score (Match Strength x Rule Weight) | |
| Rule 1 | 1 | 1 | 1 |
| Rule 2 | 0 | 1 | 0 |
| Total | 1 |
To determine if categorization could occur, compare the total rule scores to the category threshold:
| Total rule scores | 1 |
| Category threshold | 1 |
Since the total rule scores are greater than or equal to the threshold, this is a potential category for the resource, as long as other category settings allow. Note that both rules matching would also result in potential categorization.
You can control categorization using these variables. For example, if the category threshold in the above example was set to 2, and nothing else was changed, categorization would not occur:
| Total rule scores | 1 (unchanged) |
| Category threshold | 2 |
Since the rule scores are not greater than or equal to the threshold, the category would be not be applied.
Rule Example Manipulating Threshold and Rule Weight
In the following example, you want to ensure that Rule 1 and at least one of the other rules matches in order for the category to be applied. The following diagram shows the settings on all of the elements:
 |
By manipulating the category threshold and the rule weights, you can meet your requirement. For example, if a resource was processed that only had matches with rules one and four:
| Resource Match Strength | Rule Weight | Rule Score (Match Strength x Rule Weight) | |
| Rule 1 | 1 | 3 | 3 |
| Rule 2 | 0 | 1 | 0 |
| Rule 3 | 1 | 1 | 1 |
| Rule 4 | 0 | 1 | 0 |
| Total | 4 |
To determine if categorization could occur, compare the total rule scores to the category threshold:
| Total rule scores | 4 |
| Category threshold | 4 |
Since the total rule scores are greater than or equal to the threshold, this is a potential category for the resource, as long as other category settings allow. Note that all rules matching would also result in potential categorization, but that categorization cannot occur without a match on the first rule.
Note that other settings on a category may affect categorization. For more information, see How Categories Work Together: Mutual Exclusivity, Strict Ordering and Inheritance.
Writing XML Rules
Contents
You can write rules using any XML editor that supports UTF-8 encoding using the format described here. Once you have written your rule, you can add it to the system and then test it. When your rule is performing as desired, you can associate it with a category. If you plan to reuse rules across more than one category, ensure you take this into account when developing the rules. You should not refine it in a way that meets the needs of one situation but not all others. In this case, make a copy of the rule and edit the new copy, and then import the new rule into the system. For more information, see Managing Rules in the Classification System. You may wish to place your rule XML under source control to ensure change is carefully managed, and that you can roll back rule changes if necessary. To update a rule, you need to edit the XML file.
A rule uses extractors to identify text of interest, and then applies logic to define all necessary criteria for a rule pass. For example, you may need to match more than one extractor, or you may need to match only one of a list of several extractors. Or you may need to find three instances of a particular text extractor match. Quest One Identity Manager includes a number of extractors, including some not referenced in the sample taxonomies. For a list of extractors available for you to use in rules, see Sample Text Extractors Details.
The following example of a rule definition illustrates how to write rule a rule using XML. In this case, the rule is designed to use extractors to find instances of “name” and “address” as well as “ssn” within a resource, with specified strength of match values. Use this example as a guide when writing your own XML rules.
This rule contains two <if> elements that are evaluated in order; if the first <if> applies, then the second is not evaluated. Each <if> has two sub-elements; the first is a condition, and the second is an action. If the condition matches, then the action is applied.The <find> element is used to invoke a text extractor. In the rule XML, the text extractor is simply referred to by its ID.The <match> action indicates that the rule is a match, and provides a strength-of-match representing the level of certainty. For information on how match strength affects categorization, see How Rules Affect Categorization.
 |
You can view more sample rules in the taxonomies included in Quest One Identity Manager Data Governance Edition. Open the Data Governance Sample Taxononmy, PCI Sample Taxonomy, or Titus Commercial Taxonomy. These are typically located in C:\Program files\Quest Software\ QCS\Templates. |