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

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 twenty-fourth 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 airline passenger activities (such as booking flights, checking, and boarding) and airline operations.  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]  In addition, any technical terms (particularly those drawn from the field of linguistics) are rendered in a bold italic font.

An error

Before we get going, I should apologise for an error that crept into Article 22[3] and hence the sidebar for Article 23[4].  RS176 appeared in both places as:

RS176. Each person has by definition at least one trading name.

whereas it should be:

RS176. Each organisation has by definition at least one trading name.

as indicated by the supporting fact type:

FT147.  organisation has trading name

Rule statements dealing with the time dimension

In the previous article[4] we looked at a number of rule statements dealing with the time dimension, including:

  1. rules governing when something happens, such as RS102: this is a process rule (specifically an inter-process interval rule for which we already have a template):
RS102. Online check-in for a flight may occur only during the 24 hours before the departure time of that flight.
  1. rules governing statements about when something is to happen (such as RS188) or has happened (such as RS189): these are data content rules (specifically range rules, for which we already have a template):
RS188. The departure date specified in each flight booking request must be no earlier than the date on which that flight booking request is made.
RS189. The departure date specified in each flight credit request must be earlier than the date on which that flight credit request is made.
  1. rules governing the start date and end date of time periods, such as RS192: this is a new type of data content rule, namely a data consistency rule, which requires consistency between two or more data items:
RS192. The combination of start date and end date specified in each frequent flier member status record must be such that that start date is no later than that end date.
  1. new types of data content rules governing records of the history of a changing attribute or relationship:
    1. temporal data non-overlap constraints, ensuring that the time periods specified in the records concerning a given person or thing do not overlap each other, such as:
RS193. The time period specified in each frequent flier member status record must not overlap the time period specified in any other frequent flier member status record for the same frequent flier membership.
    1. temporal data completeness constraints, ensuring that the time periods specified in the records concerning a given person or thing are contiguous and between them completely span some other time period, such as:
RS194. Each day within the membership period specified in each frequent flier membership record must be within the time period specified in exactly one frequent flier member status record for the frequent flier membership recorded in that frequent flier membership record.
    1. temporal data inclusion constraints, ensuring that the time periods specified in the records concerning a given person or thing do not fall outside some other time period, such as:
RS195. Each day within the time period specified in each frequent flier member status record must be within the membership period specified in the frequent flier membership record for the frequent flier membership with which that frequent flier member status record is associated.
    1. temporal single record constraints, ensuring that a temporal state of affairs is recorded using a single record rather than multiple records, such as:
RS196. Each status specified in a frequent flier member status record must be different to the status specified in the latest of the earlier frequent flier member status records for the same frequent flier membership.
  1. rules involving time-dependent attributes, such as RS63 (a data cardinality rule) and RS154 (a party restriction rule); any existing type of rule can involve a time-dependent attribute — the phrase at the time of travel (or similar) is simply a qualifying clause:
RS163. 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.
RS154. A person may travel alone only if that person is more than 2 years of age at the time of travel.

The new types of rules here are thus data consistency rules, temporal data non-overlap constraints, temporal data completeness constraints, temporal data inclusion constraints, and temporal single record constraints.  We need one or more templates for each of these, but first let's look at the fact types supporting some of these new rule statement types.

Fact types supporting temporal rule statements

By way of introduction, consider RS176 at the start of this article.  As this is a simple rule statement involving only two terms and one verb, it is easy to see that fact type FT147, involving the same two terms and verb, supports this rule statement.

Let's now look at some of the new rule statements introduced in the previous article.  Consider RS188, which has a subject (The departure date specified in each flight booking request) and a predicate (no earlier than the date on which that flight booking request is made).  Setting aside (until the next article) the temporal operator no earlier than, it should be clear that the subject and the predicate each involve two terms and a verb.

Fact type FT1 (reproduced below) clearly supports the subject, since it can be reversed to read departure date is specified in flight booking request.

FT1.  flight booking request specifies departure date

Fact type FT152 supports the predicate, although not so obviously.  A feature of the English language is that a prepositional verb (such as is made on) gets split when we need to qualify the object of that verb (in this case date), as in the date on which that flight booking request is made.  By contrast, if we need to qualify the subject of a prepositional verb, it retains its form in the qualifying clause, as in the flight booking request that is made on that date.

FT152.  flight booking request is made on date

Similarly fact types FT153 and FT154 support the subject and predicate respectively of rule statement RS189.

FT153.  flight credit request specifies departure date
FT154.  flight credit request is made on date

In much the same way fact types FT155 and FT156 support the subject of rule statement RS192.

FT155.  frequent flier member status record specifies start date
FT156.  frequent flier member status record specifies end date

The next three fact types support rule statement RS193.

FT157.  frequent flier member status record specifies time period
FT158.  time period overlaps time period
FT159.  frequent flier member status record is for frequent flier membership

This creates a dilemma, since a frequent flier member status record does not specify a time period as well as a start date and end date.  In fact it specifies a time period that is defined by a start date and end date, so we need the next two fact types to express that situation:

FT160.  time period is defined by start date
FT161.  time period is defined by end date

It should be clear that fact type FT155 can be derived from fact types FT157 and FT160, while fact type FT156 can be derived from fact types FT157 and FT161.

The next four fact types, along with FT157 and FT159, support rule statement RS194:

FT162.  day is within membership period
FT163.  frequent flier membership record specifies membership period
FT164.  day is within time period
FT165.  frequent flier membership is recorded in frequent flier membership record

Of course a membership period is a type of time period so we could document that using fact type FT166 and then be able to derive FT162 from FT164 and FT166:

FT166.  membership period is a category of time period

When we look at rule statement RS195, the following fact type appears to be required along with FT164, FT157, FT162, FT163, and FT159:

FT167.  frequent flier member status record is associated with frequent flier membership

This appears to duplicate FT159 with only a change to the verb phrase, so we shouldn't have both of them.  If we either reword RS193 and RS194 to use is associated with or reword RS195 to use is for, we can use just the one fact type.  Replacing RS193 and RS194 by RS197 and RS198 respectively allows us to use just FT167 for both (and dispense with FT159).

RS197. The time period specified in each frequent flier member status record must not overlap the time period specified in any other frequent flier member status record associated with the same frequent flier membership.
RS198. Each day within the membership period specified in each frequent flier membership record must be within the time period specified in exactly one frequent flier member status record associated with the frequent flier membership recorded in that frequent flier membership record.

We also have to replace RS196 by RS199 to use fact type FT167 (as well as FT168 and FT169).

RS199. Each status specified in a frequent flier member status record must be different to the status specified in the latest of the earlier frequent flier member status records associated with the same frequent flier membership.
FT168.  frequent flier member status record specifies status
FT169.  status is different to status

Some more templates

We need one or more templates for each of the new types of rule introduced above.

Data consistency rules

The key differences between rule statements for this type of rule and other data content rule statements are as follows:

  1. Each rule of this type governs a combination of data items: we have already seen rule statements that do this, such as RS56 and RS60, based on template RT22 (see the [sidebar]).

  2. Unlike those rules, however, the predicate (following must be) includes the words such that and a conditional clause (e.g., in the case of RS192, that start date is no later than that end date).

The template required is thus:

RT42.  {The|Each} combination of <simple and-list>
       {<qualifying clause>|} {
(if any)|}
      
that <verb phrase> each <term> {<qualifying clause>|}
must be such that <conditional clause>
{{
if|unless} <conditional clause>|}.

Temporal data non-overlap constraints

Rule statements for this type of rule have a quite specific form.  Three terms are involved:

<term 1>:  the term signifying the complex data item representing the time period for which each history record applies: time period is the appropriate term for most history records, consisting of start date and end date (or start timestamp and end timestamp); note that the same term should be substituted in place of each <term 1> in the template;

<term 2>:  the term signifying the history records themselves, e.g., in the case of RS197, frequent flier member status record; note that the same term should be substituted in place of each <term 2> in the template;

<term 3>:  the term signifying the person or thing that is the subject of the history records, e.g., in the case of RS197, frequent flier membership.

The following template supports this type of rule statement.

RT43.  The <term 1>
      
specified in each <term 2>
must not overlap the <term 1>
      
specified in any other <term 2>
       {
for|associated with} the same <term 3>
{{
if|unless} <conditional clause>|}.

Temporal data completeness constraints

Rule statements for this type of rule also have a quite specific form.  Six terms are involved:

<term 1>:  the term signifying a suitable unit of duration: day as in RS198 if time period in the history records consists of start date and end date (minute or second if time period in the history records consists of start timestamp and end timestamp);

<term 2>:  the term signifying the complex data item representing the total time period which the history records are to cover, e.g., in the case of RS198, membership period;

<term 3>:  the term signifying the record in which that complex data item is recorded, e.g., in the case of RS198, frequent flier membership record; note that the same term should be substituted in place of each <term 3> in the template;

<term 4>:  the term signifying the complex data item representing the time period for which each history record applies: again usually time period;

<term 5>:  the term signifying the history records themselves, e.g., in the case of RS198, frequent flier member status record;

<term 6>:  the term signifying the person or thing that is the subject of the history records, e.g., in the case of RS198, frequent flier membership.

The following template supports this type of rule statement.

RT44.  Each <term 1> within the <term 2>
      
specified in each <term 3>
must be within the <term 4>
      
specified in {exactly|at least} one <term 5>
       {
for|associated with} the <term 6>
      
recorded in that <term 3>
{{
if|unless} <conditional clause>|}.

Temporal data inclusion constraints

Rule statements for this type of rule have a very similar form to those for temporal data completeness constraints.  Again, six terms are involved:

<term 1>:  the term signifying a suitable unit of duration: day as in RS195 if time period in the history records consists of start date and end date (minute or second if time period in the history records consists of start timestamp and end timestamp);

<term 2>:  the term signifying the complex data item representing the time period for which each history record applies: again usually time period;

<term 3>:  the term signifying the history records themselves, e.g., in the case of RS195, frequent flier member status record; note that the same term should be substituted in place of each <term 3> in the template;

<term 4>:  the term signifying the complex data item representing the total time period which the history records are to cover, e.g., in the case of RS195, membership period;

<term 5>:  the term signifying the record in which that complex data item is recorded, e.g., in the case of RS195, frequent flier membership record;

<term 6>:  the term signifying the person or thing that is the subject of the history records, e.g., in the case of RS195, frequent flier membership.

The following template supports this type of rule statement.

RT45.  Each <term 1> within the <term 2>
      
specified in each <term 3>
must be within the <term 4>
      
specified in the <term 5>
      
for the <term 6>
      
with which that <term 3> is associated
{{
if|unless} <conditional clause>|}.

Temporal single record constraints

Rule statements for this type of rule also have quite specific forms, although there are two varieties, one where the history records record the changing values of a single data item (e.g., a status, as in the example rule statements), and another where the history records record the changing values of multiple data items.  Let us consider the single data item variety first: three terms are involved:

<term 1>:  the term signifying the data item that changes over time, the values of which are recorded in the history records, e.g., in the case of RS199, status; note that the same term should be substituted in place of each <term 1> in the template;

<term 2>:  the term signifying the history records themselves, e.g., in the case of RS199, frequent flier member status record; note that the same term should be substituted in place of each <term 2> in the template;

<term 3>:  the term signifying the person or thing that is the subject of the history records, e.g., in the case of RS199, frequent flier membership.

The following template supports this type of rule statement.

RT46.  Each <term 1>
      
specified in a <term 2>
must be different to the <term 1>
      
specified in the latest of the earlier <term 2>
      
for the same <term 3>
{{
if|unless} <conditional clause>|}.

If the history records record the changing values of multiple data items, the following template is required.  This differs from RT46 in that <term 1> is replaced by combination of <simple and-list> in each place.  Note that:

  1. <term 2> and <term 3> have the same meanings as in RT46;

  2. The same set of terms should be substituted in place of each <simple and-list> in the template.
RT47.  Each combination of <simple and-list>
      
specified in a <term 2>
must be different to the combination of <simple and-list>
      
specified in the latest of the earlier <term 2>
      
for the same <term 3>
{{
if|unless} <conditional clause>|}.

RS200 is an example of a rule statement based on RT47.  Fact types FT170 to FT176 inclusive support that rule statement.

RS200. Each combination of speed, altitude, and heading specified in a flight data record must be different to the combination of speed, altitude, and heading specified in the latest of the earlier flight data records for the same flight.
FT170.  flight data record specifies speed
FT171.  flight data record specifies altitude
FT172.  flight data record specifies heading
FT173.  speed is different to speed
FT174.  altitude is different to altitude
FT175.  heading is different to heading
FT176.  flight data record is for flight

Note that fact types FT173 to FT175 inclusive all have the form attribute is different to attribute, as does FT169 previously encountered.  You may prefer to replace these fact types by the following:

FT177.  attribute is different to attribute
FT178.  status is a category of attribute
FT179.  speed is a category of attribute
FT180.  altitude is a category of attribute
FT181.  heading is a category of attribute

To be continued...
In subsequent articles I will discuss an improved formulation for a particular rule statement type, a more consistent approach to styling of verb phrases in rule statements, and a more flexible and rational set of templates and sub-templates, as well as some other types of rule.  I will also share some of the insights gained while writing my book "Writing Effective Business Rules" due to be published by Elsevier early in 2012.

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 22)," Business Rules Journal, Vol. 12, No. 8 (Aug. 2011), URL:  http://www.BRCommunity.com/a2011/b611.html  return to article

[4]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 23)," Business Rules Journal, Vol. 12, No. 10 (Oct. 2011), URL: http://www.BRCommunity.com/a2011/b620.html. return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "A Practical Method of Developing Natural Language Rule Statements (Part 24)" Business Rules Journal Vol. 12, No. 12, (Dec. 2011)
URL: http://www.brcommunity.com/a2011/b630.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
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Ronald G. Ross

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.