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

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

Underlying Fact Types

In the previous article[3] we met our first rule statements with conditional clauses, of which RS60 was one:

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.

This rule statement is supported by a number of fact types.  The main clause (everything up to the word if) consists of a subject (everything up to the word must) and a predicate (everything between must be and if).  The fact types supporting the subject are:

FT45.  postal address includes placename
FT46.  postal address includes postal code
FT28.  flight booking confirmation specifies postal address

The fact types supporting the predicate are:

FT61.  postal authority allocates place name
FT62.  postal authority allocates postal code
FT63.  postal authority is of country
FT64.  postal address specifies country
  (derived from fact type FT47)

The fact type supporting the conditional clause is:

FT65.  airline can access postal code information from postal authority

Similarly with rule statement RS61:

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.

The fact type supporting RS61's main clause is:

FT66.  flight booking confirmation specifies set of passport details for passenger

The fact types supporting RS61's conditional clause are:

FT38.  flight booking confirmation specifies flight
FT67.  flight is international

And with rule statement RS62:

RS62. Each flight booking confirmation must specify exactly one date of birth for each passenger if that flight booking confirmation specifies an insurance option.

The fact type supporting RS62's main clause is:

FT68.  flight booking confirmation specifies date of birth for passenger

The fact type supporting RS62's conditional clause is:

FT69.  flight booking confirmation specifies insurance option

And, finally, with rule statement RS63:

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 fact type supporting RS63's main clause is:

FT70.  flight booking confirmation specifies escorting party at destination city

The fact types supporting RS63's conditional clause are:

FT71.  flight booking confirmation specifies passenger
  (derived from fact type FT12)
FT72.  passenger is of age
  (less obviously)

In most of these articles I've simply stated what fact types support each rule statement without any explanation.  Back in Articles 2[4] and 3[5], however, I made some general statements about:

  1. the fact types supporting rule statements generated from templates RT1 and RT2 (now superseded by RT15 and RT20 respectively, reproduced below), and

  2. the fact types supporting simple qualifying clauses.
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>|}.
RT20.  {A|An} <term 1> {<qualifying clause>|}
must not <verb phrase>
{a|an} <term 2>
{{if|unless} <conditional clause>|}.

In those articles I stated:

  1. In a rule statement generated from RT15 which omits term 1, verb phrase 1, and term 4 (none of which were available in the initial RT1 version),
    <term 2> <verb phrase 2> <term 3>
    must be a fact type (possibly derived from one or more other fact types), e.g.
RS47. Each flight booking confirmation for a return journey must specify exactly two flights.
FT38.  flight booking confirmation specifies flight
  1. In a rule statement generated from RT20,
    <term 1> <verb phrase 1> <term 2>
    must be a (possibly derived) fact type, e.g.
RS11. A flight booking request for a one-way journey must not specify a return date.
FT4.  flight booking request specifies return date
  1. There needs to be a fact type (using the verb phrase in the qualifying clause) to connect the term in the qualifying clause and the term being qualified (i.e., the one immediately before the qualifying clause), thus, if the qualifying clause in RT15 has the form
    that <verb phrase> {a|an|the|each|that} <term>,
    <term 2> <verb phrase> <term>
    must be a (possibly derived) fact type, e.g.
RS9. Each flight booking request for a return journey must specify exactly one return date.
FT6.  flight booking request is for return journey
  1. Similarly, if the qualifying clause in RT20 has the same form,
    <term 1> <verb phrase> <term>
    must be a possibly derived fact type, e.g., (also supporting RS11 reproduced above)
FT7.  flight booking request is for one-way journey

We can now also state:

  1. In a rule statement generated from RT15 which includes term 1 and verb phrase 1,
    <term 1> <verb phrase 1> <term 2>
    must be a (possibly derived) fact type, e.g.
RS40. The postal address (if any) specified in each flight booking confirmation must include at least one address line.
FT28.  flight booking confirmation specifies postal address
  1. In a rule statement generated from RT15 which omits term 1 and verb phrase 1 but includes term 4,
    <term 2> <verb phrase 2> <term 3> <preposition> <term 4>
    must be a (possibly derived) fact type, e.g.
RS53. Each flight booking confirmation must specify exactly one travel class for each flight.
FT54.  flight booking confirmation specifies travel class for flight
  1. In a rule statement generated from RT15 which includes term 1, verb phrase 1, and term 4,
    <term 1> <verb phrase 1> <term 3> <preposition> <term 4>
    must be a (possibly derived) fact type (we have no examples of this situation so far).

  2. There are similar metarules determining the fact types required to support rule statements generated from each of the other templates.

  3. There must be a (possibly derived) fact type for each verb phrase in a qualifying clause or conditional clause, each fact type using the term immediately preceding the verb phrase and the term (if any) following the verb phrase, e.g., rule statement RS60 and fact types FT61 – FT64 above.  Note that a pair of consecutive verb phrases may be supported by a ternary verb phrase, e.g., rule statement RS60 and fact type FT65 above.

  4. In most rule statements with a conditional clause, there must be a term common to both the main clause and the conditional clause, e.g., postal authority in RS60, flight booking confirmation in RS61 – RS63.

Categories and Enumerated Sets

When a person or organisation is providing information to another person, organisation or system, particular information items are often restricted to discrete sets of values.  We saw this with RS60 above and, earlier, with RS21 and RS22 reproduced below.

RS21. The origin city specified by each flight booking request must be one of the cities served by the airline.
RS22. The destination city specified by each flight booking request must be one of the cities served by the airline.

Each of these rule statements refers to some set to which the organisation, its employees and/or its system has access or knowledge.  We need analogous rule statements for the travel class and fare class items, hence RS64 and RS65 below.  Note that typically travel class can be nominated during the initial booking request, but the confirmation requires that the fare class (e.g. a cheaper fare subject to conditions or a more expensive unrestricted fare) be selected.  Note also that, unless one is booking sufficiently in advance (and sometimes not even then!) not all fare classes are available on the flight you want to travel on.

RS64. Each travel class specified in each flight booking request must be one of the travel classes offered by the airline.
RS65. Each fare class specified in each flight booking confirmation must be one of the fare classes available on that flight.

Let's look at the discrete sets involved in each of these rule statements.  The set of cities may have 100 or more members, may change slowly over time but, on any given day, each test of RS21 or RS22 refers to the same set.  These properties are also exhibited by the set of combinations of placename and postal code.  While the full set of fare classes has generally fewer than 10 members, and only changes slowly over time, the set of fare classes available will vary depending on the selected flight, and will vary during the day as more bookings are taken for each flight.  Large or volatile sets are best handled in rule statements by naming or describing the set rather than its members.

The set of travel classes, by contrast, has only 3 or 4 members, is likely to change even more slowly over time, and is the same whenever the rule statement is tested.  An alternative way of describing a set such as this is to enumerate its members, as in RS66.

RS66. The travel class specified in each flight booking request must be first class, business class, premium economy class or economy class.

This requires an enhancement to ST3 in the form of ST32 and ST33.

ST3. <value set predicate> ::=
one of the <term> {<qualifying clause>|}
ST32. <value set predicate> ::=
{one of the <term> {<qualifying clause>|}|<value-list>}
ST33. <value-list > ::=
{<literal 1> or <literal 2>|<literal 3>, <value-list>}

"And" or "or" in Qualifying Clauses

In the previous article I noted the similarity between conditional and qualifying clauses.  In that article, I also noted that conditional clauses may include and or or, but not both as such clauses can be ambiguous (as discussed in Article 4[6]).

Inclusion of both and and or in a qualifying clause would be similarly ambiguous.  In fact the inclusion of either and or or in a qualifying clause that also includes that or who can lead to ambiguity.  Consider the clause "who accompanies a passenger who is less than 5 years of age or is flying first class": it's not clear whether someone who is flying first class meets the conditions of this clause or, alternatively, whether  someone who accompanies a passenger who is flying first class meets the conditions of this clause.

Inclusion of either removes the ambiguity: "who either accompanies a passenger who is less than 5 years of age or is flying first class" makes it clear that someone who is flying first class meets the conditions of the clause, whereas "who accompanies a passenger who either is less than 5 years of age or is flying first class" makes it clear that someone who accompanies a passenger who is flying first class meets the conditions of the clause.

Note:

  1. both can be used with and in a similar manner, e.g., "who both accompanies a passenger who is less than 5 years of age and is flying first class".

  2. This ambiguity arises only if there is at least one that or who as well as the and or or, e.g., "who accompanies a disabled passenger or is flying first class" is not ambiguous.

  3. To be entirely unambiguous, either or both or but not both is needed after an either … or construction.

Clearly the sub-template for qualifying clauses needs some additional work.  We will look at this in a subsequent article.

"Not" in Qualifying and Conditional Clauses

And and or are logical binary operators operating on conditions.  A unary operator on conditions is not, which can also be useful.  However, unlike in, say, French, Arabic or the Slavic languages, negation of verb phrases in English is rather untidy, involving not as an infix, as in is specified in and is not specified in.  Worse, for verb phrases not starting with is, the verb phrase changes to the infinitive preceded by does not, as in specifies and does not specify.  For this reason, I do not explicitly include negative forms of verb phrases in templates or sub-templates (which would make them even more complex!) but allow verb phrases to be optionally negated (in the same way as they may be indicative or infinitive, and active or passive, as discussed in Article 2).


To be continued...
In subsequent articles we will look at further rule types, templates and sub-templates, in particular the enhanced sub-templates for qualifying clauses to allow for and or or.  We will also examine the difference between operational and structural rules, look at temporal rules, and 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 7)," Business Rules Journal, Vol. 10, No. 8 (Aug. 2009), URL:  http://www.BRCommunity.com/a2009/b489.html  return to article

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

[5]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 3)," Business Rules Journal, Vol. 10, No. 4 (Apr. 2009), URL:  http://www.BRCommunity.com/a2009/b473.html  return to article

[6]  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 8)" Business Rules Journal Vol. 10, No. 9, (Sep. 2009)
URL: http://www.brcommunity.com/a2009/b501.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
Subscribe to the eBRJ Newsletter
In The Spotlight
 Jim  Sinur
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

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.