What is this series of articles about?

This is the seventeenth 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]

Further rule statement quality checking

In the previous article^[3] we saw how a qualifying or conditional clause can limit the scope of a rule statement to a null set, which effectively renders the rule statement irrelevant.  This is because such a clause evaluates to "false" for every instance of the qualified or conditioned term.  By contrast, it is possible to construct a qualifying or conditional clause that evaluates to "true" for every instance of the qualified or conditioned term, and hence does not limit the scope of the rule statement at all.  Such a clause is therefore redundant since the rule statement has the same effect whether the clause is retained or removed.

Redundant qualifying clauses

Consider the following examples:

1. An infant passenger who is less than 2 years of age at the time of travel ….
   
   Since the qualifying clause repeats the definition of the term infant passenger provided in RS81 (reproduced below), it is true for every infant passenger.^[4]

RS81.

An infant passenger is by definition a passenger who is less than 2 years of age at the time of travel.

2. A journey that is a one-way journey, a return journey or a multi-stop journey ….
   
   Since the qualifying clause lists all the categories of journey as defined in RS116 (reproduced below), it is true for every journey.

RS116.

A journey is by definition a one-way journey, a return journey or a multi-stop journey.

3. A flight that has an origin port ….
   
   Since the qualifying clause repeats the fact that, by definition, every flight has a single origin port, as stated in RS117 (reproduced below), it is true for every flight.

RS117.

Each flight has by definition exactly one origin port.

4. A flight booking request that does not specify a passenger name ….
   
   This qualifying clause is irrelevant because the fact type flight booking request specifies passenger name does not exist, i.e., no flight booking requests specify passenger names.
   
   
5. A flight booking request that specifies an origin city ….
   
   This qualifying clause limits the scope of its rule statement to those flight booking requests that comply with rule statement RS12 (reproduced below).  Note that, since RS12 is an operative rule statement, which can be violated (rather than a definitional rule statement, which cannot) it is possible for a flight booking request to violate RS12 by not specifying an origin city.  Note that a principle of the business rules approach is that rules are independent of each other.  Thus it is unlikely that we would want to formulate a rule that applied only to those flight booking requests that comply with some other rules.

RS12.

Each flight booking request must specify exactly one origin city.

Redundant conditional clauses

Conditional clauses which do not effectively limit the scope of their rule statements are similarly inappropriate, including the following examples:

1. that infant passenger is less than 2 years of age at the time of travel
2. that journey is a one-way journey, a return journey or a multi-stop journey
3. that flight has an origin port,
   that flight has exactly one origin port
4. that flight booking request does not specify a passenger name
5. that flight booking request specifies an origin city,
   that flight booking request specifies exactly one origin city.

Using both qualifying and conditional clauses

While it is permissible to use both a qualifying clause and a conditional clause in the same rule statement, it is possible for the conditional clause to contradict the qualifying clause, as in
    A flight booking request that specifies a return journey must … if that flight booking request does not specify a return journey. 
Such a combination of clauses limits the scope of the rule statement to the null set; one of the clauses should be removed.

Similarly it is possible for the conditional clause to repeat the qualifying clause, as in
    A flight booking request that specifies a return journey must … if that flight booking request specifies a return journey. 
Obviously the rule statement does not need both clauses; one should be removed.

Template support for data format rules

In the previous article we introduced two types of data format rule statements, including RS125 and RS126 (reproduced below) and a number of other rule statements differing from RS126 only in the subject term.  RS125 is a definitional (or structural) rule statement which provides a definition for a valid data item type, in this case a phone number.  By contrast RS126 is an operative rule statement constraining a particular data item of that type.

Data type definition rule statements

Before we establish a template for these rule statements let us look at a few other rule statements of this type.

Note that RS132 and RS134 use exactly whereas RS134 to RS136 use at least, RS133 uses up to, and RS126 and RS133 use from … to.  Note also that RS133 and RS134 each define a multi-part data item type, one part followed by the other.  Sub-template ST57 allows for all these possibilities, and RT37 therefore can be used to generate any of these structural data format rule statements.

Data item format rule statements

Again before we establish a template for these rule statements we need to look at a few other rule statements of this type (in addition to RS126 reproduced above).

Note that, in contrast to the others, RS141 to RS145 use the words represented using.  This is because dates, counts (such as numbers of passengers), flights, and ports are real-world constructs that may be represented in different ways whereas phone numbers, person names, addresses, and flight numbers are particular representations of real-world constructs (as are date representations, unsigned integers, and port codes).

These can all be generated from template RT21 (reproduced below) provided we enhance the predicate syntax provided by sub-template ST19 (also reproduced below) by including the option of a format predicate as provided for in ST57 and ST58.

The taxonomy and metarules enhanced

In this and the previous article we've added two new rule types to the taxonomy, so we should update the table of rule types and associated (sub-)templates, as follows:

To be continued...
In the next article we will look at more process rules.  In subsequent articles we will look at rules governing the parties or roles that are allowed to perform a process or use information, as well as various other topics, such as alternative rule statements, generating rule statements from a template, the role of verb phrases and prepositions in rule statements, and the role of the time dimension in rules.

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 16)," Business Rules Journal, Vol. 11, No. 8 (Aug. 2010), URL:  http://www.BRCommunity.com/a2010/b549.html  

[4]  Note that in previous versions of the sidebar "at the time of travel" in RS81 and RS82, and "at" in RS90 – RS93 inclusive, were wrongly rendered.  These have been corrected in this version of the sidebar.  

# # #