Writing Natural Language Rule Statements — a Systematic Approach Part 7: Equality Rules, Rule Statement Patterns

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

RS85. The Passenger Name specified on each Boarding Pass presented by a Passenger must be the same as the Name specified on the Passport presented by that Passenger.

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

    1. 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'.

  1. 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'.

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

P1.  <rule statement> ::=
{<definitional rule statement>|<operative rule statement>}
P2.  <operative rule statement> ::=
{<obligation statement>|<prohibition statement>|
  <restricted permission statement>}
P3.  <obligation statement> ::=
{Each|The} <subject>
must <predicate>
{{if|unless|after} <conditional clause>|}.
P4.  <prohibition statement> ::=
{A|An|The} <subject>
must not <predicate>
{{if|unless|after} <conditional clause>|}.[11]
P5.  <restricted permission statement> ::=
{Each|The} <subject>
may <predicate>
only {if|after} <conditional clause>.
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.

P7.  {<mandatory data item rule statement>|
<multiple data rule statement>} ::=
Each <transaction term> {<qualifying clause>|}
must specify
{exactly|at least} <cardinal number> <data item term>
    {for {the|each} <complex data item term> {(if any)|}|}
    {<qualifying clause>|}

{{if|unless} <conditional clause>|}.
P8.  <mandatory option selection rule& statement> ::=
Each <transaction term> {<qualifying clause>|}
must {({if|unless} <conditional clause>)|} specify
    {for {the|each} <complex data item term> {(if any)|}
    whether that <complex data item term>|
    whether {it|<determiner> <data item term>}}
<predicate list>
.
P9.  <mandatory group rule statement> ::=
Each <transaction term> {<qualifying clause>|}
must {({if|unless} <conditional clause>)|} specify
    {for {the|each} <complex data item term> {(if any)|}|}
{{a|an} <data item term> or {a|an} <data item term> but not both|
 {a|an} <data item term>, {a|an} <data item term> or both|
 {at least|exactly} one of the following: <item alternative list>}
.
P10.  <prohibited data rule statement> ::=
{A|An} <transaction term> {<qualifying clause>|}
must not specify
a <data item term>
    {for any  <complex data item term> {(if any)|}|}
    {<qualifying clause>|}

{{if|unless} <conditional clause>|}.
P11.  <maximum cardinality rule statement> ::=
{A|An} <transaction term> {<qualifying clause>|}
must not specify
more than <cardinal number> <data item term>
    {for any one <complex data item term> {(if any)|}|}
    {<qualifying clause>|}

{{if|unless} <conditional clause>|}.
P12.  <dependent cardinality rule statement> ::=
The number of <data item term>
    specified {for {the|each} <complex data item term> {(if any)|}|} in each <transaction term>

must be {equal to|less than|more than}
<data item term> <qualifying clause>

{{if|unless} <conditional clause>|}.
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>
{{if|unless} <conditional clause>|}.
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}}
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>
{{if|unless} <conditional clause>|}.
P18. <value set predicate> ::=
be {<value list>|
{one of the {<data item term>|
combinations of
<item combination list>}}
<qualifying clause>}
P19.  <equality 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 <equality predicate>
{{if|unless} <conditional clause>|}.
P20. <equality predicate> ::=
<equality operator>
{<literal>|
{<offset>|} the <data item term> <qualifying clause>}
P21. <equality operator> ::=
be {the same as|equal to}
P22.  <uniqueness constraint 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 <uniqueness constraint predicate>
{{if|unless} <conditional clause>|}.
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:

P3.  <obligation statement> ::=
{Each|The} <subject>
must
{<predicate> {{if|unless|after} <conditional clause>|}|
{({if|unless|after} <conditional clause>)|} <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  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 as that of some other data item (or some specific value).  return to article

[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).  return to article

[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).  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach Part 7: Equality Rules, Rule Statement Patterns" Business Rules Journal, Vol. 14, No. 1, (Jan. 2013)
URL: http://www.brcommunity.com/a2013/b686.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.