What is this series of articles about?

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

Some more constraints on booking flights

There are further constraints on what can actually be booked in a flight booking confirmation, in addition to those we've already looked at:

These rules have somewhat different motivations.  RS75 is concerned with safety.  Infant passengers do not get booked in seats of their own but travel in the arms of an adult passenger (or, on a long-haul flight, may travel in a cradle in the bulkhead in front of the adult passenger's seat).  While it is considered safe for an adult passenger to hold one infant in his or her arms, it is not considered safe for an adult to hold more than one infant.

RS76 and RS77 arise from the fact that the flight booking confirmation is a subsequent stage in a multi-stage automated process.  Of course, you may change your mind, but, if you do, you must go back to the original flight booking request.  This is equally true of a booking made over the counter, over the phone, or online.  Of course, the online form used by a airline typically prevents you from specifying different cities at the confirmation stage.

RS78 and RS79 arise from the definition of a return journey.  In fact you can arrange to return from a different city than the one you are flying to (e.g., you can book to fly from Chicago to Seattle and return from Portland) but such a journey is defined as an open jaw journey rather than a return journey.  Such a journey is provided by some airlines in the form of a multi-stop journey, which allows for two or more flights that do not necessarily "join up":  in other words, you may travel by some other means between the destination of one flight and the origin of the next, and may end up in a different city from where you originally departed.  However, if you have selected a return journey as your journey type, rather than an open jaw or multi-stop journey, the online form will prevent you from specifying anything other than a return flight from the destination of the outgoing flight.  This is because of the definition of the term return journey.

RS80 arises from a requirement of international flight reservation systems.  Again the online form will prevent you from specifying different passengers on the outgoing and return flights.

Later in this article I shall look briefly at rules automatically enforced by online forms.  Meanwhile I should like to concentrate on the matter of constraints implied by the definitions of concepts.

Definitions and definitional rules

We've already encountered the following:

1. A return journey is a journey that consists of two flights in which:
   1. the origin city of the return flight must be the same as the destination city of the outgoing flight;
   2. the destination city of the return flight must be the same as origin city of the outgoing flight.
      
      
2. A flight booking must cover the same set of passengers for each flight covered by the booking.

Two more definitions we need to tie down are those for the terms we introduced in RS75:  infant passenger and adult passenger:

3. An infant passenger is a passenger who is less than 2 years of age at the time of travel.
   
   
4. An adult passenger is a passenger who is at least 12 years of age at the time of travel.

Notice that the wording of all of these definitions except that of flight booking takes the form a <term> <qualifying clause>.  Such a definition, which imposes one or more delimiting characteristics (e.g., "who is less than 2 years of age at the time of travel") on a superordinate (i.e., more general) concept (e.g., "passenger"), is referred to as an intensional definition.  An extensional definition, by contrast, lists two or more subordinate (i.e., more specific) concepts which together span the set being defined, e.g., "Journey:  a one-way journey, a return journey, or a multi-stop journey."  The form of an extensional definition is thus <or-list>.

One approach to developing a rulebook that relies on such definitions is to include each of the defined terms and its definition in the vocabulary.  The SBVR offers an alternative approach, in the form of definitional rules.  These are also known as structural rules, although there is a case for restricting the term structural rule to definitions such as 1 and 2 above, since there is nothing "structural" about definitions 3 and 4.  Non-definitional rules of the type that we have been looking at so far in this series of articles are referred to as operative rules.

If you need definitional rules rather than definitions for particular concepts, the most appropriate wording, I have found, is as in RS81 and RS82:

These and other definitional rules can be generated from template RT25:

While the useability of RS75 at the start of this article depends on the terms infant passenger and adult passenger being defined, those definitions (or the structural rule statements supplying those definitions) do not replace the rule expressed by RS75.

Again, RS78 – RS80 at the start of this article result from the definitions of return journey and flight booking, but the definitional rules one might construct to help define those terms (e.g., RS83 – RS85) do not replace the operative rules.  This is because it is possible to make a statement asserting a situation that falls outside the definitions of the terms used, e.g., to state that the set of passengers travelling on the return flight will be a different from the set of passengers travelling on the outgoing flight of the same journey.  RS85 only governs actual flight bookings, not statements about intended flight bookings, so an operative rule (RS80) is needed to respond to such statements.  Similarly RS78 and RS79 are required as well as RS83 and RS84.

RS83 and RS84 can be generated from template RT26, which is derived from template RT21:

RS85 has as its subject a set so we need an alternative template; this is discussed in the next section.

More set rules

While RS76 – RS79 at the start of this article are simple match rules (see sidebar), RS75, RS80, and RS85 all involve sets but in different ways.

RS75 has a set function as its subject, like RS25, RS73, and RS74, but (unlike those rule statements) also has a set function as its predicate.  The same template (RT24) could be used but we need to update the sub-templates for those types of predicate with which a set function can be compared.  In fact, only non-time range predicates and equality predicates can meaningfully be compared with set functions, so all we require are ST45 and ST46, replacing ST18 and ST9 respectively.  RT27 is an update to RT24 which allows only those types of predicate.

In RS80 both the subject and the predicate are sets, rather than set functions, so that rule statement requires a new template in the form of RT28.

RS85 also has a set rather than a set function as both the subject and the predicate, but is structural rather than operative, so also requires a new template in the form of RT29.

Note the difference between:

• a set, which consists of any number of items of the same type e.g., infant passengers, and
  
  
• a combination, which consists of explicitly listed items of different types, e.g., placename and postal code.

Rules automatically enforced by an online form

Most, if not all, online forms used for flight bookings automatically enforce rules RS76 – RS80 at the start of this article, along with many of the others we've encountered in this series.  Whereas some rules are enforced through drop-down lists, checkboxes, radio buttons, calendar widgets etc., others (including RS76 – RS80) are enforced by the structure of the form, which does not include any means of specifying alternative cities or alternative sets of passengers.  This, I have found, leads some to believe that such rules do not need to be stated, but this is a false belief.  Rules exist irrespective of the means of enforcing them, which may change over time; rule governance requires that all rules must be stated in a common format and single location.

To be continued...
In subsequent articles we will examine temporal rules, rule statement quality assessment, including identification of redundant and conflicting rule statements, and rules governing processes and roles rather than data.

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.  

# # #