“Semantics of Business Vocabulary & Business Rules” Business Rules Team Update OMG Boston June, 2005

“Semantics of Business Vocabulary & Business Rules”

Business Rules Team Update

OMG Boston

June, 2005

OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 2

Agenda

Current Status Changes since March 2005 submission Alignment with other OMG developments Vote for revised submission date


SBVR Current Status

Approx. 400 criticisms and suggestions received, since March submission. Welcomed by BRT – will simplify finalization Approx 80% addressed Of these, about 65% accepted, 10% rejected,

25% discussed/adapted/negotiated Too many loose ends for June submission Aiming for September


Topics

Feedback resolved – examples: Position wrt MDA & other BEIDTF RFPs Formal Logic Alignment with ODM

Feedback still open Linguistic v Logic view

W3C interest – submission & EU-Rent


What will SBVR do?SBVR supports realisation of the ‘Business Rules Mantra’:

Noun Concepts

Define Concepts

Fact TypesAssociate Concepts to Define Fact Types

BusinessRules

Base Business Rules on Fact Types

Vo

cab

ula

ry Develop Vocabularies to represent them(starting with terms for the concepts)

… to describe businesses, not the IT systems that serve them

“Rules are built on Facts. Facts are built on Terms.”

… in language understandable by business people


Overview of SBVR

Sub-communities may use different natural languages

and specialized vocabularies

Community

Concepts (including Fact Types) and Business Rules

Body of Shared Meanings

Representation of Body of Shared Meanings in Business Vocabulary

Business Representation

Abstract formulation of semantics

Semantic Formulation

First-Order Predicate Logic with some (limited)

extensions

Formal Logic

usesshares

structuredas

representedas

underpinsunderpins


Positioning Relative to MDA


A view of a system that focuses on the environment of the system, and the requirements for it. The details of the structure and processing are hidden or as yet undetermined A CIM is sometimes called a domain model. It is specified with a vocabulary that is familiar to the practitioners of the domain in question .

A view of a system that focuses on its operation while hiding the details necessary for a particular platform. It shows that part of the complete specification that does not change from one platform to another.It may be expressed in a general purpose modeling language, or a language specific to the area in which the system will be used..

A view of a system that combines the specifications in the PIM with the details that specify the system uses a particular type of platform.

Model-Driven Architecture (MDA)

Computation-Independent Model

(CIM)

Platform-Independent Model

(PIM)

Platform-Specific Model (PSM)

Three model-based views of a system, with transformations between themNote that this is not a model of a business - but of an information system that supports a business


Business Model / MDA Models

In a business model: “customer” (for example) is a role that people play in interacting

with the business. “a customer” is a person playing that role Business rules are for people; they can be broken and need

enforcement; they are actionable, but not necessarily automatable

In MDA models: “customer” is (usually) an abstraction that models the real-world

customer, such as a class in a UML model or a view defined in a database schema.

In some contexts, the business model view of “customer” does appear, e.g. as the user in a Use Case model

Rules are automatable, and will be enforced automatically in the implemented system


Model Driven Architecture (MDA)

Computation Independent Model

Platform Independent Model

Platform Specific Model

Business Model

Positioning of Business Model






Business Model

Positioning of BEIDTF RFPs

BPDM

OSM

BMM

SBVR

Production Rules


Business Model

SBVR


Separation of Vocabulary?




BPDM

OSM

BMM

Business Rules

Business Vocabulary

Production Rules






Business Model

Common Vocabulary?

Business Process

Organization Structure

Business Motivation

Business Rules

Business Vocabulary

Full support

Partial support

Production Rules


Future Integration

The BEIDTF has approached business modelling by issuing a number of separate RFPs, without any overall architecture This is not a criticism – sometimes it’s the only practicable way to

make progress At some points in the future, the results will have to be integrated

into a coherent whole The Business Motivation Model may provide the basis for an

“umbrella” under which the BEIDTF specifications can be aligned Creating a common business vocabulary specification would be

an important step In the meantime, there are a few “fuzzies” at the edges of SBVR,

where it will have to be aligned with responses to other BEIDTF RFPs The Business Process Definition Metamodel is probably the most

significant


Formal Logic Basis


Formal Logic Basis of SBVR

Documented in an Appendix to the submission, as the “Authoritative Source” In language directed at logicians May be repositioned for final submission

Aligned with “Common Logic” – draft standard 24707, currently being fast-tracked by ISO

Validated with Pat Hayes, consultant to ISO on Common Logic


SBVR Purpose

Captures business facts and business rules that may be expressed either informally or formally.

Business rule expressions are formal only if they are expressed purely in terms of: fact types in the pre-declared schema for the business

domain certain logical/ mathematical operators, quantifiers etc.

Formal rules are transformed into a logical formulation that is used for exchange with other rules-based software tools.

Informal rules may be exchanged as un-interpreted comments.


SBVR Model (1)

Describes a business domain, and is comprised of: a conceptual schema (fact structure) a population of ground facts.

A business domain (universe of discourse) comprises those aspects of the business that are of interest

The schema declares: the relevant fact types (kinds of ground fact, e.g. Employee

works for Department) the relevant business rules (typically constraints or

derivation rules).


Facts

A fact is a proposition taken to be true by the business.

Population facts are restricted to elementary and existential facts.


Structural Business Rules

Constraint: A static constraint imposes a restriction on what fact populations are

possible or permitted, for each fact population taken individually e.g. Each Employee was born on at most one Date.

A dynamic constraint imposes a restriction on transitions between fact populations e.g. a person’s marital status may change from single to married, but not from

divorced to single Derivation:

Either, how a fact type may be derived from one or more other fact types e.g. Person1 is an uncle of Person2 if Person1 is a brother of some Person3

who is a parent of Person2 Or, how a noun concept (object type) may be defined in terms of other object

types and fact types e.g. Each FemaleAustralian is a Person who was born in Country ‘Australia’

and has Gender ‘Female’


What is a Fact?

In SBVR: a proposition taken to be true by the business the business members are prepared to act as if they

believed the proposition is true; their attitude toward the proposition is one of epistemic commitment.

Does not require any special interpretation of logical operators, or use of epistemic or doxastic logic.

Logical connectives (and, or, not, if-then etc.) may be interpreted like truth functional operators (conjunction, disjunction, negation, material implication etc.) in 2-valued classical logic.


Elementary Facts

An elementary fact is a declaration: Either, that an object has a property (e.g. The Country

named ‘Australia’ is large) Or, that one or more objects participate in a relationship

(e.g. The Prime Minister named ‘John Howard’ was born in the Country named ‘Australia’)

where the fact cannot, without information loss, be split into simpler facts with the same objects.

Multiple fact type readings using different predicates, possibly based on different orderings of the individuals, are considered to express the same fact if they mean the same.


Existential Facts

An existential fact is used to simply assert the existence of an individual. E.g. there is a Country that has the CountryCode

‘US’.


Denotation of Individuals

Individuals are typically denoted by definite descriptions. “The President named ‘Mary McAleese’” is treated as

shorthand for “The President who has the PresidentName ‘Mary McAleese’

Proper names may be used if they function as individual constants in the business domain.

Lexical individuals denote themselves (e.g. the country code ‘US’).

Individual constants may also be introduced as abbreviations of definite descriptions.


Open/Closed World Semantics

Closed world semantics: all relevant facts are known (either as base facts or derivable). if a proposition cannot be proved true, it is

assumed to be false - negation by failure, since failure to find a fact implies its negation.

Open world semantics: knowledge may be incomplete: if a proposition and its negation are both absent, it

is unknown whether the proposition is true.


SBVR – Open or Closed?

An SBVR model of any given business domain is restricted to propositions of interest to that domain.

If a proposition is not relevant, it is not included as a fact there, but not assumed to be false; it is simply dismissed from consideration.

For any business domain, there is a finite set of object types and fact types (typed predicates), and any object type or fact type outside this set is simply disregarded.


SBVR – Open or Closed?

It is a practical issue whether knowledge pertaining to the population of a given fact type is complete or not, since this may impact how the business derives other facts (e.g. negations) or how it reacts to query results (e.g. whether to treat “not” as “not the case” or merely “not known to be the case”

For any given schema, the business might have complete knowledge about some parts and incomplete knowledge about other parts.

In practice, a mixture of open and closed world assumptions may apply.

We use the term “local closure” (or “relative closure”) for the application of the closed world assumption to just some parts of the overall schema.


Business Rules

Structural Business Rules: use two alethic modal operators: it is necessary that … it is possible that …

Operative Business Rules: use two deontic modal operators: it is obligatory that … it is permitted that …


Structural Business Rules

Structural business rules (static constraints) are treated as alethic necessities by default, where each state of the fact model corresponds to a possible world

Pragmatically, the rule is understood to apply to all future states of the fact model, until the rule is revoked or changed.

For the model theory, the necessity operator is omitted from the formula. Instead, the rule is merely tagged as a necessity.

For compliance with Common Logic, such formulae can be treated as irregular expressions, with the modal necessity operator treated as an uninterpreted symbol


Normalization

If a modal operator is embedded later in the rule formulation, we try to “normalize” the formula by moving the modal operator to the front, using transformation rules such as

p Oq .. O(p q)


Normalisation Problems

In rare cases, a formula for a business rule might contain an embedded modality that cannot be eliminated by transformation.

For such cases, we could: Retain the modal operator in the rule formulation

and adopt the formal semantics of a particular modal logic.

Moving the embedded operators down to domain-level predicates (e.g. “is necessary”),


Operative Business Rules

If the rule includes exactly one deontic operator, e.g. O (obligation), and this is at the front, then the rule may be formalized as Op, where p is a first-order formula that is tagged as obligatory.

In SBVR, this tag is assigned the informal semantics: it ought to be the case that p (for all future states of the fact

model, until the constraint is revoked or changed) From a model-theoretic perspective, a model is an interpretation

where each non-deontic formula evaluates to true, and the model is classified as: a permitted model if the p in each deontic formula (of the form

Op) evaluates to true otherwise the model is a forbidden model (though still a model).

This approach removes any need to assign a truth value to expressions of the form Op.


Embedded Deontic Modality

A formula for a static business rule might contain an embedded deontic modality that cannot be eliminated by transformation.

The business user can express the rule at a high level using embedded deontic operators

Where possible the formula is transformed to a first-order formula without modalities by replacing the modal operators by predicates at the business domain level.

These predicates (e.g. is forbidden) are treated like any other predicate in the domain, except that: Their names are reserved They are given some basic additional formal semantics to capture the

deontic modal negation rules: it is not obligatory that it is permitted that it is not the case that (~Op P~p); it is not permitted that it is obligatory that it is not the case that (~Pp O~p). These rules entail an exclusion constraint between the predicates is forbidden

and is permitted.


Dynamic Operative Rules

Dynamic constraints apply restrictions on possible transitions between business states: compare one state to the next (e.g. salaries must never

decrease) compare states separated by a given period (e.g. invoices

must be paid within 30 days of being issued) Should be normalized for interchange between

tools: For each Invoice, if that Invoice was issued on Date1 then

it is obligatory that that Invoice is paid on Date2 where Date2 <= Date1 + 30 days

Normalized (moving deontic operator to the front): It is obligatory that each Invoice that was issued on Date1 is paid on Date2 where Date2 <= Date1 + 30 days


Dynamic Constraints - Issues

What rules licensed the normalization? Need an equivalence rule: p Oq .. O(p q).

Capturing the formal semantics in an appropriate logic (e.g. a temporal or dynamic logic). Possibilities include provide a temporal package that may be

imported, in order to provide a first-order logic solution.

adopt a temporal modal logic Final decision deferred


Higher-order Logic

SBVR can be used with: first-order logic higher-order logic restricted to Henkin semantics

Decision to use higher-order logic affects: categorization schemes un-normalized structures crossing levels/metalevels within the same model.


Henkin Semantics

Restricts quantifiers to range over only individuals and those predicates/functions that are specified in the Body of Shared Meanings, where the n-ary predicates/functions (n > 0) range over a fixed set of n-ary relations/operations.

Retains some first-order properties (e.g. completeness, compactness) that are lost in the standard interpretation of higher-order logic.


Common Logic (ISO 24707)

Common Logic: adopts the Henkin restriction on quantifier ranges does not adopt the comprehension axiom: for

each property there exists a set of elements having that property (sometimes expressed as “every formula defines a set”)

is open to extensions that adopt restricted versions of the comprehension axiom.


SBVR and Set Comprehension

SBVR uses set comprehensions to define projections, as a way to specify result sets. E.g. given the fact type Employee(EmpNr) works for

Company(Name), the query “Who works for EU-Rent?” corresponds to the set comprehension:{x:Employee | y:Company; z:CompanyName (x works for y & y has z & z = ‘EU-Rent’)}

SBVR’s use of set comprehension is restricted: Any SBVR expression that defines a set must ultimately be

expressible only in terms of predefined base fact types, which must be either elementary or existential, and some basic logical operators (e.g. &)

SBVR’s “is an instance of” predicate caters for set membership, but is constrained to be irreflexive SBVR’s formation rules do not permit expressions of the form x

x (so avoiding Russell’s paradox)


OMG Ontology Definition Metamodel (ODM)

Alignment with ODM

UML 2.0

RDF Schema

Entity Relationship

OWL

Topic Maps

Common Logic

Met

amo

de

ls g

rou

nd

ed i

n

SBVR

Common Logic

+

Common Logic(ISO 24707)

Formal Logic basis of SBVR

Currently going through ISO “Fast

Track” process


Response to some feedback on

“The SBVR Message”


The SBVR Specification (1)

SBVR specifies a metamodel for defining business vocabularies and business rules one aspect of a business model: others include

business policy, business process, geography and logistics, organization responsibilities

The SVBR metamodel, and specific models produced using it, are MOF/XMI compliant They can be stored and managed in repositories They can be interchanged as XML files

This is the OMG’s major focus, although Business Rule Management is the subject of a separate RFP



SBVR models must be worth interchanging The SVBR “vocabulary and rules for defining

business vocabulary and business rules” has to guide different practitioners, using different methodologies and tools, into producing consistent models It could not be just “everything is a thing” and “thing is

related to thing”, leaving practitioners to invent their own local semantics

Tools and methodologies will be neededThe BRT has addressed this in SBVR

The OMG will leave this to the industry - tool vendors, consultants and trainers



SBVR models must provide a rigorous basis for transformation to MDA-compliant IT specifications

The transformations are unlikely to be fully automated in the foreseeable future Many specification and design choices will need decisions

from both business and technical people Guidance and tools will be needed to support them

The OMG will be concerned with this in the future, when more of its business-oriented specifications

have been delivered and integrated


What could you do with an SBVR model?

If the tools were available: Send it to other parts of your company, or to close partners Store it in your repository, as guidance for your business and:

Manage it over time, as your business vocabulary and rules change

Validate and verify its content Use it as a basis for creating consistent, focused guidance for

different groups of people in your company, business partners, customers, suppliers …

Use it as input (with suitable tool support for transformation) to you IT specifications: Business applications Workflow

Wait for other aspects of business modelling to be realised in SBVR tools


Purpose of Templating

Fact Type templates provide patterns that are frequently encountered in practice Patterns for structures to capture meaning, not the form of

words (although particular methodologies might choose to do that)

They support consistency of methodology: they provide structure for knowledge elicitation they act as a checklist for content even when processes are different, the results are more

likely to be consistent when interchanged – of they were not included

If they were not included, practitioners would have to define equivalent semantics (SBVR is extensible), but would not all do so the same way.


Summary

Formal Logic Basis satisfactorily defined, aligned with ISO Common Logic

ODM alignment agreed in principle About 70 – 80 feedback points to be resolved

Some discussions needed with individuals Wider interest in SBVR– Semantic Web,

OASIS Requesting revised submission date for

Atlanta meeting (August 2005)

Documents

“Semantics of Business Vocabulary & Business Rules” Business Rules Team Update OMG Boston June, 2005