SBVR: N-ary Fact Types and Subtypes — Understandable and Formal

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.

Branch Aachen has a distance to branch Antwerp of 146 kilometers.

Branch Antwerp has a distance to branch Brussels airport of 45 kilometers.

Branch Brussels airport has a distance to branch Cologne of 208 kilometers.

Branch Cologne has a distance to branch Cologne/Bonn airport of 3 kilometers.

Branch Brussels North has a distance to branch Brussels airport of 3 kilometers.

Branch Brussels South has a distance to branch Brussels airport of 4 kilometers.

City branch Aachen has an amount of opening hours per day of 8.

City branch Antwerp has an amount of opening hours per day of 8.

City branch Brussels North has an amount of opening hours per day of 8.

City branch Brussels South has an amount of opening hours per day of 12.

City branch Cologne has an amount of opening hours per day of 12.

Airport branch Brussels airport has a distance of 48 kilometers to the city center of Antwerp.

Airport branch Cologne/Bonn airport has a distance of 10 kilometers to the city center of Cologne.

Airport branch Cologne/Bonn airport has a distance of 12 kilometers to the city center of Bonn.

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

branch1

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

branch2

A {branch2} is a [branch] for which the [distance] from another [branch1] 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. return to article

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

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

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

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

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

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

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

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

# # #

Standard citation for this article:


citations icon
Sjir Nijssen, "SBVR: N-ary Fact Types and Subtypes — Understandable and Formal" Business Rules Journal, Vol. 9, No. 4, (Apr. 2008)
URL: http://www.brcommunity.com/a2008/b412.html

About our Contributor:


Sjir   Nijssen
Sjir Nijssen CTO, PNA

Dr. Sjir Nijssen is CTO at PNA in the Netherlands (www.PNA-Group.nl). Dr. Nijssen started with fact based business modeling in the early seventies, at Control Data’s European headquarters in Brussels. Since then it has been more than his full-time occupation. It was there where NIAM (Natural language Information Analysis Method), a fact based business practice and notation, was conceived. After holding a position as professor of Computer Science for seven years, he founded the company PNA in 1989, exclusively dedicated to delivering business requirements, consulting and educational services fully based on fact orientation. PNA currently employs over 50 people. PNA has been awarded the first accreditation in the Netherlands for a bachelor curriculum entirely based on extended fact orientation, in which all subjects are delivered in fact orientation knowledge format (including fully describing concept definitions, fact types, fact type readings and rules).

Dr. Nijssen can be reached directly at sjir.nijssen@pna-group.nl.

Read All Articles by Sjir Nijssen
Subscribe to the eBRJ Newsletter
CONTRIBUTOR ARCHIVES
SBVR & BPMN as Pillars of Business Engineering
SBVR Diagrams: A Response to an Invitation
SBVR: N-ary Fact Types and Subtypes — Understandable and Formal
Hooray, SBVR has arrived!
SBVR ~ Ground Facts and Fact Types in First-Order Logic
In The Spotlight
 Ronald G. Ross
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.