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!

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.

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.

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).

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.

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:

7. 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:

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:

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:

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  

[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.  

# # #