What is this series of articles about?

This is the seventh article in a series in which I describe a practical method of developing unambiguous natural language rule statements.  I've developed this method for a large Australian government agency that has selected the Business Rules Approach and the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR)^[1] as representative of best rules practice.

The story so far

We've been looking at some of the rules governing an online "Book Flights" facility provided by an airline.  So far we've created a set of rule statements, the fact types on which the rules are based, and some rule statement templates and sub-templates for generating rule statements.

We've also been developing a taxonomy of rules as well as a rule statement development method based on selection of the appropriate template and sub-template(s) for each type of rule.

The taxonomy, templates, and sub-templates are listed in the [sidebar] along with all valid rule statements and supporting fact types.

The font and colour conventions used in these articles reflect those in the SBVR.^[2]

Testability of rules

In the previous article I introduced a rule statement (RS57) that raises some issues, but I deferred discussion of those issues until this article.

For a start, this rule statement is implementation-specific.  Validation of placename and postal code combinations may instead be performed using a web service.  If we rephrase this rule as in RS58, it is no longer specific as to the validation mechanism:

However, we're still not out of the woods!  If postal addresses are not confined to the one country, the rule is ambiguous:  which postal authority?  The rule needs to be restated:

In this form the statement raises the issue of whether the rule can be feasibly tested.  If the airline can access postal code information from the postal authority of every country (unlikely), or:

1. there is some other rule which constrains postal addresses to be in a limited set of countries, and
2. the airline can access postal code information from the postal authority of each of those countries,

this rule can be tested, but these conditions may not apply in practice.  Of course, if the rule is restated as in rule statement RS60, the rule can be tested in all three of the following possible circumstances:

1. the postal address specifies both a country for which postal code information is accessible and a combination of placename and postal code allocated by that country's postal authority (pass);
2. the postal address specifies a country for which postal code information is accessible but a combination of placename and postal code which does not match any combination allocated by that country's postal authority (fail);
3. the postal address specifies a country for which no postal code information is accessible (pass).

One final point needs to be made about testing this rule.  If postal code information from a particular country is not up-to-date, a postal address may be specified which specifies a combination of placename and postal code which does not match any combination currently accessible.  This rule must therefore not be enforced absolutely; instead, a warning should be issued and the person entering the data given the opportunity to "proceed with caution."

Whereas rule statements RS58 and RS59 were based on the same template (RT14) and sub-templates (ST21 and ST22) as RS57 but with different second qualifying clauses, rule statement RS60 differs from RS59 through the inclusion of a conditional clause.

Conditional clauses

Let's look at a few more rule statements using conditional clauses:

The conditional clause in each of these rule statements (and in RS60) is introduced by the word if and consists of:

1. a subject:
1. the airline in RS60
2. any flight specified in that flight booking confirmation in RS61
3. that flight booking confirmation in RS62
4. every passenger specified in that flight booking confirmation in RS63
   
   
2. a condition:
   1. can access the postal code information from that postal authority in RS60
   2. is international in RS61
   3. specifies an insurance option in RS62
   4. is less than 12 years of age in RS63.

We can make the following observations about these conditional clauses:

1. The subject may be:
   1. a single noun phrase, i.e., a term preceded by the, that, any, or every, as in RS60 or RS62, or
   2. a noun phrase followed by a qualifying clause, as in RS61 or RS63.
      
      
2. The condition may be any of the following:
   1. a transitive verb phrase followed by a term (preceded by an article and optionally followed by a qualifying clause), as in RS60 or RS62,
   2. an intransitive verb phrase, as in RS61, or
   3. is followed by a predicate, as in RS63.
      
      
3. Normally the word that must appear in the subject (at the start or within the qualifying clause), immediately followed by a reference to one of the terms in the main clause of the rule statement.  Alternatively the word the may be used if followed by a term which refers to a set with only one member relevant to the rule statement (in this case airline).

In addition, we can make the following conjectures about conditional clauses:

1. The word unless could be used instead of if to introduce a conditional clause.
2. As in a qualifying clause, the term in a condition could be preceded by each or that rather than an article.
3. A conditional clause could consist of multiple subject-condition pairs separated by and or or.  However, as we saw in the fourth article^[3], the use of and and or in the same clause can be ambiguous.

This should help us to put together the sub-templates we need for conditional clauses.

Each type of rule can be conditioned, so each template needs to allow for a conditional clause.  The ideal position for a conditional clause is after the main clause, i.e., at the end of the rule statement.  However if a rule statement ends with a list, following that list with a conditional clause yields an awkward construction, difficult to understand.  A better position for the conditional clause in such a rule statement is directly after the word must, but the conditional clause then interrupts the flow of the main clause.  This is mitigated by enclosing the inserted clause (and the preceding if or unless) in parentheses.

Before we list our enhanced templates, however, we should note that RS63 is using a slightly different form of the object noun phrase to those we've seen previously.  RS61 and RS62 use the <cardinality> <term> for each <term> form we've seen previously, but RS63 uses <cardinality> <term> at the <term>.  In fact, not only can the be used instead of each, but any preposition can be used instead of for.

Rule types and templates revisited

Now that we've replaced each template with a revised version incorporating a conditional clause we'd better bring the mapping of rule types and templates up to date.

Qualifying clauses revisited

If we look at the existing sub-template for a qualifying clause (ST6) we can see that it requires a transitive verb phrase followed by a term (preceded by an article and optionally followed by a qualifying clause).

However, there is no reason why a qualifying clause cannot also (like a condition) include either of the following:

1. an intransitive verb phrase, e.g., is online, has expired, has closed
2. is followed by a predicate, e.g., is less than 12 years of age

Note that, unlike the original form of qualifying clause, neither of these two forms ends with a term.  Therefore, since a qualifying clause can only follow a term, neither of these two forms of qualifying clause can be followed directly by another qualifying clause.

Given all this, we need to enhance sub-template ST6 to accommodate these alternative forms.  While we're doing that, we should also note that, if the term qualified by the qualifying clause refers to a person or persons, it is more appropriate to start the qualifying clause with who rather than that.  Sub-template ST30 is the enhanced version of ST6 that takes all this into account.

However, when we compare sub-template ST30 with ST29, it becomes obvious that a qualifying clause is a condition preceded by that or who; ST31 reflects this.

To be continued...
In subsequent articles we will not only look at further rule types, templates and sub-templates, but explore the metarules governing the underlying fact types required for a rule statement and the clauses from which it is constructed.  We will also explore some techniques for rule statement quality assessment, including identification of redundant and conflicting rule statements.

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF  

[2]  The font and colour conventions used in this and other well-formed rule statements and fact types in these articles reflect those in the SBVR, namely underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.   Note that, for clarity, less than well-formed rule statements will not use these conventions.  

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 4)," Business Rules Journal, Vol. 10, No. 5 (May 2009), URL:  http://www.BRCommunity.com/a2009/b481.html  

# # #