Introduction

It has been said by different experts that "SBVR is a landmark result in the evolution of business rules and business modeling"^[4], "a major breakthrough in productivity in requirements and knowledge management"^[5], "SBVR provides the foundational bridge component that has been missing since computers began to be used in organizations in the 1950s"^[2], "An important threshold … for our industry"^[7], and a "groundbreaking new standard."^[1]

There is nevertheless a lot of work ahead of us before SBVR is in the proximity of becoming as common as using Word.  We have been giving intensive multi-day SBVR training, and in this column I will share with you the experiences of this training.  Persons attending the training almost without exception turn negative on SBVR when they start to read Clauses 8 through 12 of the specification.^[6]  It subsequently takes enormous amounts of energy to demonstrate the many positive aspects of SBVR.  In this column I will describe SBVR in a way that is both tutorial and rigorous — both understandable and formal.  Wasn't that a major goal of SBVR in the first place?

SBVR as presented in the official specification is, in my opinion, much too text oriented.  There are much better ways of describing the core aspects of SBVR, by making consistent use of a diagrammatic framework that helps persons understand the total coherence and see the strong points of SBVR for practical applications.

The CogNIAM Knowledge Triangle

Our experience is that the CogNIAM knowledge triangle is a useful blueprint when introducing SBVR.  The triangle is represented in Figure 1.

Figure 1.  CogNIAM knowledge triangle

This triangle can also be used as a blueprint for a strategy by which maximum efficiency in communication can be achieved.  That strategy is:  always start with the knowledge network that the user is most familiar with.  In the large majority of cases this is the level of ground facts, represented in the notation preferred by the speech community that the communication is intended for.

Use Case EU-Rent 1

EU-Rent is an illustration widely used in the SBVR specification.  I will describe a small use case as a subset of EU-Rent that can be used to introduce unary, binary, and ternary fact types, as well as subtypes.  This is the core of SBVR, in my opinion.  Other aspects will be treated in future columns.

The text for the use case is given below:

"EU-Rent is a (fictitious) car rental company with branches in several countries."^{[6, Annex E]}  For each city branch the amount of opening hours per day is registered.  Customers renting a car from an airport branch often request the distance to a nearby city center from that branch.  For certain airport branches therefore the distance to one or more city centers in the immediate neighborhood is registered.  It is possible to pick up a car at a specific branch and drop off the car at another branch.  For branches used for these kinds of transfers, the distance between those two branches is also registered.

I will assume that most readers of SBVR have a knowledge network at the geographic ground fact level.  For this use case I apply the CogNIAM methodology to specify a concrete and representative example at the level of the ground facts, represented in the preferred notation of our EU-Rent speech community.  The result of applying this procedure to a situation is given in Figure 2.

Figure 2.  Ground facts represented in the preferred notation of the EU-Rent speech community

One of the procedures in the CogNIAM methodology is to have an effective legend as a binary.  The first part of each pair is some element of the representation in the preferred notation of the specific speech community; the second part is its verbalization as expressed in natural language facts.  Hence this can be considered as a prescription for how to specify a legend.  The legend for Figure 2 is given in Table 1.

Table 1.  Legend for the facts represented in Figure 2

	Aachen identifies a specific city.
	Brussels airport identifies a specific airport branch.
	Brussels South identifies a specific city branch.
	The distance between airport branch Brussels airport and the city center of Antwerp is 48 kilometers.
	The distance between airport branch Brussels airport and city branch Cologne is 208 kilometers.
	City branch Cologne has an amount of opening hours of 12 per day.

Verbalize

The first step in verbalizing a graphical or report representation according to the CogNIAM methodology is to express the content as if a business professional is talking to his colleague, while the business analyst writes down the textual representation of the verbalized facts.  In the case of the concrete example of Figure 2, the verbalizable information of a representative selection of the information given in that figure will result in ground facts as shown in Figure 3.

Figure 3.  The result of verbalizing the graphical representation

As there is no space in this column to describe the complete set of steps to develop a validated and verified conceptual schema in SBVR, I will skip over several steps and present the two-part result.  One part is the list of concept definitions, and the other is the related diagrammatic representation of fact types, fact type forms, and rules that is compliant with SBVR.

Part 1:  Concept definitions

The concept definitions are listed in alphabetical order.

airport branch

An {airport branch} is a [branch] that is located near an airport.

airport branch has distance to the city center of city

The {airport branch has distance to the city center of city} indicates the [amount of kilometers] [distance] between [airport branches] and the [city] center of [cities].

amount of kilometers

The {amount of kilometers} is the indication of the number of kilometers.

amount of opening hours

The {amount of opening hours} represents the number of opening hours per day a specific [city branch] has.

branch

A {branch} is a location where customers can rent a car.  It is possible to pick up and drop-off these cars at a {branch}.

branch₁

A {branch₁} is a [branch] for which the [distance] to another [branch₂] will be calculated.

branch₂

A {branch₂} is a [branch] for which the [distance] from another [branch₁] will be calculated.

branch belongs to branch type

A {branch belongs to branch type} is a specialization of [branches].

branch has distance to branch

A {branch has distance to branch} indicates the [distance] between two [branches].

branch name

A {branch name} is the text which identifies a specific [branch] within EU-Rent worldwide.

branch type

A {branch type} identifies a specific {branch type}.  There are two different types of [branches]:  [airport branch] and [city branch].

branch type name

A {branch type name} is the text which identifies a specific [branch type] within EU-Rent worldwide.

city

A {city} is an urban settlement with a particularly important status which differentiates it from a town.

city branch

A {city branch} is a [branch] that is located near a [city].

city branch has amount of opening hours

A {city branch has amount of opening hours} indicates the number of opening hours for a [city branch] per day.

city name

A {city name} is the text which identifies a specific [city].

distance

The {distance} is the [amount of kilometers] measured from one point to another point.

Part 2:  Related Diagrammatic Representations

Figure 4 contains the diagrammatical representation of the relevant fact types, fact type forms, and rules.  In natural language one could say the following:

We are willing to communicate about branches.  Each branch gets a unique identification by using a branch name.  Of every branch we want to know the branch type, to be selected from city or airport.  There is a distance table that includes nearly every pair of branches and the associated distance between them, in kilometers.  Of every city branch the number of opening hours per day is known.  Of some airport branches the distance to one or more nearby city centers is given in kilometers.

Figure 4.  Diagrammatical representation of the relevant fact types, fact type forms, and rules

Using such a diagrammatic representation it is possible to represent, without any problem, fact types of any arity, their associated fact type forms, and the rules.  It is our experience that such a representation is a much more productive communication channel than any textual representation.  I recommend you check this for yourself on your own projects.  In my opinion, it is certainly much better than the diagrammatic representation used in Annex H of the SBVR spec.^[6]

With this diagrammatic representation it is of course possible to present Clause 8.  Clause 8 is at the generic level.  In a future column I will describe the "derivation" of a complete and internally-consistent Clause 8.

Summary

SBVR is a major step forward.  It will become the ABC of business communication.^[9]  SBVR is firmly based on controlled natural language and logic.^[8]  SBVR is also firmly based on fact orientation.  (See [3] for an introduction to fact orientation.)

In the SBVR specification one is invited to come up with more productive SBVR-compliant diagrammatic representations.  The representation in Figure 4 is, as far as this author is concerned, the most productive representation of SBVR.    I invite any reader to come up with improvements on this diagrammatic representation such that the improvement evolution can be continued.

References

[1]  Anderson Healy, Keri, "Special Report on SBVR," Business Rules Journal, Vol. 9, No. 3 (March 2008), ISSN:  1538-6325.

[2]  Chapin, Donald, "SBVR:  What is now Possible and Why?" Business Rules Journal, Vol. 9, No. 3 (March 2008), URL:  http://www.BRCommunity.com/a2008/b407.html

[3]  Halpin, Terry & Tony Morgan, Information Modeling and Relational Databases, March 2008, ISBN: 978-0-12-373568-3.

[4]  Hendryx, Stan, "OMG Business Rules Proposal Nears Completion," Business Rules Journal, Vol. 6, No. 2 (Feb. 2005), URL:  http://www.brcommunity.com/a2005/b226.html

[5]  Nijssen, Sjir, "SBVR:  Semantics for Business," Business Rules Journal, Vol. 8, No. 10 (Oct. 2007), URL:  http://www.BRCommunity.com/a2007/b367.html

[6]  OMG, Semantics of Business Vocabulary and Business Rules (SBVR), v1.0, Object Management Group (Jan. 2008). Available as document 08-01-02 at http://www.omg.org/spec/SBVR/1.0/PDF. 
SBVR 1.0 and supporting files are available at http://www.omg.org/spec/SBVR/1.0/

[7]  Ross, Ronald G., "The Emergence of SBVR and the True Meaning of 'Semantics':  Why You Should Care (a Lot!) ~ Part 1," Business Rules Journal, Vol. 9, No. 3 (March 2008), URL:  http://www.BRCommunity.com/a2008/b401.html

[8]  Sowa, John F., "Fads and Fallacies about Logic," IEEE Intelligent Systems, 22:2, pp. 84-87, (March 2007).  URL:  http://www.jfsowa.com/pubs/fflogic.htm

[9]  Vanthienen, Jan, "SBVR:  The ABCs of Accurate Business Communication," Business Rules Journal, Vol. 9, No. 3 (March 2008), URL:  http://www.BRCommunity.com/a2008/b403.html

# # #