A group of experts and practitioners of the business rules approach is working within the Object Management Group (OMG) to produce a metamodel for Business Semantics of Business Rules (BSBR).  The BSBR metamodel is intended to provide for standardized data interfaces and data interchange among tools that collect, organize, analyze, and use business vocabularies and rules.  The metamodel will eventually facilitate various tools from various vendors exchanging vocabularies and rules along with their semantics.

In case anyone is unfamiliar with the term 'metamodel,' a metamodel is a model of how to define models.  For example, a Unified Modeling Language (UML) model of a computer program is just a model, but a model of how to define a UML model is a metamodel.  Similarly, a business vocabulary with a set of business rules is a kind of model of a business, but a model of how to define business vocabularies and rules is a metamodel.  OMG has specifications of several metamodels, each for defining a different kind of model.

OMG metamodels are defined using a subset of UML designated by the OMG Meta Object Facility (MOF) specification.  In order to provide a simpler version of MOF that is more likely to be widely used than the full MOF, OMG has recently defined a subset of MOF called Essential MOF (EMOF).  EMOF provides basic object-oriented capabilities found in programming languages like Java and C#:  classes, attributes, operations, and packages.  EMOF does not include UML associations.  EMOF is being chosen for the BSBR metamodel in order to foster greater use in software than is expected from using the more complicated full MOF.

OMG defines a mapping of metamodels to XML called XML Metadata Interchange (XMI).  The mapping specifies rules for creating an XML schema from a metamodel.  It also specifies rules for representing models compliant with that metamodel as XML documents conforming to the XML schema.  XMI will be used with the BSBR metamodel to define how business vocabularies and business rules are represented in XML.

Unisys is a leader in OMG development of metamodeling and XMI.  Now Unisys is proposing an innovative approach for the BSBR metamodel that will make it substantially different from other OMG metamodels.  Unisys has shown how the BSBR metamodel can generated from a vocabulary used to describe business vocabularies and semantics of business rules.  Each object of each class in the generated metamodel represents an individual fact.  The approach is very different from other OMG metamodels where classes are defined so that each object incorporates numerous facts about something.

A central and distinguishing feature of the Unisys approach is that it starts with a BSBR vocabulary of words and phrases used for defining other vocabularies and for describing business rules.  The vocabulary is defined in terms of itself.  It is itself a business vocabulary because it provides the concepts that business people use when they define their own vocabularies and rules.  It, like many business vocabularies for general subject areas, is meant to be adopted into other vocabularies and to be extended for various business uses.

Unlike the BSBR vocabulary, the BSBR metamodel is intended, not for business people, but for software engineers that build tools for business people.  The metamodel is meant to be includable and extendable in models that address various business domains.  Generation of the metamodel guarantees its consistency and accuracy in representing the concepts of the BSBR vocabulary.

There are two crucial differences between the generated metamodel and other OMG metamodels.

1. It is generated rather than designed.
2. It is fact-oriented rather than subject-based.

The generated metamodel is like other OMG metamodels in being object-oriented and in being based on MOF.  But the metamodel lacks common design optimizations that are based on presumptions of how a metamodel will be used and how it might be extended.  Instead, Unisys carefully chose to generate following a simple pattern that provides maximum extensibility and semantic stability.

Fact-Oriented vs. Subject-Based

The fact-oriented approach used for the generated metamodel puts the granularity of objects at the level of individual facts rather than at the level of things that are subjects of facts.  Each fact is represented by its own object, and not by an attribute of some other object.

In contrast to the fact-oriented approach, a common practice in object-oriented design and in other OMG metamodels is to represent facts using attributes of objects that represent the subjects of the facts.  This approach could be called 'subject-based' because it uses classes and hierarchies of classes along with attributes to represent in one object multiple facts about a subject.

The differences between the fact-oriented approach and a subject-based design are exemplified below for a small part of a work-in-progress BSBR vocabulary that includes the following terms:

symbol	preferred symbol	prohibited symbol
term	name

The four terms other than 'symbol' represent some of the many specific categories of symbol.  The example vocabulary also includes verbs for expressing facts in these forms:

• symbol is for concept
• vocabulary includes symbol
• symbol has signifier

Figure 1 below shows a generated metamodel based on the fact-oriented approach.  As explained above, the fact-oriented approach makes a separate class for each type of fact that can be expressed.  The different types of facts are divided into two kinds, as follows:

• Facts that are classifications of things (classes shown on the left).  One class is for classifying something as a symbol, another for classifying it as a preferred symbol, and so on.  Each of these classes has one attribute for referring to the thing being classified.
• Facts about relationships between things (classes shown on the right).  These classes represent facts about relationships between things, such as the relationship between a symbol and the concept it stands for.  Each of these classes has two or more attributes:  one for each thing involved in the particular type of relationship.

Classes Representing Classification Facts	Classes Representing Relationship Facts

The fact-oriented approach depends on a general class called thing (not shown above).  An object of that class is a reference point for stating facts.  For example, suppose we want to represent that a term has the signifier 'rental car' and that a particular vocabulary includes that term.  This requires an object of the thing class representing the term and objects from three of the classes shown in Figure 2 that all refer to that same thing object, as follows:

• An object of the is term class to indicate that the thing is a term

• An object of the symbol has signifier class to represent that the term has the particular signifier 'rental car'

• An object of the vocabulary includes symbol class to represent that a particular vocabulary includes the term

In contrast to the fact-oriented approach, Figure 2 shows a subject-based approach to metamodeling for the example vocabulary.  This metamodel uses a class, Symbol, with various subclasses for different kinds of symbols and various attributes for information about each symbol.

The subject-based approach creates a metamodel that is much more like a model of an object-oriented program.  It combines information into fewer, more complex classes.  Such a model is great for automated simulation or for the internal design of a software tool.  And it seems easy to understand.  But it is not well suited for a metamodel meant for facilitating business communication.

Why the Fact-Oriented Approach

The subject-based approach is often the best approach to object-oriented design of software systems, but there are many reasons for choosing the fact-oriented approach for the particular purpose of standardizing business-level data interchange.  The most important reasons are these:

1. Fine control over exactly what is communicated
2. Facts about facts
3. Multidimensional categorization
4. Things changing over time
5. Communication for many purposes that cannot be predicted
6. Extensibility and reuse in other vocabularies

Each of these is discussed below.

1. Fine control over exactly what is communicated

A primary reason that a fact-oriented approach is best for a model intended for data interchange at the business level is that people communicate facts.  The fact is the atomic unit of communication.  Controlling what specific facts are expressed in a communication is important with regard to privacy and intellectual property.  Different messages must include different facts about the same subject depending on the purpose of the message and who is receiving it.

With a fact-oriented approach, communicated content is controlled at the level of individual facts.  With the subject-based approach, in contrast, facts are bundled together.  If a provider of information does not have all of the facts for a whole object, default values commonly appear in the content.  Miscommunication results because a receiver cannot tell that a default value was not explicitly given by the sender.

The rules of XMI do not require all details of an object to be shown in an XML document, but the standard MOF programming interface provides only for writing whole objects to XML.  Note that the standard MOF programming interface is the Java Metadata Interface (JSR 40) of the Java Community Process (see www.jcp.org).  Whether communicating using XMI or using objects directly, the fact-oriented approach gives fine control over what is communicated.

2. Facts about facts

The fact-oriented approach allows for facts themselves, any and all of them, to be the subjects of other facts.  A fact is itself a kind of thing and can, therefore, be the subject of other facts.

The subject-based approach takes away this capability.  Based on Figure 2, a symbol is represented by an object of type Symbol.  The fact that a symbol is for a particular concept is not represented by an object but is incorporated into the same object that represents the symbol.  Other objects cannot selectively refer to the fact because it is represented through an attribute rather than by a separate object.  In contrast, the fact-oriented approach shown in Figure 1 makes each fact an object that can be the subject of other facts.

Why would anyone need facts about facts?  At the level of business rules that guide business activities, facts are things of great interest, as the following questions illustrate.

• Which facts are confidential and which are not?
• What facts must be disclosed when negotiating a contract?
• When and how were certain facts disclosed?
• Which facts are expressed in what business documents and in what formal communications?
• Which facts about customers are private as a general rule?
• Which specific private facts has a customer authorized to be shared with whom?
• When did a fact become true?
• What is the source of knowing a specific fact?
• What version of a document states a certain fact?

The issue of having facts about facts came up at Unisys during the design of a versioning model for a MOF-based repository.  Tracking changes in repository versions requires relating versions to individual facts.  The versioning model works with all sorts of MOF-based metamodels and, until now, these metamodels have not been fact-oriented.  Consequently, creating a viable versioning model required significant under-the-covers work in order to keep track of individual facts.  Nonstandard extensions to XMI were invented in order to communicate versioning details.  The need to work under-the-covers rather than through standard MOF interfaces revealed a significant shortcoming of the subject-based approach:  it gives no standard way to represent facts about each of the individual facts represented in a MOF-based repository.

Business users often need to communicate facts about facts.  The fact-oriented approach lets them do this without going under the covers and without going outside of standard XMI-based interchange capabilities.

3. Multidimensional categorization

Business vocabularies, including the BSBR vocabulary for defining vocabularies and rules, include terms for various categories of things.  Categorization occurs in many dimensions.  For example, symbols are categorized by whether or not they are preferred.  Symbols can be separately categorized by whether they are terms, verbs, articles, quantifiers, icons, etc.  (Only one of these categories, term, is shown in the example model.)

The fact-oriented approach encounters no difficulty with things being categorized in many different ways because each classification of something into a category is a separate fact.  For example, to represent that the term 'rental car' is a preferred symbol, there is simply an object of type is preferred symbol.

The subject-based approach falls short in this regard because each MOF object must be an instance of exactly one most specific class.  One of a number of design approaches for working around this shortcoming is to define intersection classes.  An intersection class is a subclass of two or more other classes.  Its purpose is to be the type of an object that is an instance of each of the other classes.  The example in Figure 2 needs intersection classes for several possible combinations:  Preferred Term, Preferred Name, Prohibited Term, and Prohibited Name.  These intersection classes are shown in Figure 3.  This approach quickly becomes impractical when there are many dimensions of categorization because the number of intersection classes grows exponentially.

Various means other than intersection classes have been used under the subject-based approach to address multidimensional categorization:

• Replacing subclasses with an attribute whose type is an enumeration of kinds
• Replacing subclasses with Boolean attributes
• Dividing an object into multiple objects representing different dimensions

Unfortunately, such design choices are based on factors that often change as a model grows or is put to different uses, causing significant disruption.

4. Things changing over time

In a business, things change with time.  To illustrate using the example vocabulary, consider what happens when a symbol becomes a preferred symbol.  With the fact-oriented approach there is no disruption.  A new object of type is preferred symbol is created to represent the new fact.

The subject-based approach fails because MOF does not support an object of one class being transformed into an object of another class.  A Symbol object cannot be transformed into a Preferred Symbol object, so the Symbol object must be deleted and replaced by a Preferred Symbol object.  Due care must be given not only to replicating all attributes but also to the likely impossible task of finding all references to the Symbol object in order to replace each one with a reference to the new Preferred Symbol object.  A simple change becomes a big change, and change management becomes much more complicated.

As with multidimensional categorization, various other design choices are used to cope with things changing over time.  But again, design choices are driven by factors that often change as a model grows or is put to different uses.  Individual requirements to support change are often discovered late when design changes cause substantial disruption.

5. Communication for many purposes that cannot be predicted

Object-oriented models tend to be designed for a particular purpose.  The purpose drives the design such that changes in purpose often lead to substantial redesign.

For example, when a group of experts in a field such as UML modeling work together to define an object-oriented metamodel such as the UML metamodel, much design and redesign results from the various participants' intended uses of the metamodel.  Consider the metamodel design changes occurring in only a minor revision of UML from version 1.3 to 1.4.  A UML 1.3-based XML encoding of a simple UML model of one class with one attribute is invalid with respect to the UML 1.4 XML format.  The diagram of the class and attribute did not change, and the English words that describe the class and attribute did not change, but the metamodel changed.  New requirements cause redesign in each revision of a metamodel.  Many man-years of redesign went into the core parts of UML 2 that concern classes and attributes.

Metamodel changes introduced by redesign cause substantial work for tool vendors.  Vendors often choose to skip compliance for some versions because of time and cost.  This noncompliance disables the intended interchange capabilities between tools from different vendors.

The fact-oriented approach addresses the problem of constant design churn that results from changes in purpose.  The fact-oriented approach is vocabulary-driven.  The words used to state a fact almost always remain valid from one version of a vocabulary to the next, so the generated metamodel and resulting XML format with respect to those words continue to be the same.  New purposes often lead to adding words to a vocabulary for saying things that could not previously be said.  But additions to a vocabulary result only in additions to a generated metamodel, not changes.  The fact-oriented approach leads to a metamodel for business vocabulary and business rules well suited to multiple and unpredicted uses.  The fact-oriented approach provides semantic stability in the face of changing rules and expanding vocabularies so that document contents and queries are not impacted.

6. Extensibility and reuse in other vocabularies

The BSBR vocabulary must support not only defining vocabularies and rules, but it must also be able to be included into other vocabularies and to be extended to meet the variety of needs that arise in managing and using vocabularies and rules.  The BSBR metamodel must be able to be incorporated into other models and extended in step with inclusion and extension of the BSBR vocabulary.

A metamodel is extended by defining additional classes in a separate package.  Those classes can specialize existing classes in the metamodel, but neither attributes nor superclasses can be added to existing classes.

Expansion of business vocabularies introduces new types of facts about things for which concepts are already defined.  It also introduces new concepts without any regard to their being more specific or more general than what is already defined.  The fact-oriented approach imposes no restrictions on extensibility because, unlike the subject-based approach, adding something new does not change anything already in a model.

The fact-oriented approach to generating an EMOF model from a vocabulary works well for vocabularies in any subject area.  This generation is especially important where a subject area vocabulary incorporates and expands the BSBR vocabulary.  The reason is that the EMOF model generated from the subject area vocabulary includes the metamodel elements of the BSBR vocabulary, so any XML document that conforms to the BSBR metamodel XML format is implicitly conformant to the resulting subject area model XML format.  This extensibility is likely to lead to further use of the simple pattern of generation recommended by Unisys and therefore to much more widespread use of EMOF and XMI outside of their current niche in defining OMG metamodels.

It has been suggested that even though a fact-oriented approach is important for models representing business domain vocabularies, it would be reasonable to have an OMG metamodel for business vocabulary and business rules that does not follow the fact-oriented approach.  This suggestion neglects the important requirement that the metamodel must be able to be included in other models generated from business vocabularies and to be expanded by other models representing various business domains.  For such inclusion and extensibility to operate smoothly, it is essential that the metamodel follows the same modeling approach as the domain models.

Some Questions and Answers

Since the fact-oriented approach is new in OMG, questions have naturally arisen.  Answers to some of the most important questions are detailed below.

Can objects defined by fact-oriented models be interrelated with objects defined by subject-based models?

Yes they can, and in both directions.  A fact-oriented model generated from a vocabulary can support facts about things in other models as long as there are terms in the vocabulary for referring to those things.  Conversely, a subject-based model can use the general classes fact and thing as types of properties in order to refer to objects defined by a fact-oriented model.  The ability to interrelate models and to represent facts about things in many kinds of models is strategically important to many vendors, including Unisys.

What about type checking and class hierarchies?

Since all attributes in a fact-oriented model are of type thing, some nonsense facts can be represented.  The fact-oriented approach does not use MOF to check for semantic consistency, but only for consistency in representation of facts.  The subject-based approach uses MOF for a small part of semantic consistency checking concerning types of things in the cases where types are represented by classes.  But fallacies can be expressed using either approach.

Consistency checking of facts with respect to definitions and rules is a large task that is outside the scope of what OMG has requested for standardization.  Differences in consistency checking capabilities are to be expected from different software tools that implement the BSBR metamodel.  Semantic analysis is best kept separate from using MOF for representation for the following reasons:

• A much fuller semantic analysis than MOF provides is generally required.

• Having consistency errors found in two different ways adds unnecessary complexity.

• Separation of semantic analysis from representation is part of what gives the fact-oriented approach its semantic stability.  Class hierarchies produced by the subject-based approach are too prone to design changes.

The generated metamodel accommodates all definitions and rules that are the basis of semantic analysis, including type checking.  But the metamodel does not use MOF for semantic consistency enforcement.

Do the MOF and XMI rules for creating programming interfaces and XML schemas change when using the fact-oriented approach?

No.  MOF and XMI are used without change.  Also, the more complicated features of MOF and XMI are not used, so the BSBR metamodel will be more easily implemented in software tools.

Conclusion

Unisys has proposed a new fact-oriented approach for generating a metamodel for business vocabularies and business rules.  The approach provides important advantages for business-level data interchange.  There are several reasons for choosing this approach.

1. Fine control over exactly what is communicated
2. Facts about facts
3. Multidimensional categorization
4. Things changing over time
5. Communication for many purposes that cannot be predicted
6. Extensibility and reuse in other vocabularies

Like many vendors and other organizations, Unisys is deeply interested in interoperability of modeling tools and in integration of many kinds of models.  These models range from business mission and vision to business vocabulary, rules, and processes; to IT models of components and databases; and to models of system deployment and administration.  Business Blueprints involve many kinds of model artifacts, mostly created using non-Unisys tools.  The Unisys 3D Visible Enterprise tracks critical cause-effect relationships across numerous kinds of models so that Unisys customers can see the results of business decisions before they make them.  The fact-oriented approach is well suited to the Unisys requirements for integration and traceability.

Business people will not see any differences arising from the fact-oriented approach directly.  They will just see improved integration of the tools they use.

But software engineers who build tools involving business vocabularies and business rules will accrue significant advantage from the difference in approach.  The model they use for data interchange will look less like the internal model of the tool they are building and more like the expressions of facts that can be communicated.  Future extensions and changes will require less work for both the engineers and their customers.  These advantages will translate into a significant advance for the industry and open new areas of opportunity for software developers.

# # #