What is this series of articles about?

This is the fourteenth 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.  This month I've added a number of fact types supporting rule statements added in recent articles.

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

In the previous article^[3] we encountered some rules that govern whether a process can take place on the basis of whether a prerequisite process has taken place.  Let us call these prerequisite process rules.  One such rule I expressed in two different ways:  RS103 as an obligation, and RS104 as a restricted permission.

Note that this rule statement has been improved by moving the word only to immediately before after.  We shall also do this for RS105 to RS107 inclusive. 

Now, one of the rule quality criteria listed in the previous article is that the subject of the rule statement must be the thing that is to be tested by the rule. The rule expressed by RS103 and RS104 tests whether a passenger may board a flight, and is not (nor can it be) tested at check in.  RS104 is therefore the more appropriate formulation, and the same formulation was used for the analogous rule statements RS105 to RS107 inclusive.

These rule statements have a common formulation, but before we develop a template let us consider some possible variations on such rules:

1. The subject (passenger) may, of course, be qualified by a qualifying clause.  This is also true of the object of either the main clause (flight) or the subordinate clause (departure control, security screening, check-in).
   
   
2. There may be alternative prerequisite processes, e.g., a non-US citizen must have either obtained a visa or registered with the visa waiver program before entering the US (and hence before checking into an international flight to the United States).
   
   
3. There may be multiple prerequisite processes.  For example, before the advent of online check-in, the check-in process combined the issue of a boarding pass and the deposit of bags to be checked.  Online check-in, however, only results in the issue of a boarding pass, which is why passengers with bags to be checked must proceed to a bag drop counter even if they have checked in online.  This is because security screening should only occur after both the issue of a boarding pass and the deposit of bags to be checked.

Template RT32 and sub-templates ST52 to ST55 provide for these variations:

Note:

1. In RT32, <term 1> appears twice.  This is not a typographical error; this specifies that, in each rule statement generated from this template, the same term should replace both placeholders.
   
   
2. As with qualifying clauses and conditional clauses, the use of and and or in the same process list is avoided.

RS108 is a special case of a prerequisite process rule involving the possibility of a loop in the process flow.  I'll look at this case and a suitable template in the next article.

Another type of rule encountered in the previous article, namely RS109 to RS115 inclusive, prevents a process from taking place unless the subject party provides required documentation.  The simplest of these is RS109, although RS110 to RS115 inclusive are formed in the same way; a template suitable for RS109 will work for the others.

Note that, like RS104 to RS107 inclusive, this rule statement has also been improved by moving the word only to immediately before if.  We shall also do this for RS110 to RS115 inclusive. 

Rather than develop a specific template for just these rules, I observe that they are a particular type of process pre-condition.  Prerequisite process rules are also process pre-conditions, but I believe they are sufficiently common and numerous in business process modelling to warrant a template of their own.

Template RT33 supports process pre-conditions other than prerequisite process rules:

Process fact types

Note that the "check-in" process has been referred to in a number of different ways:

1. passenger checks in for that flight in RS104
2. online check-in for a flight in RS102
3. passenger undergoes check-in in RS107.

Of course, each of these ways of referring to the process is supported by a fact type, FT84 or FT85 introduced in the previous article, or the new fact type FT91.

FT91 is of course another way of expressing FT84, which is possible because check-in is an objectification of passenger checks in for flight.

By contrast, security screening is of passenger (which supports RS108) is merely the reversed form of passenger undergoes security screening rather than being a separate fact type.

By the way, the presence of both of the terms check-in and online check-in raises another issue:  Has a passenger who has used the online check-in facility complied with the requirement of RS107?  It is not immediately obvious that they have, unless we introduce fact type FT108, which makes clear that an online check-in is indeed a check-in:

Categories and characteristics

There is another set of fact types that deal with the same concept in different ways:  FT67, FT88, and FT96.

FT96 defines international flight as a category of flight while FT67 and FT88 each define a characteristic (Boolean attribute) of flight, namely whether or not it belongs to that category.  In fact, a flight is either domestic or international.  We have established that if a flight is international it is an international flight.  Similarly if a flight is domestic it is a domestic flight.  We had better add FT109!

Equivalent or overlapping rule statements

Two rule statements may be semantically equivalent (duplicate each other), or may overlap, in which case one implies the other.  In each case, one should be deleted since one of our quality criteria (listed in the previous article) is that no rule statement should duplicate or overlap another.

There are many potential causes of equivalent or overlapping rule statements.  The following are just a few examples:

1. We've just seen that a rule statement can refer to either an international flight or a flight that is international, with no change of meaning.  Two rule statements that are identical except for such a rephrasing are equivalent.
   
2. If a rule statement includes a conditional clause introduced by unless, it can be rephrased by changing unless to if and negating the first verb phrase in the conditional clause, e.g., unless the flight is domestic can be rephrased as if the flight is not domestic.  More insidiously, unless the flight is domestic and if the flight is international mean the same thing since is domestic and is international are complementary Boolean characteristics.  Again, two rule statements that are identical except for such a rephrasing are equivalent.
   
   
3. Some rules may be expressed as either an obligation or as a restricted permission, e.g., RS103 and RS104 in the previous article.  If the same rule has been expressed in both ways, only one rule statement should be retained; choose a preferred form for that particular type of rule, as we did in that article.
   
   
4. Two rule statements may overlap (one implies the other) if they impose the same condition on a term and the term representing its subset, e.g., the following two rule statements would overlap since an online flight booking request is a category of flight booking request:
       Each flight booking request must specify exactly one origin city.
       Each online flight booking request must specify exactly one origin city.
   
   Again, only one should be retained; here, however, since they are not equivalent, the choice of statement to be retained has semantic implications.  The first is the correct one here (the one with flight booking request) since the rule applies to all flight booking requests, whether online or not.  If, however, the rule only applied to online flight booking requests, the rule statement with flight booking request should be deleted.
   
   
5. Two rule statements overlap if they are identical except for the presence or absence of a qualifying clause, e.g.,
      Each flight booking request for a return journey must specify exactly one return date.
      Each flight booking request must specify exactly one return date.
   
   
6. Two rule statements overlap if they are identical except for the presence or absence of a conditional clause, e.g.,
      Each flight booking confirmation must specify exactly one date of birth for each passenger if that flight booking confirmation specifies an insurance option.
      Each flight booking confirmation must specify exactly one date of birth for each passenger.

Contradictory rule statements

Another quality criterion listed in the previous article is that no rule statement should contradict another.  There are also many potential causes of contradictory rule statements.  For example:

1. Two cardinality rule statements are in conflict if they are identical except for cardinality, e.g.,
       Each flight booking request must specify exactly one departure date.
       Each flight booking request must specify at least one departure date.
   
   
2. Two data content rules of the same type are in conflict if they are identical except for predicate, e.g.,
       The travel class specified in each flight booking request must be first class, business class, premium economy class or economy class.
       The travel class specified in each flight booking request must be first class, business class or economy class.
   
   
3. Two rule statements are in conflict if they are identical except for semantically different qualifying clauses, e.g.
      Each bag that weighs more than 20kg must be labelled with a 'heavy bag' label.
      Each bag that weighs more than 30kg must be labelled with a 'heavy bag' label.
   
   
4. Two rule statements are in conflict if they are identical except for semantically different conditional clauses, e.g.,
      Each flight booking confirmation must specify exactly one set of passport details for each passenger if any flight specified in that flight booking confirmation is international.
      Each flight booking confirmation must specify exactly one set of passport details for each passenger if all flights specified in that flight booking confirmation are international.
   
   

Ambiguity

There are many potential sources of ambiguity in rule statements, some (but not all) of which can be avoided through careful use of the appropriate template:

1. In Articles 4^[4] and 8^[5] I observed that mixing and and or in a qualifying or conditional clause will create ambiguity; this may be able to be mitigated by the use of both or either.  The sub-templates for these types of clause have been designed to avoid such ambiguity.  For a similar reason (the absence of "operator precedence" in natural language), mixing not or that with and or or can create ambiguity.  For example, in "a visa that specifies a passport that specifies the name of the same passenger and has expired" it is not clear whether it is the visa or the passport that has expired.
   
   
2. In Article 3^[6] I discussed the ambiguity that can arise from inappropriate use of the definite article the.
   
   
3. In Article 11^[7] I discussed the ambiguity that can arise from the use of the same term more than once in a rule statement to refer to different instances of the same concept (e.g., if flight is used twice in the one rule statement to refer to two different flights, how do we distinguish the flights?).
   
   
4. If a personal pronoun (e.g., it, her) were to be used in a rule statement after more than one noun phrase, it might not be clear which noun phrase the pronoun refers to, e.g., in "A passenger may pass through security screening only if that passenger presents a boarding pass and a passport and it specifies the name of that passenger" it is not clear whether "it" refers to "boarding pass" or "passport".  No template provides for inclusion of such a pronoun; instead repetition of the term (e.g., "that passenger") is required.
   
   
5. In Article 5^[8] I observed that mixing at least and less than in a range predicate can produce an ambiguity.

To be continued...
In subsequent articles we will look at some more process rules, as well as rules governing the parties or roles that are allowed to perform a process or use information, and rules governing the way data is represented.  We shall also look various other topics, such as the time dimension and the choice of appropriate terms.

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 13)," Business Rules Journal, Vol. 11, No. 2 (Feb. 2010), URL:  http://www.BRCommunity.com/a2010/b522.html  

[4]  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  

[5]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 8)," Business Rules Journal, Vol. 11, No. 9 (Sep. 2009), URL: http://www.BRCommunity.com/a2010/b501.html  

[6]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 3)," Business Rules Journal, Vol. 10, No. 4 (Apr. 2009), URL: http://www.brcommunity.com/a2010/b473.html  

[7]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 11)," Business Rules Journal, Vol. 10, No. 12 (Dec. 2009), URL: http://www.brcommunity.com/a2010/b514.html  

[8]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 5)," Business Rules Journal, Vol. 10, No. 6 (Jun. 2009), URL: http://www.brcommunity.com/a2009/b485.html  

# # #