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 earlier articles in this series (see the "Language Archives" sidebar) we have looked at standardised rule statements for various types of operative rules^[4] (data rules,^[5] activity rules,^[6] and party rules^[7]) and definitional rules.^[8]  Each specific 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.

In previous articles^[9] we looked at the syntactic components that may be found in rule statements of all types, namely prepositional phrases,^[10] qualifying clauses,^[11] terms,^[12] and determiners,^[13] verbs,^[14] and conditional clauses.^[15]  In this article we will look at some of the quality criteria that govern rule statements.

Fundamental criteria

Any natural language rule statement must meet a number of criteria, including (but not limited to) the following:

1. Each word or phrase in the rule statement must be correctly spelt in the natural language used by the organisation, e.g., US or Australian English.
   
   
2. The rule statement must form a syntactically correct sentence.

Given the flexibility of any natural language, this gives plenty of scope for expressing the same rule in many different ways, some better than others (and some quite inappropriate).  We therefore need additional quality criteria, which I shall discuss in this article and the next.

Constraining rule statement wording

Any organisation is governed by many rules.  If the various rules of a given type are expressed in different ways, the following are each much more difficult and error-prone:

• establishing whether any two rule statements duplicate each other or (worse) conflict with each other
  
  
• translating (automatically or manually) natural language rule statements into statements in the appropriate programming language, database constraint language, and/or rule engine input language.

For example, each of the following statements is an alternative wording of the same rule:

The constrained natural language described in these articles prescribes a particular pattern for statements of rules governing mandatory data items, namely the pattern exemplified by RS16.  The reasons for choosing this particular pattern are set out in the first article in this series.^[17]

If alternative terms or verbs are allowed, we can still express this one rule differently, e.g.,

To make detection of duplicate or conflicting rule statements (and translation of rule statements) easier, each rule should only be expressed in one way.  To ensure this:

1. There should be a single pattern for each type of rule, as documented in earlier articles in this series.
   
   
2. Preferred terms (e.g., Travel Insurance Application, Departure Date) and verbs (e.g., specify) must be agreed on and documented, as well as the prepositions (e.g., for) used with some verbs.
   
   
3. Each rule statement must use only those preferred terms, verbs, and prepositions.

Constraining rule statement vocabulary

The best way to document agreed terms, verbs, and prepositions is by way of a fact model, which is a collection of:

1. agreed preferred terms, each with an agreed definition
   
   
2. fact types specifying the agreed verbs (and prepositions if required) to be used with terms in rule statements.

For example, if the terms and verb used in RS16 are agreed as the preferred words, fact type FT1 documents this.

FT1.	Travel Insurance Application specifies Departure Date

FT1 is a binary fact type since it connects two terms.  Some binary fact types have a reverse form; the reverse form of FT1 is Departure Date is specified in Travel Insurance Application.  In its reverse form the same fact type clearly supports RS61.

Some more fact types are required to support RS61; FT2 is analogous to FT1.

FT2.	Travel Insurance Application specifies Return Date

It might be tempting to also include fact type FT3.

FT3.	Return Date is later than Departure Date

This is a legitimate approach, but there is an alternative, which I shall discuss shortly.  Let us first look at another rule statement.

This rule statement is supported by FT1, FT4, and FT5 (for which there is no reverse form).

FT4.	Departure Date is later than Date
FT5.	Travel Insurance Application is made on Date

Alternatively, FT3 and FT4 can be recognised as being specific instances of a more general fact type, FT6.  FT6 can replace FT3 and FT4 if FT7 and FT8 are also included.

FT6.	Date is later than Date
FT7.	Return Date is a category of Date
FT8.	Departure Date is a category of Date

Another way of looking at these fact types is that FT3 can be derived from FT6 by substituting:

1. Return Date in place of the first Date in FT6 (allowed because of FT7) and
   
   
2. Departure Date in place of the second Date in FT6 (allowed because of FT8).

Similarly, FT4 can be derived from FT6 by substituting Departure Date in place of the first Date in FT6.

Here are some more rule statements and the fact types that support them.

FT9.	Travel Insurance Application specifies Birth Date for Passenger     (this is a ternary fact type)

FT10.	Travel Insurance Application is for international travel     (this is a unary fact type)
FT11.	Travel Insurance Application specifies Region

FT12.

Travel Insurance Application specifies Travel Duration     (as well as FT2)

FT13.	Flight Booking Confirmation specifies Passenger Name     (reverse form Passenger Name is specified in Flight Booking Confirmation)
FT14.	Flight Booking Request specifies Number of Passengers     (reverse form Number of Passengers is specified in Flight Booking Request)
FT15.	Flight Booking Request gives rise to Flight Booking Confirmation

FT16.	Travel Insurance Application specifies Value for High Value Item     (reverse form Value is specified for High Value Item in Travel Insurance Application)
FT17.	Monetary Amount is more than Monetary Amount
FT18.	Value is a category of Monetary Amount

FT19.	Travel Insurance Application specifies Salutation for Passenger     (reverse form Salutation is specified for Passenger in Travel Insurance Application)
FT20.	Salutation is Name Title
FT21.	Standard lists Name Title     (reverse form Name Title is listed in Standard)
FT22.	AS4590-2006 is an instance of Standard

FT23.	Travel Insurance Application specifies Region     (reverse form Region is specified in Travel Insurance Application)
FT24.	Region is different to Region

FT25.	Passenger Name is specified on Boarding Pass
FT26.	Boarding Pass is presented by Passenger
FT27.	Passenger Name is the same as Name
FT28.	Name is specified on Passport
FT29.	Passport is presented by Passenger

FT30.	Effective Time Period is specified in Insurance Product Version
FT31.	Effective Time Period overlaps Effective Time Period
FT32.	Insurance Product Version is for Insurance Product

FT33.	Region is Region     (a specific instance of the general fact type Object is Object)
FT34.	Region is recognised by Organisation as at Date     (as well as FT5, FT22)
FT35.	Australian Travel Insurance P/L is an instance of Organisation

FT36.	Folder is renamed
FT37.	File is within Folder
FT38.	Folder is open for editing

In the previous article, we saw that some verbs state or question the truth of a proposition.  The verb specify can be used in this manner as in RS22.  In this situation the term Proposition is used as the object of the verb (as in FT39).  This term can then stand for other fact types, such as FT40 – FT42.

FT39.	Flight Booking Request specifies Proposition
FT40.	Flight Booking Request is for a one-way journey
FT41.	Flight Booking Request is for a return journey
FT42.	Flight Booking Request is for a multi-stop journey

To be continued...
In the remaining articles in this series I will look at the other quality criteria that govern 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  

[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]  A rule that states what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  

[5]  A rule that constrains the data included in a transaction (a form or message) or a persistent data set (e.g., a database record).  

[6]  A rule that constrains the operation of one or more business processes or other activities.  

[7]  A rule that makes a distinction between different parties or the roles they play.  

[8]  A rule that defines a construct created or used by an organisation (or the industry within which it operates), or defines a property of such a construct, and which cannot therefore be contravened, by contrast with an operative rule.  

[9]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 26:  Some Common Syntactic Components of Rule Statements," Business Rules Journal, Vol. 15, No. 9 (Sep. 2014), URL:  http://www.BRCommunity.com/a2014/b777.html,
Graham Witt, "Writing Natural Language Rule Statements —a Systematic Approach —Part 27:  Terms and Determiners," Business Rules Journal, Vol. 15, No. 11 (Nov. 2014), URL:  http://www.BRCommunity.com/a2014/b785.html, and
Graham Witt, "Writing Natural Language Rule Statements —a Systematic Approach —Part 28:  Verbs and Conditional Clauses," Business Rules Journal, Vol. 15, No. 12 (Dec. 2014), URL:  http://www.BRCommunity.com/a2014/b790.html  

[10]  A phrase formed from:
    • a preposition, such as for, from, in, of, on, to, or (in the case of a temporal constraint) after, before, during, earlier than, later than
    • an optional determiner, such as a, an, any, each, that, the
    • a term, such as passenger, credit card.  

[11]  A clause used after a term in two ways:
    1. following the subject term of a rule statement, to restrict the scope of that rule statement to a subset of the set of objects signified by that term, rather than the set of all objects signified by that term (e.g., 'for a return journey' in "Each flight booking request for a return journey must specify exactly one return date.")
    2. following any other term in a rule statement, to make a constraint more specific than if the qualifying clause were absent (e.g., 'that is current' in "Each passenger must present a passport that is current.").  

[12]  A noun used to refer to any concept that is of interest to the organisation.  

[13]  A word or phrase used before a noun to provide some information as to which instance (or instances) of the noun's concept are being referred to, such as the, my, this.  

[14]  A word that:
    1. inflects, in that the form after a singular noun, 'he', 'she', or 'it' (e.g., is and specifies) is different to the form after a plural noun or 'they' (are and specify respectively)
    2. has a form (the infinitive) that can follow a modal auxiliary (in particular must and may).  

[15]  A clause in a rule statement generally following if or unless, and consisting of either a single subject and predicate or two or more subject-predicate pairs separated by and or or.  

[16]  Each rule statement example that does not comply with the constrained natural language described in this series of articles is marked with an initial dagger.  

[17]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 1:  Basic Principles," Business Rules Journal, Vol. 13, No. 7 (July 2012), URL:  http://www.BRCommunity.com/a2012/b660.html  

# # #