What is this series of articles about?

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

Rules in conflict

One of my readers is Manuel Lamotte-Schubert, of the Max Planck Institute for Informatics in Saarbrücken, Germany, working in collaboration with Peter Baumgartner, of NICTA (National ICT Australia) in Canberra, Australia.  Manuel has noticed that rule statements RS64 and RS66 (reproduced below) appear to be in conflict.  This is quite true.  If the airline offers the four travel classes listed in RS66, these two rule statements are duplicates and only one is needed.  If, in fact, the airline offers a different set of travel classes (for example, not every airline offers premium economy class, and budget airlines typically offer only economy class), RS66 is incorrect.

In Article 8,^[3] in which both these rule statements were introduced, RS66 was introduced as an alternative to RS64, which can be employed if the set of valid options has only a few members, is non-volatile (never changes, or changes only slowly over time), and is the same whenever the rule statement is tested.  By contrast, if the set of valid options has more than a few members (such as the set of cities served by the airline), any rule statement that limits a data item to a value from that set should not list the members of the set (as in RS66) but should describe the set (as in RS64).  Have a look at RS21 and RS22 in the sidebar for rule statements referring to the set of cities served by the airline.  Another situation in which the members of the set should not be listed is where the set varies depending on circumstances, such as the fare classes (as distinct from travel classes) available once a flight is selected:  these may vary depending on the selected flight, and may vary during the day as more bookings are taken for each flight.

Before we leave these rule statements, I should point out one aspect of RS64 and RS66 that escaped proof-reading.  Some flight booking forms allow you to select a travel class when making the initial flight booking request, while others don't; you select a fare class (and hence a travel class) when you have seen what classes are available on what flights.  If that is the case, neither RS64 nor RS66 is valid, since a flight booking request cannot specify a travel class.  If, however, you can select a travel class in your initial flight booking request, there are two possible scenarios:

1. You can only select a single travel class for the entire journey, in which case whichever rule statement you select (RS64 or RS66) it should start with The rather than Each.
   
   
2. You can select different travel classes for the outgoing and return flights, in which case whichever rule statement you select it should start with Each rather than The.

This is because Each should be used when there can be more than one occurrence of the data item in the form being tested, whereas The should be used when there can be only one occurrence of the data item.

Improving a template

This brings us to another issue raised by Manuel, who understandably found it difficult to generate rule statements from template RT15.

I share his concern because RT15 is designed to support a wide range of mandatory data item rules covering all the possible complexities that might arise in a paper or online form.  In this article, therefore, I shall be replacing RT15 by two templates, one covering the simpler, more common situations and one covering the rarer, more complex situations.

These complexities may arise in any of the following situations:

1. Multiple instances of a real-world object, each defined by a similar set of data items, may be able to be recorded on the one form.  For example, a flight booking confirmation may specify:

• multiple flights, for each of which it is necessary to specify a travel class and a fare class;
  
  
• multiple passengers, for each of which it may be necessary to specify a passenger name, a set of passport details, and/or a date of birth.

2. A data item may be complex, in that it is made up of other data items.  For example, a postal address is made up of address lines, a placename, a postal code, and a country name, and each passenger name must include a family name and a given name.  This situation requires more complex rule statements.  As an aside, there are two problems I frequently encounter with the way organisations handle person names:

• Many organisations define the components of a person name as first name and last name, even though they need to know the person's family name for indexing, sorting, addressing, etc.  However, whether a passenger's family name is their first or last name depends on their ethnicity, the country in which they live, and whether they have adopted the customs of that country.
  
  
• Some ethnicities may not necessarily use family names.

3. There may be a data item that is optional as a whole, but which is made up of data items that are mandatory if the set is included.  For example, the postal address is optional in a flight booking confirmation if some other means of communication (such as e-mail or telephone) is used, but if the postal address is specified, there must be at least one address line, exactly one placename, exactly one postal code, and exactly one country name.  This situation also requires more complex rule statements.
   
   
4. Data items that are parts of different complex data items may be given the same name — e.g., if a form includes both a delivery address and a billing address, each address will have address line, place name, and postal code data items.    This situation also requires more complex rule statements.

Shortly I'm going to look at a template for the more complex rule statements discussed above.  However, the majority of mandatory data item rules govern data items that are not part of a complex data item and so have a unique name within the form or message.  Rule statements for these rules, such as RS8 (reproduced below), can be generated using template RT38, which is a simpler form of RT15:

This template can also be used to generate mandatory data item rule statements for data items defining multiple instances of a real-world object recorded on the one form, as in RS53 (reproduced below):

Note that RS53 uses the {<preposition> {each|the} <term 3>|} clause in RT38, whereas RS8 does not.

Mandatory data item rule statements for data items that are part of complex data items can be generated from template RT39:

Existing mandatory data item rule statements that must now be generated from template RT39 rather than RT38 are RS40 to RS45 inclusive, including the two reproduced below.  All other mandatory data item rule statements must now be generated from RT38.

Note that I've included {that is|} in RS43 and RS44 as a reminder that that is may be omitted from a rule statement after it is generated.

Non-party-specific process rules

Yet another issue raised by Manuel is the need to express a wider range of process rules than so far discussed — in particular, rules that express dependencies between processes that may be performed by different persons (or roles), or persons or roles unknown.  This is a fair point given that each prerequisite process rule statement we've looked at so far (RS104 – RS107) has as its subject 'A passenger'.  Indeed, with only two exceptions all process rule statements so far (RS96 – RS115 inclusive) have as their subject 'Each passenger' or 'A passenger'.

Let us revisit the template for a prerequisite process rule statement:

Three things should be noted:

1. <verb phrase> may be passive rather than active, in which case <term 1> refers to the target of the process rather than the agent (who performs the process).
   
   
2. If <verb phrase> is active, <term 1> will most often refer to a party (a person or organisation) or a system, i.e., something capable of independent action, whereas if <verb phrase> is passive, <term 1> will most often refer to an inanimate object incapable of independent action, as in rule statements RS147 and RS148.
   
   
3. If <verb phrase> is passive, the agent performing the process may be identified — e.g., A bag may be carried by a passenger — but does not have to be; neither RS147 nor RS148 states who carries the bag or performs security screening of the computer.

The subject of each rule statement must be that which is to be tested

Consider rule statement RS104 (reproduced below):

RS149 may seem like a perfectly good alternative, and indeed many rules of this kind are expressed in this way in public-facing documentation.

The only problem is that this is not a test of the validity of a passenger's check-in but of whether it is valid for that passenger to board a flight.  As we have seen previously, the subject of each rule statement must be that which is to be tested, i.e., that which may or may not be valid.

Consider rule statement RS25 (reproduced below):

Before we consider an (invalid) alternative way of writing this rule, note that “number of” is styled differently in each occurrence within this rule statement.  This is not a typo; in the first occurrence (number of passenger names), number of is a set function applied to a repeating data item, whereas the second occurrence (number of passengers) is a simple data item.

You might be tempted to write this rule using rule statement RS150, but RS150 is invalid as it tests a data item (number of passengers) against a property of some other data that only occurs in a later stage of the end-to-end transaction.

However, it is not simply a matter of testing the later process or data against the earlier process or data.  Consider rule statement RS101 (reproduced below):

You might be tempted to write this rule using rule statement RS151, but RS151 is invalid.  We need a rule to test whether online check-in for a flight is valid, not whether the departure time of that flight is valid.

To be continued...
In subsequent articles we will look at rules governing the parties or roles that are allowed to perform a process or to 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 8)," Business Rules Journal, Vol. 10, No. 9 (Sep. 2010), URL:  http://www.BRCommunity.com/a2009/b501.html  

# # #