What is this series of articles about?

This is the third 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 the rule statements are based on, and some rule statement templates and sub-templates for generating rule statements.  [See sidebar for the details of these elements.]

We also made a start on a rule taxonomy (see [2] for definitions) as well as a rule statement development method:

1. Cardinality rules:
   1. Mandatory data rules
   2. Prohibited data rules
   3. Singular data rules
2. Data content rules:
   1. Value set rules
   2. Match rules
   3. Range rules

Using the right term or verb phrase form

We've also seen that, after must, the infinitive form of a verb phrase is required, e.g., specify rather than specifies, whereas in most other cases the third person singular present indicative ("3PSPI") form is required (the form used in the relevant fact type).^[3]

In fact, terms also have alternative forms:  after one of the in sub-template ST3, the plural form of a term is required, e.g., cities rather than city, whereas in most other cases the singular form is required, e.g., city.  The form required after <cardinality> in template RT1 or RT2 depends on whether <positive integer> is one (in which case the singular form is required) or some value greater than one (in which case the plural form is required).

The use of the definite article

A common error in formulating rule statements (and, indeed, definitions of terms) is to use the definite article (the) inappropriately.  Given that a term represents a concept, which can be thought of as a set of real-world instances, we can use a term in a rule statement (or term definition) in any of the following ways:

1. a <term> (singular form) or one of the <term> (plural form) to refer to any member of that set
   
   
2. the <term> (plural form) or, better, all <term> (plural form) to refer to all the members of that set
   
   
3. each <term> (singular form) to make a statement that applies to all the members of that set individually
   
   
4. <name> (singular form) to refer to the sole member of a set having only one member, e.g., the United Kingdom
   
   
5. the <term> (singular form) to refer to a specific member of a set having more than one member, but only in one of the following situations:
   
   
1. only one member of the set is relevant to the context (and it is clear what member that is) , e.g., the airline
   
   
2. the <term> is followed by a clause establishing which member we are referring to, e.g.,
         The departure date (that is) specified by each flight booking request
   at the start of rule statement RS19 is valid since there is only one departure date in a flight booking request.

It is wrong to use the and the singular form of a term when there is more than one instance of that term and we cannot infer which one is being referred to, e.g., if rule statement RS20 were to read
      "The return date (if any) specified by each flight booking request must be no earlier than the departure date."
it would be ambiguous, since, although parties governed by the rule can probably guess which departure date is being referred to, there may be others.

The addition of the qualifying clause
      (that is) specified by that flight booking request
after the departure date in rule statement RS20 enables anyone to infer precisely which departure date is being referred to.

Qualifying clauses

One thing we haven't yet established is a sub-template for qualifying clauses.  Let's review the qualifying clauses that we've so far encountered:

1. (that is) for a return journey and (that is) for a one-way journey in rule statements RS9 and RS11 respectively
2. (that is) specified by that flight booking request in rule statements RS20 and RS23
3. (that is) served by the airline in rule statements RS21 and RS22.

We've also seen that (that is) specified by each flight booking request in rule statements RS19 to RS24 inclusive performs the function of a qualifying clause (although it's implicitly included in template RT3 in the form that <verb phrase> each <term 2> rather than explicitly as <qualifying clause>.

The common feature of all of these is the structure
            that <verb phrase> {a|each|that} <term>.

In each case 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).  Fact types FT6 and FT7 fulfil that role in rule statements RS9 and RS11 respectively, while fact type FT1 fulfils that role in rule statement RS20.

Sometimes, in order to establish precisely which instance of a concept we are dealing with, we need a longer qualifying clause.  For example:

RS25.

The number of passenger names specified by each flight booking confirmation must be equal to the number of passengers specified by the flight booking request that gives rise to that flight booking confirmation.

This is a better statement of the rule briefly considered in the previous article, for which RS18 was a less business-friendly attempt.  We'll need a new template for this rule statement, which we'll look at shortly.  Let's concentrate for the moment on the qualifying clause (specified by the flight booking request that gives rise to that flight booking confirmation).  If we add that is at the beginning, we can see that the structure
        that <verb phrase> {that|the} <term>
appears twice.  Sometimes it's even necessary to have three or more qualifications.  The sub-template for a qualifying clause is therefore:

ST6.	<qualifying clause> ::=
		that <verb phrase> {a|an|each|that|the} <term> {<qualifying clause>|}

which can generate a qualifying clause containing as many qualifications as required.

Of course RS25 needs one more fact type in addition to FT12 and FT10:

FT15.

flight booking request gives rise to flight booking confirmation

A new template

Rule statement RS25 is an example of a constraint on a set function, in this case the count (or "number") of members of a set.  Other set functions that may be constrained are:

1. the total (or sum) of a set of quantities (e.g., total weight of bags), monetary amounts (e.g., a limit on the total cost of a booking) or percentages (e.g. all percentages must sum to 100%)
   
   
2. the maximum or minimum of a set of quantities, monetary amounts or percentages
   
   
3. the average of such a set (usually only in scientific applications, in which case the terms "mean", "median", and "mode" might be required so as to be precise).

These will all be familiar to users of SQL.

The template that we can use to generate rule statement RS25 is:

RT4.	The <set function> of {the|} <term 1> that <verb phrase> each <term 2> must be <predicate>.

The associated sub-template for <set function> is:

ST7.	<set function> ::=
		{number|total|maximum|minimum|average|mean|median|mode}

We also need to broaden the sub-template for <predicate> to include equality predicates:

ST8.	<predicate> ::=
		{<value set predicate>|<match predicate>|<range predicate>| <equality predicate>}

We also need a sub-template for <equality predicate>:

ST9.	<equality predicate> ::=
		{not|} equal to {<literal>|the <term> {<qualifying clause>|}}

Alternative wordings

Your business people might prefer alternative wordings to those I've used in these rule statements.  For example, they might prefer specified in to specified by.  This is up to the business; all you have to do is record that the passive form of specifies is be specified in or is specified in rather than (or as well as) be specified by or is specified by.  In fact they might even prefer in rather than specified in, as in
        The number of passengers in each flight booking request must be no less than one.

Perhaps you would rather see must not be earlier than today instead of must be no earlier than today, and must not be less than one instead of must be no less than one.  This requires a modification to template RT3, namely the inclusion of {not|} between must and be.  This makes template RT3 richer, in that data items can be constrained to not belong to a set of values (if using sub-template ST3).  However, if you wish to avoid too many alternative ways of saying the same thing (which makes comparison of rule statements for duplication, overlap or conflict more difficult) you might want to:

1. remove {|different to} from sub-template ST4;
   
   
2. remove {no|} from sub-template ST5.

What I would advise against is the formulation must be greater than or equal to one instead of must not be less than one or must be no less than one.  There are three reasons for this formulation being less appropriate:

1. It uses more words;
2. It uses language more familiar to the world of mathematics than of business;
3. It uses or — as we shall see in a subsequent article, or and and can introduce ambiguity so must be used with care, or avoided if possible.

To be continued...
In subsequent articles we will look at some more rule types and templates as well as conditional clauses and sources of ambiguity.  Each of these topics may well need an article to itself!

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

[3]  The font and colour conventions used 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.  

# # #