What is this series of articles about?

This is the fourth 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.  [See sidebar for the details of these elements.]

We also made a start on a taxonomy of rules (see [2] for definitions) as well as a rule statement development method based on selection of the appropriate template and sub-template(s) for each type of rule.

Cardinality rules covering selection of options

The cardinality rules that we've looked at so far are all concerned with one or more of the following types of constraint on the data in a transaction of a given type:

1. the requirement for a particular named data item to be present (or absent);
2. requirements for (or restrictions on) the number of instances of a particular named data item.

Another type of cardinality rule is concerned with the requirement that one of a set of pre-defined options is chosen.  In an application screen or online form, such a set of options may be managed by a drop-down list ("combo box"), a check-box (either checked or not), or a set of "radio buttons" (only one of which can be selected).

A drop-down list can be treated like any other data item since there is usually a label for the field in which the selected item from the list will appear, and this label can be used as the term in any rule statement about that list.  For example, a flight booking confirmation requires that each passenger's title (e.g., Mr, Mrs) be supplied; this is often supported by a drop-down list.

A check box (which can only be checked or not checked) does not require any cardinality rules, although rules about other data items may be conditioned by whether a particular check box has been checked or not.

A set of radio buttons can present a challenge, however, as these are often accompanied by fairly verbose legends that may be difficult to incorporate as such in a rule statement.  Let's look at some examples from the online "Book Flights" facility provided by an actual airline:

1. The flight booking request form has sets of radio buttons with which to specify:
   
   
1. whether the journey is a return, one way, or multi-stop journey;
   
   
2. whether the passengers must travel on the specified dates or are flexible with dates.
   
   
2. The flight booking confirmation form has sets of radio buttons with which to specify:
   
   
1. which of four travel insurance options are required (including none);
   
   
2. whether the paying party wishes to include a CO2 offset payment or not;
   
   
3. the payment method (credit card or electronic transfer);
   
   
4. (if credit card is selected as the payment method) the type of card (Visa™, Mastercard™, American Express™, Diners' Club™, etc.).

Note that some of these sets of options are easy to express in terms of a single noun phrase, for example:

• journey type can be used to label the set of options in 1.a.
  
  
• insurance option can be used for 2.a.
  
  
• payment method can be used for 2.c.
  
  
• credit card type can be used for 2.d.

Template RT1 can be used for each of these, but we will need a new template for the others.  Let's first look at how we might word the rule statements we need.

RS26.	Each flight booking request must specify whether or not the passengers must travel on the specified dates.
RS27.	Each flight booking confirmation must specify whether or not the paying party wishes to include a CO2 offset payment.

Before we look at the underlying template we need to discuss the style conventions (font and colour) used in these rule statements.^[3]  I've used the verb phrase style for the entire phrase must travel on the specified dates and for the entire phrase wishes to include a CO2 offset payment, since there are unlikely to be terms or fact types expressing the underlying relationships adequately.  For example, "specified date" is unlikely to be a term, and, while "CO₂ offset payment" may be a term, and "paying party includes CO₂ offset payment" may even be a fact type, these rules are not about actual travel or actual payment but about wishes, intentions, or requirements, in other words the verbs involved are modal.  The most elegant way I've found of including this type of information in the fact model is to do so by way of unary fact types:

FT16.	passenger must travel on the specified dates
FT17.	paying party wishes to include a CO2 offset payment

If your fact modelling technique allows for objectification (assignment of a noun phrase to an fact type) of unary fact types as well as binary named associations, you can create additional fact types of the form "flight booking request specifies <noun phrase assigned to unary fact type>" in which case "specify" in rule statements RS26 and RS27 should definitely use the verb phrase style.  If not, you may consider using the keyword style for "specify" in this type of rule statement.

Rule statements RS26 and RS27 each deal with a situation which provides for only "Yes" and "No" options.  However, the other sets of options in the forms we've been looking at include some that provide for more than two options and some where there are two options that cannot be simply treated as "Yes" or "No".  If we want to state the rules about these sets of options in a similar manner to rule statements RS26 and RS27, we would end up with:

RS28.	Each flight booking request must specify whether it is for a return journey, a one-way journey or a multi-stop journey.
RS29.	Each flight booking confirmation must specify whether the payment is a credit card payment or an electronic transfer payment.

To cover all of these situations our new template needs to look like this:

RT5.	Each <term> {<qualifying clause>|} must specify whether {{or not|}{it|the <term>} <verb phrase> {<article> <term>|}|     {it|the <term>} <verb phrase> <or-list>}.

The or-list syntax allows for two or more options.  The first alternative form within sub-template ST10 is <article> <term> or <article> <term>; the second alternative form generates <article> <term>, <article> <term> or <article> <term> at its simplest but can precede this by as many additional instances of <article> <term>, as are required:

ST10.

<or-list> ::=     {<article> <term> or <article> <term>|         <article> <term>, <or-list>}

Note that the or-list syntax is appropriate for UK or Australian punctuation conventions but not for US punctuation conventions, in which there should be a comma before "or" when there are more than two items in the list.  As an exercise you may wish to rewrite ST10 to support US punctuation conventions.

Of course, we also need a sub-template for article:

ST11.

<article> ::= {a|an|the}

Cardinality rules covering groups of data items

Sometimes there is a requirement for at least one of a group of data items to be present, even though none of the data items in the group is itself mandatory.  A good example is where some means of electronic contact is required for the transmission of a confirmation message but this may be a mobile (cell) phone number or an e-mail address.  This could be expressed as:

RS30.

Each flight booking confirmation must specify a mobile phone number, an e-mail address or both.

However it may be that the airline requires only one data item from a group, for example:

RS31.

Each flight booking confirmation must specify a credit card or an electronic transfer payment receipt but not both.

These rule statements each cater for only two data items.  If there are more than two data items, an alternative formulation is required.  For example, if the airline needs to send the finalised itinerary to the travel arranger, there are three possibilities: postal address, e-mail address, or fax number.  This could be expressed as:

RS32.

Each flight booking confirmation must specify exactly one of the following: a postal address, an e-mail address or a fax number.

Each of these rule statements requires a different template:

RT6.	Each <term 1> {<qualifying clause>|} must <verb phrase> {a|an} <term 2>, {a|an} <term 3> or both.
RT7.	Each <term 1> {<qualifying clause>|} must <verb phrase> {a|an} <term 2> or {a|an} <term 3> but not both.
RT8.	Each <term 1> {<qualifying clause>|} must <verb phrase> <cardinality> of the following: <or-list>.

We've looked at rules covering requirements for electronic message contact and itinerary transmission but the airline also needs to make voice contact.  This is a bit more complicated.  If a mobile (cell) phone number is specified, this can be used for all voice contact, but if the travel arranger or main contact among the passengers does not provide a mobile phone number, he or she must provide daytime and evening landline numbers in the origin city.  It is tempting to state this rule along the following lines:

RS33.

Each flight booking confirmation must specify a mobile phone number or an origin city daytime phone number and an origin city evening phone number.

However the use of and and or in the same clause can be ambiguous: it is not clear from this rule statement whether the requirement is:

1. either a mobile phone number or the other two numbers (i.e., the real requirement), or
   
   
2. an origin city evening phone number, plus either a mobile phone number or an origin city daytime phone number.

If the second of these alternatives were in fact the requirement, this could be achieved by separating it into its constituent rules (it is non-atomic as it stands) for which rule statements can be generated using templates RT1 (for origin city evening phone number) and RT7 (for mobile phone number and origin city daytime phone number).  To unambiguously specify the real requirement (the first alternative above) we need to be able to include combinations of terms in an or-list as in rule statement RS34:

RS34.

Each flight booking confirmation must specify exactly one of the following: • a mobile phone number; or • an origin city daytime phone number and    an origin city evening phone number.

This does not require a new template; RT8 fills the bill provided we extend the syntax of or-list:

ST12.	<simple or-list> ::=
		{<article> <term 1> or <article> <term 2>|     <article> <term 3>, <simple or-list>}
ST13.	<simple and-list> ::=
		{<article> <term 1> and <article> <term 2>|     <article> <term 3>, <simple and-list>}
ST14.	<complex or-list> ::=
		• <article> <term 1>|<simple and-list>}; or     {• <article> <term 1>|<simple and-list>}|<complex or-list>}
ST15.	<or-list> ::= {<simple or-list>|<complex or-list>}

Things get more complicated in the case of a return journey.  In this situation, if the travel arranger or main contact among the passengers does not provide a mobile phone number, he or she must also provide daytime and evening landline numbers in the destination city.  However the same template (RT8) and sub-templates (ST12 to ST15) support rule statement RS35 just as easily.

RS35.

Each flight booking confirmation must specify exactly one of the following: • a mobile phone number; or • an origin city daytime phone number and    an origin city evening phone number and    a destination city daytime phone number and    a destination city evening phone number.

To be continued...
In subsequent articles we will look at further rule types, templates, and sub-templates, including those for conditional clauses.  We will also explore some more sources of ambiguity, as well as alternative wordings and some techniques for rule statement quality assessment.

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.  

# # #