The Semantics of Business Vocabulary and Business Rules (SBVR) standard was introduced in my last posting as a meta-language capable of supporting translation or serving as a common language. But is SBVR a language, a meta-language, a metamodel, an ontology language, a specification, or perhaps something else?  Depending on the context, it could be all of these things. 

If SBVR is used as a common language (refer to my previous post), it’s a language. When used to define the syntax and semantics of other languages, such as Ontology Definition Metamodel (ODM), then it’s a meta-language. As a meta-language, it provides a MOF-compliant metamodel for defining languages, including ontology languages. The Meta-Object Facility (MOF) is a standard metamodeling framework that supports modeling and the design of metadata-driven systems. SBVR is also a specification, which was created by the Object Management Group (OMG) to support:

• Natural language expressions – SBVR is a controlled natural language.
• Formal logic structures – SBVR logic includes first- and higher-order predicate logic, and deontic and alethic modal logic.
• Formal logic structures support business rules. SBVR supports two types of rules: deontic and alethic.  Deontic rules define obligations whereas alethic rules define necessities:
  • Deontic rule example - An employee may have at most one spouse (it’s possible but not permissible to have more than one spouse).
  • Alethic rule example – An employee may have only one birth date (it’s impossible to be born at two different times).

These two types of rules support four rule modalities: obligations and permissions for deontic rules, and necessities and possibilities for alethic rules.

SBVR and conventional business rules are both declarative; i.e. the behavior they specify is grounded in logic, rather than a procedural specification of control flow. In contrast to business rules, SBVR supports higher-level abstractions, which represents a more formal approach for describing complex entities like business enterprises and business processes. Supporting higher-level abstractions merely means that problems can be expressed in a way that's easier to understand and more aligned with the problem space, i.e. the business domain being modeled. 

In contrast to SBVR, conventional business rules and most business rule engines merely regard business rules as atomic units of executable, re-usable business logic specified declaratively.

You may recall from my last post that SBVR offers two key advantages: solutions can now be expressed in natural language. The resulting specifications are executable, which reduces or eliminates translation ambiguities and errors between specifications, models and executable systems. 

One of the grand challenges for most organizations is to figure out how to build a unified technology stack with higher-level layers capable of processing digital content based on its meaning rather than syntax rules. Occupying these higher layers are artifacts of particular interest, including vocabularies, rules, processes and models. A natural language and formal logic foundation provides a platform for exploiting these new types of artifacts. Thus, SBVR is of interest to business and technology managers alike, if for no other reason than to help technologists grasp the higher-level abstractions that technology stacks must support in order to provide increased business value.