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:

whereas it should be:

as indicated by the supporting fact type:

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

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

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

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

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

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

4. temporal single record constraints, ensuring that a temporal state of affairs is recorded using a single record rather than multiple records, such as:

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

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.

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.

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

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

The next three fact types support rule statement RS193.

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:

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:

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:

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

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

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

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:

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.

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.

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.

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.

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.

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

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:

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  

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

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

# # #