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

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

Testability of rules

In the previous article I introduced a rule statement (RS57) that raises some issues, but I deferred discussion of those issues until this article.

RS57. The combination of placename and postal code included in the postal address (if any) specified by each flight booking confirmation must be one of the combinations of placename and postal code listed in the postal code file obtained from the postal authority.

For a start, this rule statement is implementation-specific.  Validation of placename and postal code combinations may instead be performed using a web service.  If we rephrase this rule as in RS58, it is no longer specific as to the validation mechanism:

RS58. The combination of placename and postal code included in the postal address (if any) specified by each flight booking confirmation must be one of the combinations of placename and postal code allocated by the postal authority.

However, we're still not out of the woods!  If postal addresses are not confined to the one country, the rule is ambiguous:  which postal authority?  The rule needs to be restated:

RS59. The combination of placename and postal code included in the postal address (if any) specified by each flight booking confirmation must be one of the combinations of placename and postal code allocated by the postal authority of the country specified in that postal address.

In this form the statement raises the issue of whether the rule can be feasibly tested.  If the airline can access postal code information from the postal authority of every country (unlikely), or:

  1. there is some other rule which constrains postal addresses to be in a limited set of countries, and
  2. the airline can access postal code information from the postal authority of each of those countries,

this rule can be tested, but these conditions may not apply in practice.  Of course, if the rule is restated as in rule statement RS60, the rule can be tested in all three of the following possible circumstances:

  1. the postal address specifies both a country for which postal code information is accessible and a combination of placename and postal code allocated by that country's postal authority (pass);
  2. the postal address specifies a country for which postal code information is accessible but a combination of placename and postal code which does not match any combination allocated by that country's postal authority (fail);
  3. the postal address specifies a country for which no postal code information is accessible (pass).
RS60. The combination of placename and postal code included in the postal address (if any) specified by each flight booking confirmation must be one of the combinations of placename and postal code allocated by the postal authority of the country specified in that postal address if the airline can access the postal code information from that postal authority.

One final point needs to be made about testing this rule.  If postal code information from a particular country is not up-to-date, a postal address may be specified which specifies a combination of placename and postal code which does not match any combination currently accessible.  This rule must therefore not be enforced absolutely; instead, a warning should be issued and the person entering the data given the opportunity to "proceed with caution."

Whereas rule statements RS58 and RS59 were based on the same template (RT14) and sub-templates (ST21 and ST22) as RS57 but with different second qualifying clauses, rule statement RS60 differs from RS59 through the inclusion of a conditional clause.

Conditional clauses

Let's look at a few more rule statements using conditional clauses:

RS61. Each flight booking confirmation must specify exactly one set of passport details for each passenger if any flight specified in that flight booking confirmation is international.
RS62. Each flight booking confirmation must specify exactly one date of birth for each passenger if that flight booking confirmation specifies an insurance option.
RS63. Each flight booking confirmation must specify exactly one escorting party at the destination city if every passenger specified in that flight booking confirmation is less than 12 years of age.

The conditional clause in each of these rule statements (and in RS60) is introduced by the word if and consists of:

  1. a subject:
    1. the airline in RS60
    2. any flight specified in that flight booking confirmation in RS61
    3. that flight booking confirmation in RS62
    4. every passenger specified in that flight booking confirmation in RS63

  2. a condition:
    1. can access the postal code information from that postal authority in RS60
    2. is international in RS61
    3. specifies an insurance option in RS62
    4. is less than 12 years of age in RS63.

We can make the following observations about these conditional clauses:

  1. The subject may be:
    1. a single noun phrase, i.e., a term preceded by the, that, any, or every, as in RS60 or RS62, or
    2. a noun phrase followed by a qualifying clause, as in RS61 or RS63.

  2. The condition may be any of the following:
    1. a transitive verb phrase followed by a term (preceded by an article and optionally followed by a qualifying clause), as in RS60 or RS62,
    2. an intransitive verb phrase, as in RS61, or
    3. is followed by a predicate, as in RS63.

  3. Normally the word that must appear in the subject (at the start or within the qualifying clause), immediately followed by a reference to one of the terms in the main clause of the rule statement.  Alternatively the word the may be used if followed by a term which refers to a set with only one member relevant to the rule statement (in this case airline).

In addition, we can make the following conjectures about conditional clauses:

  1. The word unless could be used instead of if to introduce a conditional clause.
  2. As in a qualifying clause, the term in a condition could be preceded by each or that rather than an article.
  3. A conditional clause could consist of multiple subject-condition pairs separated by and or or.  However, as we saw in the fourth article[3], the use of and and or in the same clause can be ambiguous.

This should help us to put together the sub-templates we need for conditional clauses.

ST24. <conditional clause> ::=
  {<simple conditional clause>|<and-conditional clause>|
<or-conditional clause>
}
ST25. <simple conditional clause> ::=
  <condition subject> <condition>
ST26. <and-conditional clause> ::=
  <simple conditional clause> and
{<simple conditional clause>|<and-conditional clause>}
ST27. <or-conditional clause> ::=
  <simple conditional clause> or
{<simple conditional clause>|<or-conditional clause>}
ST28. <condition subject> ::=
  {the|that|any|every} <term> {<qualifying clause>|>}
ST29. <condition> ::=
  {<verb phrase>
{{<
article>|each|that} <term> {<qualifying clause>|}|}|
is <predicate>}

Each type of rule can be conditioned, so each template needs to allow for a conditional clause.  The ideal position for a conditional clause is after the main clause, i.e., at the end of the rule statement.  However if a rule statement ends with a list, following that list with a conditional clause yields an awkward construction, difficult to understand.  A better position for the conditional clause in such a rule statement is directly after the word must, but the conditional clause then interrupts the flow of the main clause.  This is mitigated by enclosing the inserted clause (and the preceding if or unless) in parentheses.

Before we list our enhanced templates, however, we should note that RS63 is using a slightly different form of the object noun phrase to those we've seen previously.  RS61 and RS62 use the <cardinality> <term> for each <term> form we've seen previously, but RS63 uses <cardinality> <term> at the <term>.  In fact, not only can the be used instead of each, but any preposition can be used instead of for.

RT15.  {{The|Each} <term 1> {(if any)|} that <verb phrase 1>|}
   
each <term 2> {<qualifying clause>|}
must <verb phrase 2>
<
cardinality> <term 3> {<preposition> {each|the} <term 4>|}
{{
if|unless} <conditional clause>|}.
RT16.  Each <term 1> {<qualifying clause>|}
must {({if|unless} <conditional clause>)|} specify whether
{{
or not|}
    {
it|the <term 2>} <verb phrase 1> {<article> <term 3>|}|
    {
it|the <term 4>} <verb phrase 2> <or-list>}.
RT17.  Each <term 1> {<qualifying clause>|}
must <verb phrase>
{
a|an} <term 2>, {a|an} <term 3> or both
{{
if|unless} <conditional clause>|}.
RT18.  Each <term 1> {<qualifying clause>|}
must <verb phrase>
{
a|an} <term 2> or {a|an} <term 3> but not both
{{
if|unless} <conditional clause>|}.
RT19.  Each <term 1> {<qualifying clause>|}
must {({if|unless} <conditional clause>)|} <verb phrase>
<
cardinality> of the following: <or-list>.
RT20.  {A|An} <term 1> {<qualifying clause>|}
must not <verb phrase>
{a|an} <term 2>
{{if|unless} <conditional clause>|}.
RT21.  The <term 1> {<qualifying clause>|} {(if any)|}
   
that <verb phrase> each <term 2> {<qualifying clause>|}
must be
<predicate>
{{
if|unless} <conditional clause>|}.
RT22.  The combination of <simple and-list>
    {<qualifying clause>|} {(if any)|}
    that <verb phrase> each <term 2> {<qualifying clause>|}
must be
<combination predicate>
{{if|unless} <conditional clause>|}.
RT23.  The <set function> of {the|} <term 1>
   
that <verb phrase> each <term 2>
must be
<predicate>
{{
if|unless} <conditional clause>|}.

Rule types and templates revisited

Now that we've replaced each template with a revised version incorporating a conditional clause we'd better bring the mapping of rule types and templates up to date.

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 RT23 <set function> ::= number
Value set rule RT21 <predicate> ::= <value set predicate>
if only 1 data item
RT22 <combination predicate> ::=
<combination value set predicate>
if combination of data items
Match rule RT21 <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

Qualifying clauses revisited

If we look at the existing sub-template for a qualifying clause (ST6) we can see that it requires a transitive verb phrase followed by a term (preceded by an article and optionally followed by a qualifying clause).

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

However, there is no reason why a qualifying clause cannot also (like a condition) include either of the following:

  1. an intransitive verb phrase, e.g., is online, has expired, has closed
  2. is followed by a predicate, e.g., is less than 12 years of age

Note that, unlike the original form of qualifying clause, neither of these two forms ends with a term.  Therefore, since a qualifying clause can only follow a term, neither of these two forms of qualifying clause can be followed directly by another qualifying clause.

Given all this, we need to enhance sub-template ST6 to accommodate these alternative forms.  While we're doing that, we should also note that, if the term qualified by the qualifying clause refers to a person or persons, it is more appropriate to start the qualifying clause with who rather than that.  Sub-template ST30 is the enhanced version of ST6 that takes all this into account.

ST30. <qualifying clause> ::=
  {that|who}
{<verb phrase>
{{a|an|each|that|the} <term> {<qualifying clause>|}|}|
is <predicate>}

However, when we compare sub-template ST30 with ST29, it becomes obvious that a qualifying clause is a condition preceded by that or who; ST31 reflects this.

ST31. <qualifying clause> ::= {that|who}<condition>


To be continued...
In subsequent articles we will not only look at further rule types, templates and sub-templates, but explore the metarules governing the underlying fact types required for a rule statement and the clauses from which it is constructed.  We will also explore some techniques for rule statement quality assessment, including identification of redundant and conflicting rule statements.

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 4)," Business Rules Journal, Vol. 10, No. 5 (May 2009), URL:  http://www.BRCommunity.com/a2009/b481.html  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "A Practical Method of Developing Natural Language Rule Statements (Part 7)" Business Rules Journal Vol. 10, No. 8, (Aug. 2009)
URL: http://www.brcommunity.com/a2009/b494.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.