What is this series of articles about?

This is the fifteenth 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. 

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

The editors of the Business Rules Community journal, in which this series of articles has been published, have been kind enough to give me my own byline.  Given my focus on natural language expression of rules, we've decided to call it "Mind your language."  Accordingly, I thought I would include in each of the next few articles some discussion of the various aspects of natural language that can feature in rule statements.  Where better to start than with noun phrases, known as Terms in the SBVR?

We use Terms to signify sets of real-world instances (objects, events, etc.).  Thus, for example, we can use the Term aircraft model to signify the set {Boeing 747, Boeing 767, Airbus A380, …} and aircraft to signify the set {N785UA, …, VH-OEJ, …} (although you'll frequently hear people use aircraft when actually talking about different models of aircraft rather than individual aircraft).

We often need to refer to a subset of a set.  When selecting a Term to signify a subset of a set for which we already have a Term, we can often prefix the existing Term.  We've seen this already with flight.  Two subsets of the set of flights operated by an airline can be signified by the Terms international flight and domestic flight.  Similarly, return journey and one-way journey signify subsets of the set signified by journey, online check-in signifies a subset of the set signified by check-in, and so on.  Note that whereas the last word in Term must be a noun, the prefix may be an adjective (as in these examples) or another noun, as in passenger name.

However, we sometimes use completely different Terms to signify a set and its subsets.  For example, many organisations that deal with both individuals and other organisations (as customers, suppliers, partners, etc.) use the Term party to signify the union of the sets signified by person (or individual) and organisation.

The right Term in a rule statement

When choosing the Terms to include in a rule statement, it is important that we choose the Term that covers all instances that are to be governed by the rule but does not include any instances that are not governed by the rule.

The Term passenger is a good example.  Not everyone at an airport is a passenger; there are airport and airline staff, as well as people farewelling or meeting passengers.  Yet each of the rule statements RS103 – RS115 inclusive has as its subject the Term passenger.  Do some of the rules expressed by these statements apply also to people other than passengers?  If they do, the rule statements in question should be rephrased to use the Term person rather than passenger.

I first encountered this problem when visiting a tourist steam railway operation in England.  At one end of the station platform was a sign reading "passengers must not pass this sign."  The motivation for this rule was clearly safety, yet it seemed to me that the safety of non-passengers was equally important.

Remember, each Term signifies a set.  At any one time, the set of passengers is a subset of the set of persons.  Stating a rule in terms of a subset of the set to which the rule should actually apply, as in the last example, makes the rule statement too specific.  At the same time, stating a rule in terms of a superset of the set to which the rule should actually apply makes the rule statement too general.  This would occur if we used the Term person in a rule statement expressing a rule that applies only to passengers.

Ambiguous Terms

Ambiguity can arise from the use of a Term that has multiple meanings.  A good example of this in the airline industry is the word service.  Setting aside the use of this word in verb phrases (mainly to do with maintenance and engineering) and its use as a qualifying noun in such Terms as service interval and long service leave, it is used by some airlines sometimes to signify the set each member of which is a set of flights, e.g., {the East Coast Service, the Melbourne – Sydney Service, …}, and at other times to signify the set of in-flight meal services, e.g., {Breakfast Service, Dinner Service, …}.  To make matters worse, public announcements at airports use service to refer to an individual flight (as in "Your 6pm service to Sydney is now boarding").  Obviously, the use of service without qualification in a rule statement will introduce ambiguity.

Ambiguity can also arise with Terms that may be used to denote different granularities.  The most common situation here is when the same Term is used to signify a set of recurrent events and the set of instances of that event.  For example, flight may be used to signify the set {QF1, QF2, …} or the set {QF1 on 1/1/2010, QF1 on 2/1/2010, …}.  Fortunately for us, this rarely causes a problem when formulating rule statements, as it is almost always clear from the context what is meant by the Term flight.  Problems can, however, arise from the fact that even an individual flight (on a particular day) may be a complex object.  If I travel from Sydney to Paris via London using QF1 for the Sydney – Bangkok and Bangkok – London legs and BA306 for the London – Paris leg, how many flights is that?  Again, it often doesn't matter, although it might if a rule were to be based on the number of flights flown.  In that situation, the Term flight leg could be used to signify the set {QF1 Sydney – Bangkok, QF1 Bangkok - London, …}.

Multi-Noun Terms

We've seen that we can prefix a Term with another noun to yield a Term signifying a subset of the set signified by the original Term.  For example, whereas booking signifies the set of all bookings, flight booking signifies a subset of that set, namely the set of all bookings for flights, and hotel booking signifies a different subset of the original set, namely the set of all bookings for hotel accommodation.

We can also suffix a Term with another noun to yield a Term signifying a set of components of the members of the original set.  For example, each member of the set signified by the Term flight booking has request and confirmation components:  the Term flight booking request signifies the set of requests for flight bookings whereas flight booking confirmation signifies the set of confirmations of flight bookings.

We can also suffix a Term with another noun to yield a Term signifying a set of attributes of the members of the original set.  For example, each member of the set signified by the Term passenger has a name; the Term passenger name signifies the set of names of passengers.

Enhancing our sub-templates

In the previous two articles^{[3]  [4]} we encountered RS108, a special case of a prerequisite process rule involving the possibility of a loop in the process flow, but we haven't yet identified the template and sub-templates that can be used to generate this rule statement.

It turns out that template RT33 can be used, provided we enhance the set of sub-templates that define conditional clauses.

The conditional clause in RS108 is, of course, that passenger has not entered landside after the last security screening of that passenger.  To establish what enhancements are required, let's first parse this clause:

1. that passenger has not entered landside is a simple conditional clause that can be generated using sub-template ST25 (reproduced below), since it contains:
   1. a condition subject (that passenger) that can be generated using sub-template ST49 (also reproduced below), and
   2. a condition (has not entered landside) that can be generated using sub-templates ST37 and ST46 (also reproduced below).
      
      
2. after the last security screening of that passenger is a prepositional phrase, containing:
   1. a preposition (after), and
   2. a term (security screening) preceded by a determiner (the last) and followed by a qualifying clause (of that passenger).

The prepositional phrase limits the time period in which the condition applies, namely only after the last security screening of the passenger, so we need to enhance ST46 to allow for the inclusion of a prepositional phrase at the end of a condition.  (Note that, while a prepositional phrase can in certain circumstances be included in the middle of a chained condition, the resulting construction is generally unwieldy and hard to interpret.)

For the moment, we won't create a sub-template for <preposition>; there are many prepositions we could use in rule statements, although some are more useful than others!  We will also explore the fact that we have classified prepositions as keywords here whereas previously we classified them as (parts of) verb phrases.^[5]  This is because prepositions can, in fact, play both roles.  We'll look at verb phrases and prepositions in more detail in later articles. 

May … only

In the previous article^[4] I took the liberty of moving the word only in a number of rule statements from immediately after may as in Article 13^[3] to immediately before if or after, in other words from before the verb phrase to after the verb phrase (and any term and qualifying clause standing as the object of that verb phrase).  There was a good reason for this, illustrated by the original and revised forms of RS107:

The original form of RS107 could be interpreted as "after check-in, a passenger may undergo departure control but nothing else" whereas the revised form states clearly and unambiguously "the only time a passenger is allowed to undergo departure control is after that passenger has undergone check-in."

However, we still have a rule statement with the construction may only, namely RS102.

This rule statement should similarly be reworded as follows:

However, this means that template RT31 (on which the original RS102 was based) is no longer valid; it must be replaced by RT34 (covering rule statements using must) and RT35 (covering rule statements using may … only):

To be continued...
In subsequent articles we will look at rules governing the way data is represented, as well as rules governing the parties or roles that are allowed to perform a process or use information.  We shall also look at various other topics, such as redundancy and self-contradiction within rule statements, 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 13)," Business Rules Journal, Vol. 11, No. 2 (Feb. 2010), URL:  http://www.BRCommunity.com/a2010/b522.html  

[4]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 14)," Business Rules Journal, Vol. 11, No. 4 (Apr. 2010), URL: http://www.BRCommunity.com/a2010/b532.html  

[5]  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/b494.html  

# # #