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

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

Analysing a set of rule statements

If you have been following this series of articles, you may recall that Manuel Lamotte-Schubert, of the Max Planck Institute for Informatics in Saarbrücken, Germany, made some observations about the rule statements and templates that have been developed so far in the series.  I was able to meet Manuel during a recent visit by him to Peter Baumgartner, of NICTA (National ICT Australia) in Canberra, Australia, with whom he is collaborating.  We discussed the rule statements and templates at some length, and some interesting points arose from those discussions.

Entities playing roles

One phenomenon Manuel observed was that a relationship between two entities may involve one or both entities playing a particular role.  Consider fact types FT8 and FT9 (each reproduced below), each of which describes a different relationship between a flight booking request and a city.  Even though from the point of view of a flight booking request there are two cities, each playing a different role (and hence given different role names), each of them is a city (and must be a city served by the airline as stated in rule statements RS21 and RS22 — each reproduced below).

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

Indeed, fact type FT14 (reproduced below) describes the relationship between airlines and the cities they serve:

FT14.  airline serves city

However these three fact types (FT8, FT9 and FT14) do not appear to connect properly.  It appears as if fact types linking origin city and destination city with city are required.  It might be tempting to create categorisation fact types of the form origin city is a category of city and destination city is a category of city but that is incorrect.  Every city is an origin city for some flights and a destination city for other flights; origin city and destination city are not categories of city but roles played by cities in various situations.

Version 1.0 of the SBVR proposes "is-role-of" fact types that specify roles played by concepts in other fact types; following the examples in the SBVR, the roles played by 'city' in a flight booking request would be specified by fact types with the form "city plays the role 'origin city' in the fact type 'flight booking request specifies origin city'" and "city plays the role 'destination city' in the fact type 'flight booking request specifies destination city'."  These are actually facts about the model rather than being facts or fact types about the real world being modelled, which is what I have been primarily collecting so far.

So I thought I would look at the EU-Rent example in that version of the SBVR, which includes examples of both roles and role naming.  The EU-Rent vocabulary entries and diagrams illustrate how to support these, along with some introductory example facts about the model (rather than about EU-Rent), which take the form "The noun concept 'origin city' is a role that ranges over the noun concept 'city'."  These make no reference to any fact type since these are examples of situational roles rather than fact type roles, i.e., no relationship to any particular fact type is called for.

Given this state of affairs, and the fact that the SBVR team are currently working on a significant update of "is-role-of" fact types, I've decided to leave open for the time being what form any fact types should take that include role names, and provide examples in a subsequent article.

Specifying entities using their identifiers

A flight booking confirmation is required to specify the names of the passengers involved, as stated in rule statement RS16 supported by fact type FT12 (each reproduced below):

RS16.  Each flight booking confirmation must specify at least one passenger name.
FT12.  flight booking confirmation specifies passenger name

However other rule statements (such as RS63 reproduced later in this article) refer to flight booking confirmations specifying passengers (rather than their names).  This is supported by fact type FT71 (reproduced below):

FT71.  flight booking confirmation specifies passenger

In fact, a form specifies an instance of some set by including a suitable identifier of that instance, so that FT12 and FT71 are equivalent.  In fact, either one can be derived from the other, provided there is an additional fact type (FT113) that establishes that a passenger is (at least for these purposes) identified by his or her name.

FT113.  passenger name identifies passenger

Multi-step processes

Flight booking request and flight booking confirmation represent two steps of a multi-step process.  While this is indicated in fact type FT15 (reproduced below), a flight booking confirmation cannot occur without a preceding flight booking request, so what is needed is rule statement RS149 to prevent that.

FT15.  flight booking request gives rise to flight booking confirmation
RS149. Each flight booking confirmation must arise from a flight booking request.

Note that it is not true that every flight booking request gives rise to a flight booking confirmation, as a person making a request may decide not to proceed — for example, if there are no flights available at the right time and within that person's budget.

Errata

The following fact types are incorrect as they stand:

FT21.  payment is for flight booking request
FT56.  record locator is allocated to confirmed flight booking

They should read as follows:

FT21.  payment is for flight booking confirmation
FT56.  record locator is allocated to flight booking confirmation

Remember that in the previous article[3] I pointed out that 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) in the flight booking confirmation, when you have seen what classes are available on what flights.  The latter is the case in the model we have been developing, so neither RS64 nor RS66 (each reproduced below) is valid as it stands, since a flight booking request cannot specify a travel class.  Since you select the fare class rather than the travel class, neither RS64 nor RS66 is even needed since we also have RS65 (also reproduced below).  For example, if you select a "Red Spot Special" fare, you travel in economy (coach) class since that fare class is tied to that travel class.

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.
RS66. The travel class specified in each flight booking request must be first class, business class, premium economy class or economy class.

The "each" at the start of RS65 is correct since you can select different fare classes for the outgoing and return flights.  However since you are selecting a fare class for each flight, RS65 is more appropriately worded as follows:

RS65. Each fare class specified for each flight in each flight booking confirmation must be one of the fare classes available on that flight.

Missing fact types

The following additional fact type is required to support RS83 and RS84 (reproduced below):

FT115.  flight is part of journey
RS83. The origin city of the return flight of a return journey is by definition the same as the destination city of the outgoing flight of that return journey.
RS84. The destination city of the return flight of a return journey is by definition the same as the origin city of the outgoing flight of that return journey.

The following additional fact type is required to support the relationship between cities and the ports (airports to you and me) that serve them, since some rule statements refer to cities and some refer to ports:

FT116.  port serves city

A source of ambiguity — missing qualifying clauses

Manuel also noticed that rule statements RS61 – RS63 inclusive are each missing an essential qualifying clause.  Consider RS61 and RS62 first (each reproduced below):

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.

Unfortunately, the qualifying clause for each passenger in each of these rule statements is, as it stands, insufficiently precise.  Passport details or dates of birth only need to be specified for those passengers specified in the flight booking confirmation in question.  The term passenger therefore needs to be followed by the qualifying clause specified in that flight booking confirmation.  With this necessary modification, RS61 and RS62 now look like this:

RS61. Each flight booking confirmation must specify exactly one set of passport details for each passenger specified in that flight booking confirmation 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 specified in that flight booking confirmation if that flight booking confirmation specifies an insurance option.

RS63 (reproduced below) already has that qualifying clause to qualify the term passenger but needs:

  1. the same qualifying clause to qualify the term destination city
  2. a qualifying clause to qualify the age limit (it is the passengers' age at the time of travel that is relevant).
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.

With those additions RS63 now looks like this:

RS63. Each flight booking confirmation must specify exactly one escorting party at the destination city specified in that flight booking confirmation if every passenger specified in that flight booking confirmation is less than 12 years of age at the time of travel .

Prompted by the observations made and issues raised by Manuel, I decided to review some of the other rule statements developed so far.  I discovered that rule statements RS90 – RS93 inclusive were also each missing the same essential qualifying clause.  With the addition of that qualifying clause they now look like this:

RS90. The arrival time of each outgoing flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must precede the departure time of the next outgoing flight specified in that flight booking confirmation by at least the minimum domestic transit time for the port at which those flights connect if no outgoing flight specified in that flight booking confirmation is international.
RS91. The arrival time of each outgoing flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must precede the departure time of the next outgoing flight specified in that flight booking confirmation by at least the minimum international transit time for the port at which those flights connect if any outgoing flight specified in that flight booking confirmation is international.
RS92. The arrival time of each return flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must precede the departure time of the next outgoing flight specified in that flight booking confirmation by at least the minimum domestic transit time for the port at which those flights connect if no outgoing flight specified in that flight booking confirmation is international.
RS93. The arrival time of each return flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must precede the departure time of the next outgoing flight specified in that flight booking confirmation by at least the minimum international transit time for the port at which those flights connect if any outgoing flight specified in that flight booking confirmation is international.

Tightening airport security

Two other rule statements, RS111 and RS114, are perfectly logical as rule statements but do not accurately reflect airport security requirements.

RS111. A passenger may pass through departure control only if that passenger presents a boarding pass in which the departure date is no earlier than the date of departure control and is no later than 1 day after the date of departure control.
RS114. A passenger may pass through security screening for an international flight only if that passenger presents a boarding pass that specifies a departure date that is no earlier than the date of security screening and is no later than 1 day after the date of security screening.

Notice that these rule statements as they stand do not require the boarding pass to bear the name of the passenger actually travelling, so a person carrying a valid passport with their name and likeness and someone else's boarding pass could pass through departure control — since they would comply with RS111 and RS112 (reproduced below) — and security screening — since they would comply with RS114 and RS115 (also reproduced below).

RS112. A passenger may pass through departure control only if that passenger presents a passport that specifies the name of that passenger and bears a likeness of that passenger and specifies an expiry date that is later than 6 months after the date of departure control.
RS115. A passenger may pass through security screening for an international flight only if that passenger presents a passport that specifies the name of that passenger and bears a likeness of that passenger and specifies an expiry date that is later than 6 months after the date of security screening.

RS111 and RS114 each need to be "beefed up" by the addition of specifies the name of that passenger to the qualifying clause qualifying boarding pass.  They should now be as follows:

RS111. A passenger may pass through departure control only if that passenger presents a boarding pass that specifies the name of that passenger and specifies a departure date that is no earlier than the date of departure control and is no later than 1 day after the date of departure control.
RS114. A passenger may pass through security screening for an international flight only if that passenger presents a boarding pass that specifies the name of that passenger and specifies a departure date that is no earlier than the date of security screening and is no later than 1 day after the date of security screening.

Of course the way RS111 and RS114 are implemented is that the officer performing the check compares the passenger name on the boarding pass with the passenger name on the passport which must be presented at the same time.

Both of these rule statements (as well as RS112 and RS115) deal solely with international flights (RS114 and RS115 explicitly and RS111 and RS112 by virtue of the fact that departure control only applies to international flights).  RS109 as it stands covers both domestic and international flights: while it accurately describes the check that occurs when boarding a domestic flight (in Australia at least) it does not accurately describe the check that occurs when boarding an international flight, since that too actually requires that the boarding pass presented specifies the name of the passenger.  RS109 therefore needs to be replaced by the following two rule statements, one for domestic and one for international flights:

RS150. A passenger may board a domestic flight only if that passenger presents a boarding pass that specifies that flight and specifies the departure date of that flight.
RS151. A passenger may board an international flight only if that passenger presents a boarding pass that specifies the name of that passenger and specifies that flight and specifies the departure date of that flight.

Elision of repeated verb phrases

RS151 (as well as RS150 and quite a few other rule statements) uses the same verb phrase (specifies) in each of the conditions making up the qualifying clause.  An alternative way of rendering this rule statement would be as follows:

RS151. A passenger may board an international flight only if that passenger presents a boarding pass that specifies the name of that passenger and that flight and the departure date of that flight.

Similar elision of the second and any subsequent occurrence of specifies in the qualifying clause can be made, if desired, in any rule statement in which specifies appears more than once in the qualifying clause and is the only verb that appears in the qualifying clause.


To be continued...
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 18)," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL:  http://www.BRCommunity.com/a2010/b569.html  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "A Practical Method of Developing Natural Language Rule Statements (Part 19)" Business Rules Journal Vol. 12, No. 2, (Feb. 2011)
URL: http://www.brcommunity.com/a2011/b580.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
 Ronald G. Ross
 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.