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

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 eleventh 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:  this month, as well as including the templates added last month, I've updated the table which indicates the appropriate (sub-)templates.

The taxonomy, templates, and sub-templates are listed in the [sidebar] along with all valid rule statements and supporting fact types:  this month I've added a number of fact types supporting rule statements added in recent articles.

The font and colour conventions used in these articles reflect those in the SBVR.[2]

Some more temporal rules

By the time you read this, I'll have attended — and spoken at — the Business Rules Forum in Las Vegas, but as I write these words I'm preparing for the flight from Sydney to Las Vegas in just over two weeks time.  When booking my flight, I complied with all rules governing the information required to make a successful flight booking.  Two of those rules were RS38 and RS39:  I complied with RS38 as I booked weeks ahead, and I complied with RS39 as I wanted to spend more than 1 hour at the conference after nearly 24 hours travelling!

RS38. The departure time of the return flight (if any) specified in each flight booking confirmation must be no earlier than 1 hour after the arrival time of the outgoing flight specified in that flight booking confirmation.
RS39. The departure time of the outgoing flight specified in each flight booking confirmation that is made online must be no earlier than 3 hours after the booking confirmation time of that flight booking confirmation.

However these rule statements represent an over-simplification:  I actually had to book two flights (changing planes in LAX) in each direction.  To accommodate multiple connecting flights in either direction, RS38 and RS39 need to be modified as in RS86 and RS87, respectively.

RS86. The departure time of the first or only return flight (if any) specified in each flight booking confirmation must be no earlier than 1 hour after the arrival time of the last or only outgoing flight specified in that flight booking confirmation.
RS87. The departure time of the first or only outgoing flight specified in each flight booking confirmation that is made online must be no earlier than 3 hours after the booking confirmation time of that flight booking confirmation.

Notice that the only differences are in the qualifying clauses:

  1. {that is|} of the first or only return flight

  2. {that is|} of the last or only outgoing flight

  3. {that is|} of the first or only outgoing flight

so template RT21 does not need to be modified.  Instead the sub-template for <qualifying clause> (or one of its constituents) will have to be modified, but, before we do that, let's look at some other rule statements.

Of course, if more than one flight is required to reach or return from the destination, there is a similar constraint on transit (connection) times between those flights, as stated in RS88 and RS89, which represent the situation for journeys consisting only of domestic flights within Australia.

RS88. The departure time of the second or any subsequent outgoing flight (if any) specified in each flight booking confirmation must be no earlier than 30 minutes after the arrival time of the previous outgoing flight specified in that flight booking confirmation.
RS89. The departure time of the second or any subsequent return flight (if any) specified in each flight booking confirmation must be no earlier than 30 minutes after the arrival time of the previous return flight specified in that flight booking confirmation.

These rules were brought home to me when the airline flying me from Las Vegas back to LAX decided to change my flight to a later time after I had booked, resulting in a 10 minute transit of LAX — definitely not feasible!  So I had the choice of an earlier departure from Vegas or a later departure from LAX.

In fact, the minimum transit time varies, depending on a number of circumstances.  For example, ports with multiple terminals (e.g., JFK) may require longer transfer times, as do ports such as London Heathrow, with not only multiple terminals but large ones that can require up to 20 minutes' walk to a gate lounge.  Also significantly longer times are required between an international flight entering a country and a connecting flight within that country:  in my experience you can't transit LAX from outside the USA in under 3 hours.  So the actual minimum transit time allowed depends on the airport and whether any of the flights are international.  This requires a different formulation, as stated in RS90 and RS91 (outgoing flights) and RS92 and RS93 (return flights).

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 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 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 return flight must precede the departure time of the next return 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 return flight 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 return flight must precede the departure time of the next return 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 return flight is international.

The concept of two flights connecting at a port then brings up an additional type of constraint where there is more than one connecting flight in either direction, namely that the destination port of each flight other than the last must be the same as the origin port of the next (connecting) flight, as stated in RS94 and RS95.

RS94. The destination port of each outgoing flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must be the same as the origin port of the next outgoing flight specified in that flight booking confirmation.
RS95. The destination port of each return flight other than the last specified in each flight booking confirmation that specifies more than one return flight must be the same as the origin port of the next return flight specified in that flight booking confirmation.

Note that I've been referring to ports here rather than cities.  Cities are appropriate as destinations of journeys (on my various journeys to London I've sometimes landed at Heathrow and sometimes at Gatwick), but connections at cities with more than one port (e.g., London, New York) must be constrained to occur at just one of those ports.

New qualifying and conditional clause formulations

Again most of the differences are in the qualifying clauses, with some additional differences in conditional clauses.  The additional clause formulations we've introduced in this article are:

  1. {that is|} of the {first|last} or only <term>

  2. {that is|} of the second or any subsequent <term>

  3. {that is|} of the {previous|next} <term>

  4. {that is|} other than the last (other than the first is also likely to be useful)

  5. that specifies <cardinality> <term>

  6. at which those <term> <verb phrase>

for qualifying clauses and:

  1. no <term> <verb phrase>

for conditional clauses.

Let's look first at additional formulations 1 – 4.  Each of these selects one or more instances from a sequenced set, and does so either by including one of the words first, second, last, previous, next, subsequent, only (or two of those words separated by or) between the and <term>, or by preceding the by other than and replacing the <term> after the by first or last.  Actually, in the latter case, first or last is included before <term> but <term> can be elided as it is the same as the <term> immediately before other than.

Although additional formulation 5 is different from 1 – 4, in that it has nothing particularly to do with sequenced sets, it is syntactically similar in that it involves <cardinality> rather than the before <term>.

The relevant sub-templates are:

ST33. <qualifying clause> ::=
  {<simple qualifying clause>|<chained qualifying clause>|
<or-qualifying clause>|<and-qualifying clause>|
<either-or-qualifying clause>|<both-and-qualifying clause>
}
ST38. <simple qualifying clause> ::=
  {that|who} <final condition>
ST35. <final condition> ::=
  {<simple condition>|<verb phrase>|is <predicate>}
ST34. <simple condition> ::=
  <verb phrase> {<article>|each|that} <term>

We first need more flexibility in a <simple condition>:  rather than just <article>, each, or that between <verb phrase> and <term>, we need to allow for the {first|last} or only, the second or any subsequent, the {previous|next}, or <cardinality>.  We also need to allow other than the {first|last} as an alternative <final condition>:  these formulations have to be final conditions since they can't be followed by further qualifying clauses.

Additional formulation 7 is also easy to deal with.  The relevant sub-templates are:

ST24. <conditional clause> ::=
  {<simple conditional clause>|<and-conditional clause>|
<or-conditional clause>
}
ST25. <simple conditional clause> ::=
  <condition subject> <condition>
ST28. <condition subject> ::=
  {the|that|any|every} <term> {<qualifying clause>|}
ST37. <condition> ::=
  {<final condition>|<chained condition>}
ST35. <final condition> ::=
  {<simple condition>|<verb phrase>|is <predicate>}
ST34. <simple condition> ::=
  <verb phrase> {<article>|each|that} <term>

All we need here is to allow no as an alternative determiner before <term> in a <condition subject>.

That leaves us with additional formulation 6, at which those <term> <verb phrase>.  This formulation introduces two new syntactic concepts:

  • alternative treatments of verb phrases involving prepositions;
  • reflexive verb phrases.

Let's deal first with verb phrases involving prepositions.  To do this we should first look at verb phrases not involving prepositions, e.g., serves in the fact type airline serves city.  This verb phrase can be used in qualifying clauses in either order, for example:

  • that serves that city
    as in:  each airline that serves that city or

  • that is served by that airline
    as in:  each city that is served by that airline.

In fact, each fact type is bi-directional and has a different formulation in each direction.

But what of the fact type seat is available on flight (in which the verb phrase involves the preposition on)?  A "reverse" formulation is not so easy to state for this fact type, but we can still use it in qualifying clauses in either order, i.e.:

  • that is available on that flight
    as in:  each seat that is available on that flight and

  • on which a seat is available
    as in:  each flight on which a seat is available.

This works generally for all verb phrases involving prepositions:  the preposition can be moved to the front of the qualifying clause and followed by which (or, as we shall see, whom) rather than that.  It also works for ternary fact types, e.g., flight booking confirmation specifies date of birth for passenger supports the following qualifying clauses:

  • that specifies the date of birth for that passenger
    as in:  the flight booking confirmation that specifies the date of birth for that passenger;

  • that is specified for that passenger in that flight booking confirmation
    as in:  the date of birth that is specified for that passenger in that flight booking confirmation;

  • for whom the date of birth is specified in that flight booking confirmation
    as in:  the passenger for whom the date of birth is specified in that flight booking confirmation.

The qualifying clause
      at which those flights connect
      as in:  the port at which those flights connect
looks to be based on the fact type flights connect at port, but the relevant fact type is actually ternary:

FT82.  flight connects with flight at port

The repetition of flight in this fact type would normally pose a problem when trying to use the fact type in a rule statement.  We can't write the port at which that flight connects with that flight but must distinguish the flights.  How?  You might be tempted to use first and second (e.g., the port at which the first flight connects with the second flight), but that would be confusing since the rule will indeed cover the first and second flights in any journey involving two or more flights but also needs to cover the second and third flights in any journey involving three or more flights.  Fortunately reflexive verb phrases (those involving the same term twice) offer us a way out, in that we can usually refer to the term in the plural as we did in rule statements RS92 and RS93 earlier in this article.

So what do the sub-templates need to look like now?  I leave that question for you to try to work out before the next article comes out.


To be continued...
In the next article, we'll look at the new sub-templates for the new qualifying and conditional clause formulations we've looked at in this article.  In that and subsequent articles we will take another look at temporal rules, as well as rule statement quality assessment, including identification of redundant and conflicting rule statements, and rule statement generalisation and its implications.

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

# # #

Standard citation for this article:


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

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.