Vocabularies
The terms used to define rule conditions and actions are usually expressed by domain or industry-specific nomenclature. For example, an e-mail user writes rules in terms of messages "received from" and messages "received after," while an insurance business analyst writes rules in terms of "risk factors" and "coverage amount."
Underlying this domain-specific terminology are the technology artifacts (objects, database tables, and XML documents) that implement rule conditions and rule actions. Vocabulariesare designed to bridge the gap between business semantics and implementation.
For example, a data binding for an approval status might point to a certain column in a certain row in a certain database, represented as an SQL query. Instead of inserting this sort of complex representation in a rule, you might instead create a vocabulary definition, associated with that data binding, with a friendly name of "Status." Subsequently you can include "Status" in any number of rules, and the rule engine can retrieve the corresponding data from the table.
A vocabulary is a collection of definitions consisting of friendly names for the facts used in rule conditions and actions. Vocabulary definitions make the rules easier to read, understand, and share by people in a particular business domain.
You can use the Business Rule Composer to define vocabularies that are then placed in the shared rule store. Vocabularies can also be consumed by tool developers responsible for integrating rule authoring into new or existing applications.
Before you can use a vocabulary, it must be stamped with a version and published in your rule store. This is to guarantee that the definitions in the vocabulary will not change, and to preserve referential integrity. This means that any policies that use that particular version of the vocabulary will not fail unexpectedly due to changes in the underlying vocabulary.