What is this series of articles about?

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

Underlying Fact Types

In the previous article^[3] we met our first rule statements with conditional clauses, of which RS60 was one:

This rule statement is supported by a number of fact types.  The main clause (everything up to the word if) consists of a subject (everything up to the word must) and a predicate (everything between must be and if).  The fact types supporting the subject are:

The fact types supporting the predicate are:

The fact type supporting the conditional clause is:

Similarly with rule statement RS61:

The fact type supporting RS61's main clause is:

The fact types supporting RS61's conditional clause are:

And with rule statement RS62:

The fact type supporting RS62's main clause is:

The fact type supporting RS62's conditional clause is:

And, finally, with rule statement RS63:

The fact type supporting RS63's main clause is:

The fact types supporting RS63's conditional clause are:

In most of these articles I've simply stated what fact types support each rule statement without any explanation.  Back in Articles 2^[4] and 3^[5], however, I made some general statements about:

1. the fact types supporting rule statements generated from templates RT1 and RT2 (now superseded by RT15 and RT20 respectively, reproduced below), and
   
   
2. the fact types supporting simple qualifying clauses.

In those articles I stated:

1. In a rule statement generated from RT15 which omits term 1, verb phrase 1, and term 4 (none of which were available in the initial RT1 version),
   <term 2> <verb phrase 2> <term 3>
   must be a fact type (possibly derived from one or more other fact types), e.g.

2. In a rule statement generated from RT20,
   <term 1> <verb phrase 1> <term 2>
   must be a (possibly derived) fact type, e.g.

3. There needs to be a fact type (using the verb phrase in the qualifying clause) to connect the term in the qualifying clause and the term being qualified (i.e., the one immediately before the qualifying clause), thus, if the qualifying clause in RT15 has the form
   that <verb phrase> {a|an|the|each|that} <term>,
   <term 2> <verb phrase> <term>
   must be a (possibly derived) fact type, e.g.

4. Similarly, if the qualifying clause in RT20 has the same form,
   <term 1> <verb phrase> <term>
   must be a possibly derived fact type, e.g., (also supporting RS11 reproduced above)

We can now also state:

1. In a rule statement generated from RT15 which includes term 1 and verb phrase 1,
   <term 1> <verb phrase 1> <term 2>
   must be a (possibly derived) fact type, e.g.

2. In a rule statement generated from RT15 which omits term 1 and verb phrase 1 but includes term 4,
   <term 2> <verb phrase 2> <term 3> <preposition> <term 4>
   must be a (possibly derived) fact type, e.g.

3. In a rule statement generated from RT15 which includes term 1, verb phrase 1, and term 4,
   <term 1> <verb phrase 1> <term 3> <preposition> <term 4>
   must be a (possibly derived) fact type (we have no examples of this situation so far).
   
   
4. There are similar metarules determining the fact types required to support rule statements generated from each of the other templates.
   
   
5. There must be a (possibly derived) fact type for each verb phrase in a qualifying clause or conditional clause, each fact type using the term immediately preceding the verb phrase and the term (if any) following the verb phrase, e.g., rule statement RS60 and fact types FT61 – FT64 above.  Note that a pair of consecutive verb phrases may be supported by a ternary verb phrase, e.g., rule statement RS60 and fact type FT65 above.
   
   
6. In most rule statements with a conditional clause, there must be a term common to both the main clause and the conditional clause, e.g., postal authority in RS60, flight booking confirmation in RS61 – RS63.

Categories and Enumerated Sets

When a person or organisation is providing information to another person, organisation or system, particular information items are often restricted to discrete sets of values.  We saw this with RS60 above and, earlier, with RS21 and RS22 reproduced below.

Each of these rule statements refers to some set to which the organisation, its employees and/or its system has access or knowledge.  We need analogous rule statements for the travel class and fare class items, hence RS64 and RS65 below.  Note that typically travel class can be nominated during the initial booking request, but the confirmation requires that the fare class (e.g. a cheaper fare subject to conditions or a more expensive unrestricted fare) be selected.  Note also that, unless one is booking sufficiently in advance (and sometimes not even then!) not all fare classes are available on the flight you want to travel on.

Let's look at the discrete sets involved in each of these rule statements.  The set of cities may have 100 or more members, may change slowly over time but, on any given day, each test of RS21 or RS22 refers to the same set.  These properties are also exhibited by the set of combinations of placename and postal code.  While the full set of fare classes has generally fewer than 10 members, and only changes slowly over time, the set of fare classes available will vary depending on the selected flight, and will vary during the day as more bookings are taken for each flight.  Large or volatile sets are best handled in rule statements by naming or describing the set rather than its members.

The set of travel classes, by contrast, has only 3 or 4 members, is likely to change even more slowly over time, and is the same whenever the rule statement is tested.  An alternative way of describing a set such as this is to enumerate its members, as in RS66.

This requires an enhancement to ST3 in the form of ST32 and ST33.

"And" or "or" in Qualifying Clauses

In the previous article I noted the similarity between conditional and qualifying clauses.  In that article, I also noted that conditional clauses may include and or or, but not both as such clauses can be ambiguous (as discussed in Article 4^[6]).

Inclusion of both and and or in a qualifying clause would be similarly ambiguous.  In fact the inclusion of either and or or in a qualifying clause that also includes that or who can lead to ambiguity.  Consider the clause "who accompanies a passenger who is less than 5 years of age or is flying first class": it's not clear whether someone who is flying first class meets the conditions of this clause or, alternatively, whether  someone who accompanies a passenger who is flying first class meets the conditions of this clause.

Inclusion of either removes the ambiguity: "who either accompanies a passenger who is less than 5 years of age or is flying first class" makes it clear that someone who is flying first class meets the conditions of the clause, whereas "who accompanies a passenger who either is less than 5 years of age or is flying first class" makes it clear that someone who accompanies a passenger who is flying first class meets the conditions of the clause.

Note:

1. both can be used with and in a similar manner, e.g., "who both accompanies a passenger who is less than 5 years of age and is flying first class".
   
   
2. This ambiguity arises only if there is at least one that or who as well as the and or or, e.g., "who accompanies a disabled passenger or is flying first class" is not ambiguous.
   
   
3. To be entirely unambiguous, either or both or but not both is needed after an either … or construction.

Clearly the sub-template for qualifying clauses needs some additional work.  We will look at this in a subsequent article.

"Not" in Qualifying and Conditional Clauses

And and or are logical binary operators operating on conditions.  A unary operator on conditions is not, which can also be useful.  However, unlike in, say, French, Arabic or the Slavic languages, negation of verb phrases in English is rather untidy, involving not as an infix, as in is specified in and is not specified in.  Worse, for verb phrases not starting with is, the verb phrase changes to the infinitive preceded by does not, as in specifies and does not specify.  For this reason, I do not explicitly include negative forms of verb phrases in templates or sub-templates (which would make them even more complex!) but allow verb phrases to be optionally negated (in the same way as they may be indicative or infinitive, and active or passive, as discussed in Article 2).

To be continued...
In subsequent articles we will look at further rule types, templates and sub-templates, in particular the enhanced sub-templates for qualifying clauses to allow for and or or.  We will also examine the difference between operational and structural rules, look at temporal rules, and 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 7)," Business Rules Journal, Vol. 10, No. 8 (Aug. 2009), URL:  http://www.BRCommunity.com/a2009/b489.html  

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

[5]  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/a2009/b473.html  

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

# # #