Writing Natural Language Rule Statements — a Systematic Approach Part 10: The Effect of the Time Dimension on Rules

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
About this series of articles

While my first series of articles on writing natural language rule statements[1] explored a wide variety of issues in a rather organic and hence random manner, this series takes a more holistic and systematic approach and draws on insights gained while writing my recently-published book on the same topic.[2]  Rule statements recommended in these articles are intended to comply with the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR) version 1.0.[3]

The story so far

In previous articles in this series (see the "Language Archives" sidebar) we have looked at a variety of data cardinality rule statements,[4] as well as the following data content rule statements:[5]  range rule statements,[6] value set rule statements,[7] uniqueness constraint statements,[8] (in)equality rule statements,[9] data consistency rule statements,[10] and temporal data constraint statements.[11] Each type of rule statement has a common formulation which we have discussed in both a relatively informal way and by way of rule statement patterns.

While temporal data constraints constrain temporal data items (dates or times), the time dimension can affect other data rules, so we need to discuss the implications before moving on.

Errata

In parts 7 and 8 of this series, an error crept into the rule statement patterns for equality and inequality rule statements.  The pattern for equality rule statements alone in part 7 should have been:

P19.  <equality rule statement> ::=
{Each | The} <data item term> {(if any) |}
            specified
            {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>
            {<qualifying clause> |}
must <equality predicate>
{{if | unless} <conditional clause> |}.

Similarly the combined pattern for equality and inequality rule statements in part 8 should have been:

P19.  <(in)equality rule statement> ::=
{Each | The} <data item term> {(if any) |}
            specified
            {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>
            {<qualifying clause> |}
must <(in)equality predicate>
{{if | unless} <conditional clause> |}.

The effect of the time dimension on data rules

When authoring a rule statement it may be necessary to take the time dimension into account.  For example:

  1. If a constrained data item is time-variant (it can vary over time) it may be necessary to establish which of its values are subject to the constraint.  In particular, there are many rules that refer to a person's age:  a product (such as insurance) may be limited to persons under some maximum age, whereas public transport tickets are often cheaper for young persons or seniors.  If the product is being purchased in advance, which is relevant:  the age of the person at the time of purchase or their age at the time covered by the insurance or ticket?

  2. A rule may vary over time, e.g., the upper limit imposed by a range rule may change.

  3. Different rules may apply to a transaction (such as a loan application) or arrangement (such as an account) at different stages in the lifecycle of that transaction or arrangement.

  4. If the cardinality of a relationship is "exactly one" or "at most one", does that relationship allow only one for all time (e.g., an order line cannot be transferred from one order to another) or one at a time (e.g., an order line can be updated to refer to a different product but can only refer to one product at a time)?

Time-variant and non-time-variant data items

Most of the rules that we have encountered so far in this series govern data specified in transactions, such as Travel Insurance Applications, Flight Booking Requests, Flight Booking Confirmations, Policy Type Creation Forms, Reward Flight Bookings, or Real Property Transfer Instruments.  Typically such transactions are initiated on user interfaces or web forms, but may be transferred from system to system by way of electronic messages.  Some may even start life on paper forms, but even these will be captured by a system via user interfaces or web forms.  A common feature of transactions is that, although a user may modify the content prior to final submission, the transaction is essentially invariant once submitted.  If update after submission is permitted, this can only be achieved by storing the transaction as persistent data that is then retrieved for update. Note, however, that a transaction can include a reference to a time-variant data item such as a person's age.

Other rules in this series govern persistent data, such as records of Parties Covered, Land Titles, Insurance Products, Insurance Product Versions, or Insurance Product Base Premium Versions.  Most persistent data can vary over time as a result of update.

Finally, a few of the rules in this series have specified required conditions in the physical world, such as comparisons between Landing Distances Required of Aircraft and Lengths of Runways on which those aircraft might land.  Such properties of physical objects may also vary over time:  aircraft may be upgraded, and runways may be extended.

Rules governing time-variant data items:  ages and birth dates

A person's age is obviously time-variant, which is why it may be better for an organisation that is interested in a customer's or employee's age to capture that person's birth date rather than their age at some point.  For example, an insurance company may limit travel insurance cover to passengers below some maximum age; if it does, it must be clear about when that maximum age applies.  Will the policy cover a passenger who is below the maximum age on the day that insurance is taken out but who reaches the maximum age during the period of travel?

RS99. The Age specified for each Passenger in each Travel Insurance Application
must be less than 80 years
     on the Return Date specified in that Travel Insurance Application.

Compare rule statement RS99 with two other rule statements (in a previous article[12]) that were intended to state the same business rule:

RS56. The Age specified for each Passenger in each Travel Insurance Application
must be less than 80 years.
RS63. The Birth Date specified for each Passenger in each Travel Insurance Application
must be later than 80 years before the Return Date
     specified in that Travel Insurance Application.

Note that RS56 is a less prescriptive form of RS99 in that it lacks the qualifying clause that states the requirement that each passenger still be less than 80 years old on the final day of travel.  By contrast, RS63 (which governs the non-time-variant data item Birth Date) does not have to include any qualification.  Interestingly, most travel insurance websites request passenger ages (rather than birth dates); however, since none that I have so far encountered includes any qualification as to whether you should enter passenger ages at the time of application or at the time of travel, a 79-year-old passenger can be covered even though they turn 80 before travelling.

This suggests that, rather than simply requesting passenger ages, such websites should explicitly request the ages of all passengers as at the return date.[13]  This in turn suggests an alternative rule statement formulation:

RS100. The Age as at Return Date specified for each Passenger in each Travel Insurance Application
must be less than 80 years.

Time-variant rules

Rules themselves may also change over time.  Consider rule statement RS67 (reproduced from a previous article):  what if the company decides to change the set of regions (for example, add Middle East or split Europe into Western Europe and Eastern Europe)?

RS67. Each Region (if any) specified in each Travel Insurance Application
must be Africa, Asia, Europe, North America, Oceania or South America.

Of course, we could simply change the rule, either immediately (if appropriate) or on the day on which the change is to come into effect.  An alternative is to make the rule parametric, i.e., rather than stating the regions as literals (as in rule statement RS67), use a suitably-qualified term (as in rule statement RS69 — also reproduced from a previous article).

RS69. Each Region (if any) specified in each Travel Insurance Application
must be one of the Regions recognised by Australian Travel Insurance P/L.

This raises an interesting issue.  Imagine that on 1 May 2013 the company decides that the set of regions is to be changed on 30 June 2013, and on 2 May 2013 an application for travel insurance is received for a journey to take place after 30 June 2013.  Must the regions specified in that travel insurance application belong to the set in force on 2 May 2013 (as specified in RS101) or the set in force after 30 June 2013 (as specified in RS102)?

RS101. Each Region (if any) specified in each Travel Insurance Application
must be one of the Regions recognised by Australian Travel Insurance P/L
    as at the Date on which that Travel Insurance Application is made.
RS102. Each Region (if any) specified in each Travel Insurance Application
must be one of the Regions recognised by Australian Travel Insurance P/L
    as at the Departure Date specified in that Travel Insurance Application.

Rule variance across the lifecycle of a governed transaction or arrangement

Different rules may apply to a transaction (such as a loan application) or arrangement (such as an account) at different stages in the lifecycle of that transaction or arrangement.

For example, the balance of an account may be required to be greater than some minimum value at all times during the life of that account.  If a rule applies at all times, the phrase 'at all times' in the rule statement makes this explicit, e.g.,

RS103. The Balance of each Investment Account
must be at least $5,000
    at all times.

While 'always' is a more succinct alternative to 'at all times', I advise against it as it is used with a specific, different meaning in RuleSpeak®.[14]

If the constraint applies only at a particular time point or during a particular time period, that time point or period should be identified in the rule statement, e.g.,

RS104. The Balance of each Low-Interest Loan Account
must be no more than $5,000
    during the 6 months following the Establishment of that Account.

Some data entry facilities provide users with the ability to save incomplete transactions for eventual completion and submission:  this also requires different rules for the "save incomplete transaction" and "submit complete transaction" processes.  For example, most employee time recording systems allow an employee to save a partial record of a week's work (while awaiting a project code, for example) but require the record to be complete when it is finally submitted.  What we have here is actually two different processes, each subject to different rules.  For example, a submitted timesheet is subject to rule statements RS105 and RS106, but an incomplete saved timesheet is not.

RS105. A Timesheet
may be submitted
only if that Timesheet specifies a Project Code for each Activity.
RS106. A Timesheet
may be submitted
only if the sum of the Activity Durations specified on that Timesheet
    is at least 40 hours.

These are actually process rules rather than data rules, to be discussed in a later article in this series.

The enforcement level concept provides for an alternative approach to this situation.  Rules can be specified that apply to all transactions (in this case, timesheets), but these rules are strictly enforced only when a timesheet is submitted, and less rigorously enforced (e.g., with a warning message) if a timesheet is only being saved.

RS107. Each Timesheet
must specify a Project Code for each Activity.
RS108. The sum of the Activity Durations recorded on each Timesheet
must be at least 40 hours.

The impact on rule statement patterns

To allow for temporal qualifying clauses to be included in range rule statements (as in RS99, RS103, and RS104) and value set rule statements (as in RS101 and RS102), the rule statement patterns for these types of rule statement need to be enhanced:

P13.  <range rule statement> ::=
{Each | The} <data item term> {(if any) |}
    specified
    {for {the | each} <complex data item term> {(if any) |} |}
    {in | on} each <transaction term>
    {<qualifying clause> |}

must <range predicate> {<temporal qualifying clause> |}
{{if | unless} <conditional clause> |}.
P17.  <value set rule statement> ::=
{Each | The} {<data item term> {(if any) |} |
combination of <item combination list>}
    specified
    {for {the | each} <complex data item term> {(if any) |} |}
    {in | on} each <transaction term>
    {<qualifying clause> |}

must <value set predicate> {<temporal qualifying clause> |}
{{if | unless} <conditional clause> |}.

Equality and inequality rules may also occasionally require such qualifications, so we similarly enhance their rule statement pattern:

P19.  <(in)equality rule statement> ::=
{Each | The} <data item term> {(if any) |}
            specified
            {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>
            {<qualifying clause> |}
must <(in)equality predicate> {<temporal qualifying clause> |}
{{if | unless} <conditional clause> |}.

Other data content rule statements (for uniqueness constraints, data consistency rules, or temporal data constraints) are unlikely to require qualification in this way.

Data updatability

In the foregoing discussion I have referred to time-variant and non-time-variant data items.  Rules may be required to govern whether or not particular data items are allowed to vary over time.  For example, there is a difference between relationships that allow only one for all time (e.g., an order line cannot be transferred from one order to another) and those that allow only one at a time (e.g., an order line can be updated to refer to a different product but can only refer to one product at a time).  We shall discuss these in a subsequent article.

To be continued...
The next article in this series will discuss data format rule statements.

References

[1]  The first of which is:  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 1)," Business Rules Journal, Vol.  10, No.  2 (Feb.  2009), URL:  http://www.BRCommunity.com/a2009/b461.html  return to article

[2]  Graham Witt, Writing Effective Business Rules.  Morgan Kaufmann (2012).  return to article

[3]  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/
     The font and colour conventions used in these rule statements 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, these conventions are not used for rule statements that exhibit one or more non-recommended characteristics.  return to article

[4]  Statements of rules that require the presence or absence of a data item and/or place a restriction on the maximum or minimum number of occurrences of a data item.  return to article

[5]  A statement of a rule that places a restriction on the values contained in a data item or set of data items (rather than whether or not they must be present and how many there may or must be).  return to article

[6]  A statement of a rule that requires that the content of a data item be a value within a particular range.  return to article

[7]  A statement of a rule that requires that the content of a data item be (or not be) one of a particular set of values (either a fixed set or a set that may change over time), or that the content of a combination of data items match or not match a corresponding combination in a set of records.  return to article

[8]  A statement of any of the following:

  1. an integrity constraint by which a DBMS ensures that a particular column (or combination of columns) in a table has different values in every row,

  2. in ORM (Object Role Modelling), a constraint in which each instance of a particular object type may participate in no more than one instance of a particular fact type,

  3. a rule that requires that the content of a data item (or combination of data items) be different to that of the corresponding data item(s) in the same or other records or transactions.  return to article

[9]  A statement of a rule that requires that the content of a data item be the same (or different to) as that of some other data item (or some specific value).  return to article

[10]  A statement of a rule that requires the content of multiple data items to be consistent with each other, other than as provided for by a value set rule, range rule, or equality rule.  return to article

[11]  A statement of a rule that constrains one or more temporal data items (dates or times).  return to article

[12]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach: Part 4 — Some Data Content Rules," Business Rules Journal, Vol. 13, No. 10 (October 2012), URL: http://www.BRCommunity.com/a2012/b674.html  return to article

[13]  The wording "as at" is used rather than "on" or "at" to make clear that it qualifies "ages of all passengers" rather than "request".  The alternative wordings "request the ages of all passengers at the return date" or "request the ages of all passengers on the return date" could be interpreted as meaning that the request is made on the return date.  The wording "as on" would be an acceptable alternative.  return to article

[14]  Ronald Ross & Gladys Lam, RuleSpeak Sentence Templates — Developing Rule Statements Using Sentence Patterns.  (2001).  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 10: The Effect of the Time Dimension on Rules" Business Rules Journal Vol. 14, No. 4, (Apr. 2013)
URL: http://www.brcommunity.com/a2013/b697.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

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.