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 (see the "Language Archives" sidebar) we looked at a variety of data cardinality rule statements,^[4] and three types of data content rule statement,^[5] namely range rule statements,^[6] value set rule statements,^[7] and uniqueness constraint statements.^[8]  In this article we shall look at another type of data content rule statement, the equality rule statement.^[9]  Between them these rule statement types constitute the vast majority of data validation rule statements.

We have also established a common formulation for each rule statement type in a relatively informal way.  It is now appropriate to analyse these formulations in terms of rule statement patterns.

Erratum

In Part 3 of this series, an error crept into the common formulation for dependent cardinality rule statements, in the form of item 6 in the list of statement elements — this item should be deleted.

Equality Rules

There are situations in which the content of a data item must match that of some other data item.  These situations frequently arise when there is a requirement to authenticate a person by way of documentation tendered, e.g., the name on a boarding pass presented by a passenger must match the name on their passport or other photo ID (as specified in rule statement RS85).

In fact, other data items on a boarding pass presented by a passenger at a gate must have specific values:

1. The flight number must match the flight number of the flight departing from that gate within half an hour of that time.
   
   
2. The date on the boarding pass must be the date on which the check of that boarding pass takes place (or that of the next day if the departure time of the flight is between midnight and 0030).

Another common matching requirement is that a password supplied by someone wishing to access a system must match the password recorded against the username supplied by that person.

Like other types of rule statement, equality rule statements have a common formulation:

1. the subject, identifying the governed data item, such as The Passenger Name
   
   
2. specified
   
   
3. if the governed data item is part of a complex data item, a phrase having the following form:
   
   
1. for the (if there can only be one of the complex data item) or for each (if there can be more than one of the complex data item)
   
   
2. the name of the complex data item
   
   
3. (if any) if the complex data item is optional
   
   
4. a qualifying clause identifying the type of transaction, in this case on each Boarding Pass presented by a Passenger
   
   
5. must, followed by an equality predicate.

Equality Predicates

These also have a common formulation:

1. an equality operator:
   
   
1. be the same as
   
   
2. alternatively, where the governed data item is a simple numeric value (but not a date), be equal to
   
   
2. either:
   
   
1. the name of the governing data item (the data item which the governed data item must match), in this case Name:
   
   
1. preceded by the (optionally preceded in turn by an optional offset — such as 80 years before) and
   
   
2. followed by a qualifying clause (always present so as to relate the governed and governing data items) — in this case specified on the Passport presented by that Passenger

or

2. a literal, such as 80 years or $500.

Rule Statement Patterns

The SBVR makes a distinction between:

1. definitional or structural rules (rules that cannot be contravened) and
   
   
2. behavioural or operative rules (rules that can be contravened, and that prompt appropriate action when contravened).

All rule statements so far in this series of articles have been statements of operative rules.  The SBVR defines three broad types of operative rule statements:

1. An obligation statement expresses an obligation, typically one that obliges:
   
   
1. data of some kind to be present or to have valid content
   
   
2. a process to occur or to behave in a particular manner
   
   
3. a person to have a particular attribute, to perform a particular action, or to behave in a particular manner, or
   
   
4. a thing to be present or to be in a particular state.

There are various approaches to the standard expression of obligation statements.  In the constrained natural language described in these articles, as in RuleSpeak,^[10] all obligation statements include the word 'must' without an immediately following 'not'.

2. A prohibition statement expresses a prohibition, typically one that prohibits:
   
   
1. the presence of, or invalid content in, data of some kind
   
   
2. the occurrence of, or particular behaviour by, a process
   
   
3. a particular attribute or action of, or a particular behaviour by, a person, or
   
   
4. the presence of, or a particular state of, a thing.

Again, there are various approaches to the standard expression of prohibition statements.  In these articles, again as in RuleSpeak, all prohibition statements include the words 'must not'.

3. A restricted permission statement allows a situation to exist only if a particular condition applies, typically:
   
   
1. data of some kind may be present or absent, or may have particular values, only if a particular condition applies,
   
   
2. a process may occur or fail to occur, or may behave in a particular manner, only if a particular condition applies,
   
   
3. a person may have (or not have) a particular attribute, may perform a particular action, or may behave in a particular manner, only if a particular condition applies, or
   
   
4. a thing may be present or absent, or may be in a particular state, only if a particular condition applies.

Again, there are various approaches to the standard expression of restricted permission statements.  In these articles, again as in RuleSpeak, all restricted permission statements include the word 'may' followed eventually by the word 'only' immediately before the clause expressing the condition.

We have therefore established both some general categories of rule statements and patterns (or templates) for particular types of rule statement:

P6.	<subject> ::= {<term>|combination of <item combination list>|set of <plural term>}{<qualifying clause>|}

and so on.

In these pattern definitions:

1. Each item enclosed in the symbols '<' and '>' is a placeholder.
   
   
2. The placeholder or placeholders to the left of the symbol '::=' in each pattern definition statement denote the object type(s) — rule statement types or constituents — being defined.
   
   
3. Each placeholder to the right of the symbol '::=' in each pattern definition statement provides for the substitution of any suitable text.  For example, pattern P6 allows for any of the following to be substituted in place of <subject> in patterns P3, P4 or P5:
   
   
1. a term, e.g., Travel Insurance Application
   
   
2. a term followed by a qualifying clause, e.g., Travel Insurance Application that is for international travel
   
   
3. a reference to a combination of items, e.g., combination of Departure Date and Return Date, with or without a qualifying clause
   
   
4. a reference to a set of items, e.g., set of Passengers, with or without a qualifying clause.
   
   
4. Each pair of braces ('{' and '}') encloses a set of options (separated from each other by the bar symbol '|'), one of which is included in the rule statement.  For example, each rule statement conforming to pattern P3 or P5 starts with either 'Each' or 'The'.
   
   
5. If a pair of braces includes a bar symbol immediately before the closing brace, the null option is allowed, i.e., you can if necessary include none of the options at that point in the rule statement.  For example, each rule statement conforming to pattern P3 or P4 may include or omit a conditional clause preceded by 'if', 'unless' or 'after'.
   
   
6. Patterns P3 and P4 also illustrate that sets of options may be nested.

Of course, these patterns allow for considerable variety in rule statement formulation since they allow for any combination of subject and predicate.  Effective rule book management requires (among other things) that rule statements of the same type should have the same syntax (sentence structure).

For this reason we have established a common formulation for each type of rule statement we have encountered so far.  Expressed as rule statement patterns (templates) — and with conditional clauses and other elements added to increase their flexibility — these are as follows.  I've shaded the subject (in yellow) and the predicate (in green) of each pattern to make the underlying structure clearer.

P14.	<range predicate> ::= <range operator> {<literal>| {<offset>|} the <data item term> <qualifying clause>}
P15.	<offset> ::= <literal> {before|after}
P16.	<range operator> ::= be {{no|} {less|more|earlier|later} than| at {least|most|the earliest|the latest}}

P18.	<value set predicate> ::= be {<value list>| {one of the {<data item term>| combinations of <item combination list>}} <qualifying clause>}

P20.	<equality predicate> ::= <equality operator> {<literal>| {<offset>|} the <data item term> <qualifying clause>}
P21.	<equality operator> ::= be {the same as|equal to}

P23.	<uniqueness constraint predicate> ::= be different to {the|any other} {<data item term>| combination of <item combination list>}     specified     {for {that|any other}     <complex data item term>|}     in that <transaction term>

If we look at each of the patterns for complete rule statements of various types, we can see that nearly all the rule statements we have encountered so far are obligation statements.  The two exceptions are prohibited data rule statements and maximum cardinality rule statements, both of which are prohibition statements.

Another point to note is that, in patterns P8 and P9, the optional conditional clause is immediately after must rather than at the end (as in all other patterns).  This is because the placement of a conditional clause after a list of predicates or (possibly qualified) data item terms can yield a statement that is hard to read.  These patterns therefore do not conform to pattern P3 even though they are for obligation statements.  We therefore need to update P3 as follows, to allow the conditional clause to either precede or follow the predicate:

To be continued...
The next article in this series will discuss some further types of data content rule statement.

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  

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

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

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

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

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

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

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

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

[10]  Ronald Ross & Gladys Lam, RuleSpeak Sentence Templates — Developing Rule Statements Using Sentence Patterns (2001) and Ronald Ross, RuleSpeak Sentence Forms — Specifying Natural-Language Business Rules in English (2009).  

[11]  'A', 'An', or 'The' is used rather than 'Each' in this type of rule statement since the use of 'Each' with 'must not' leads to awkward-sounding statements such as '†Each passenger must not smoke.' (the dagger symbol is used to indicate that a rule statement is, for one or more reasons, not recommended).  

# # #