A Practical Method of Developing Natural Language Rule Statements (Part 17)

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
What is this series of articles about?

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

Further rule statement quality checking

In the previous article[3] we saw how a qualifying or conditional clause can limit the scope of a rule statement to a null set, which effectively renders the rule statement irrelevant.  This is because such a clause evaluates to "false" for every instance of the qualified or conditioned term.  By contrast, it is possible to construct a qualifying or conditional clause that evaluates to "true" for every instance of the qualified or conditioned term, and hence does not limit the scope of the rule statement at all.  Such a clause is therefore redundant since the rule statement has the same effect whether the clause is retained or removed.

Redundant qualifying clauses

Consider the following examples:

  1. An infant passenger who is less than 2 years of age at the time of travel .

    Since the qualifying clause repeats the definition of the term infant passenger provided in RS81 (reproduced below), it is true for every infant passenger.[4]
RS81. An infant passenger is by definition a passenger who is less than 2 years of age at the time of travel.
  1. A journey that is a one-way journey, a return journey or a multi-stop journey .

    Since the qualifying clause lists all the categories of journey as defined in RS116 (reproduced below), it is true for every journey.
RS116. A journey is by definition a one-way journey, a return journey or a multi-stop journey.
  1. A flight that has an origin port .

    Since the qualifying clause repeats the fact that, by definition, every flight has a single origin port, as stated in RS117 (reproduced below), it is true for every flight.
RS117. Each flight has by definition exactly one origin port.
  1. A flight booking request that does not specify a passenger name .

    This qualifying clause is irrelevant because the fact type flight booking request specifies passenger name does not exist, i.e., no flight booking requests specify passenger names.

  2. A flight booking request that specifies an origin city .

    This qualifying clause limits the scope of its rule statement to those flight booking requests that comply with rule statement RS12 (reproduced below).  Note that, since RS12 is an operative rule statement, which can be violated (rather than a definitional rule statement, which cannot) it is possible for a flight booking request to violate RS12 by not specifying an origin city.  Note that a principle of the business rules approach is that rules are independent of each other.  Thus it is unlikely that we would want to formulate a rule that applied only to those flight booking requests that comply with some other rules.
RS12. Each flight booking request must specify exactly one origin city.

Redundant conditional clauses

Conditional clauses which do not effectively limit the scope of their rule statements are similarly inappropriate, including the following examples:

  1. that infant passenger is less than 2 years of age at the time of travel
  2. that journey is a one-way journey, a return journey or a multi-stop journey
  3. that flight has an origin port,
    that flight has exactly one origin port
  4. that flight booking request does not specify a passenger name
  5. that flight booking request specifies an origin city,
    that flight booking request specifies exactly one origin city.

Using both qualifying and conditional clauses

While it is permissible to use both a qualifying clause and a conditional clause in the same rule statement, it is possible for the conditional clause to contradict the qualifying clause, as in
    A flight booking request that specifies a return journey must if that flight booking request does not specify a return journey. 
Such a combination of clauses limits the scope of the rule statement to the null set; one of the clauses should be removed.

Similarly it is possible for the conditional clause to repeat the qualifying clause, as in
    A flight booking request that specifies a return journey must if that flight booking request specifies a return journey. 
Obviously the rule statement does not need both clauses; one should be removed.

Template support for data format rules

In the previous article we introduced two types of data format rule statements, including RS125 and RS126 (reproduced below) and a number of other rule statements differing from RS126 only in the subject term.  RS125 is a definitional (or structural) rule statement which provides a definition for a valid data item type, in this case a phone number.  By contrast RS126 is an operative rule statement constraining a particular data item of that type.

RS125. A valid phone number is by definition composed of from 9 to 12 digits.
RS126. The mobile phone number (if any) specified in each flight booking confirmation must be a valid phone number.

Data type definition rule statements

Before we establish a template for these rule statements let us look at a few other rule statements of this type.

RS132. A valid port code is by definition composed of exactly 3 letters.
RS133. A valid flight number is by definition composed of from 2 to 3 letters followed by up to 4 digits.
RS134. A valid person name is by definition composed of at least 1 given name followed by exactly 1 surname.
RS135. A valid given name is by definition composed of at least 2 letters.
RS136. A valid surname is by definition composed of at least 2 letters.

Note that RS132 and RS134 use exactly whereas RS134 to RS136 use at least, RS133 uses up to, and RS126 and RS133 use from to.  Note also that RS133 and RS134 each define a multi-part data item type, one part followed by the other.  Sub-template ST57 allows for all these possibilities, and RT37 therefore can be used to generate any of these structural data format rule statements.

ST57. <format definition> ::=
  {{exactly|at least|up to} <positive integer>|
from <positive integer> to <positive integer>} <term 1>
{
followed by <format definition>|}

RT37.  A valid <term 1>
is by definition composed of <format definition>.

Data item format rule statements

Again before we establish a template for these rule statements we need to look at a few other rule statements of this type (in addition to RS126 reproduced above).

RS137. The person name specified in each flight booking confirmation must be a valid person name.
RS138. The e-mail address (if any) specified in each flight booking confirmation must be a valid e-mail address.
RS139. The postal address (if any) specified in each flight booking confirmation must be a valid postal address.
RS140. The flight number specified in each seat allocation must be a valid flight number.
RS141. The departure date specified in each flight booking request must be represented using a valid date representation.
RS142. The return date (if any) specified in each flight booking request must be represented using a valid date representation.
RS143. The number of passengers specified in each flight booking request must be represented using a valid unsigned integer.
RS144. The flight specified in each flight booking confirmation must be represented using a valid flight number.
RS145. The origin port of each flight specified in each flight booking confirmation must be represented using a valid port code.
RS146. The destination port of each flight specified in each flight booking confirmation must be represented using a valid port code.

Note that, in contrast to the others, RS141 to RS145 use the words represented using.  This is because dates, counts (such as numbers of passengers), flights, and ports are real-world constructs that may be represented in different ways whereas phone numbers, person names, addresses, and flight numbers are particular representations of real-world constructs (as are date representations, unsigned integers, and port codes).

These can all be generated from template RT21 (reproduced below) provided we enhance the predicate syntax provided by sub-template ST19 (also reproduced below) by including the option of a format predicate as provided for in ST57 and ST58.

RT21.  The<term 1> {<qualifying clause>|} {(if any)|}
     
that <verb phrase> each <term 2> {<qualifying clause>|}
must be
<predicate>
{{
if|unless} <conditional clause>|}.

ST19. <predicate> ::=
  {<value set predicate>|<match predicate>|<range predicate>|<equality predicate>|<uniqueness predicate>}
ST57. <predicate> ::=
  {<value set predicate>|<match predicate>|<range predicate>|<equality predicate>|<uniqueness predicate>|<format predicate>}
ST58. <format predicate> ::=
  {represented using|} a valid <term 1>

The taxonomy and metarules enhanced

In this and the previous article we've added two new rule types to the taxonomy, so we should update the table of rule types and associated (sub-)templates, as follows:

Rule type Template Metarules
Mandatory data item rule RT15 <cardinality> ::=
    {exactly <positive integer>|
    at least <positive integer>
    {and at most <positive integer>|}}
Mandatory option selection rule RT16  
Mandatory group rule RT17 if either or both of 2 items in the group
RT18 if only 1 of 2 items in the group
RT19 if more than 2 items in the group
Prohibited data rule RT20  
Singular data rule RT15 <cardinality> ::= {exactly|at most} one
Dependent cardinality rule RT27 <set function> ::= number
Structural cardinality rule RT36  
Value set rule RT21 <predicate> ::= <value predicate>
if only 1 data item
RT22 <combination predicate> ::=
<combination value set predicate>
if combination of data items
Match rule (operative) RT21 <predicate> ::= <match predicate>
Match rule (structural) RT26 <predicate> ::= <match predicate>
Range rule RT21 <predicate> ::= <range predicate>
Uniqueness constraint RT21 <predicate> ::=
<uniqueness predicate>
if only 1 data item
RT22

<combination predicate> ::=
<combination uniqueness predicate>
if combination of data items

Set constraint (operative) RT28  
Set constraint (structural) RT29  
Definitional rule RT25  
Inter-process interval rule RT34 if rule statement expresses obligation (must)
RT35

if rule statement expresses restricted permission (may only)

Prerequisite process rule RT32  
Other process pre-condition RT33  
Data type definition rule RT37  
Data item format rule RT21 <predicate> ::= <format predicate>

To be continued...
In the next article we will look at more process rules.  In subsequent articles we will look at rules governing the parties or roles that are allowed to perform a process or 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  return to article

[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.  return to article

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 16)," Business Rules Journal, Vol. 11, No. 8 (Aug. 2010), URL:  http://www.BRCommunity.com/a2010/b549.html  return to article

[4]  Note that in previous versions of the sidebar "at the time of travel" in RS81 and RS82, and "at" in RS90 – RS93 inclusive, were wrongly rendered.  These have been corrected in this version of the sidebar.  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "A Practical Method of Developing Natural Language Rule Statements (Part 17)" Business Rules Journal Vol. 11, No. 10, (Oct. 2010)
URL: http://www.brcommunity.com/a2010/b559.html

About our Contributor:


Graham   Witt
Graham Witt Consultant / Author

Graham Witt has over 30 years of experience in assisting organisations to acquire relevant and effective IT solutions. NSW clients include the Department of Lands, Sydney Water, and WorkCover while Victorian clients include the Departments of Sustainability & Environment, Education & Early Childhood Development, and Human Services. Graham previously headed the information management and business rules practice in Ajilon's Sydney (Australia) office.

Graham has developed specialist expertise in business requirements, architectures, information management, user interface design, data modelling, relational database design, data quality, business rules, and the use of metadata repositories & CASE tools. He has also provided data modelling, database design, and business rules training to various clients including NAB, Telstra, British Columbia Government, and ASIC and in the form of public courses run by Simsion Bowles and Associates (Australia) and DebTech (USA).

He is the co-author, with Graeme Simsion, of the widely-used textbook "Data Modeling Essentials" and is the author of the newly published book, "Writing Effective Business Rules" (published by Elsevier). Graham has presented at conferences in Australia, the US, the UK, and France. Contact him at gwitt@pacific.net.au.

Read All Articles by Graham Witt

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.