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

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

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

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

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.

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.

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:

They should read as follows:

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.

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:

Missing fact types

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

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:

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

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:

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

With those additions RS63 now looks like this:

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:

Tightening airport security

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

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

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:

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:

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:

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  

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

[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  

# # #