by Ronald G. Ross

How humans 'know' what symbols 'mean' is one of the great questions of science and mysteries of life.  The word for 'knowing what symbols mean' is 'semantics'.^[1]

Over the past several years, the industry has increasingly used "semantics" to describe emerging capabilities of machines (computers).  Fortunately, since we do understand the mechanics of machines, understanding what semantics means for them is much simpler than for the human mind.  Literally, understanding how machines work is not brain science.  (I'll leave the question of whether machines will ever be able to consciously understand anything we talk about as humans to futurists and Hollywood.^[2])

The official debut on December 11, 2007 of the new standard Semantics of Business Vocabulary and Business Rules (SBVR 1.0) proves that business semantics for machines is a solvable problem and viable approach.  Mark that date!  An important threshold was passed for our industry, as I explain later.

What Makes an Approach "Semantic"

The majority of specialists in the field of semantics focus on what symbols denote, rather than what they connote.  So "motherhood and apple pie" means (denotes) literally 'being a mother and a pie made with apples'.  The fact that in North America the phrase also suggests (connotes) 'something everyone can accept as unquestionably good' is not in scope.  This assumption about the 'literalness' of expression makes understanding what "semantics" means for machines a good deal simpler.

I believe there are two fundamental tests for whether a machine is 'doing semantics', the second one significantly harder.  An approach to semantics must start by satisfying these two tests, then be judged on how well it fits into the actual arena of everyday business work.  SBVR excels on all aspects of these criteria.

Test 1.  Can the machine determine that some instance (of something) does or does not fall into some class of things the machine knows about?

For example, if a machine were handed a fruit electronically — and took a megabyte or two out of it (bad pun) — could it determine that the fruit was or was not an apple?  To be as sure as our knowledge allows us to be, what the machine 'knows' about the fruit would have to satisfy all the encoded rules for 'apple-ness'.  Representing such rules is a primary focus of semantic languages, including in particular those proposed for the semantic web.  Clearly, such classification problems can become quite complex and require sophisticated inferences.

Test 2.  Can the machine determine whether or not two expressions mean the same?

At a trivial level, this might simply require determining that two or more symbols denote the same concept.  For example, suppose humans take c-u-s-t-o-m-e-r and c-l-i-e-n-t (and perhaps c-l-i-e-n-t-e in Spanish) to designate the same concept (think synonyms).  If humans specify as much to machines, then the machines will 'know' the meaning denoted by the symbols is the same one, not different.

Far more interesting cases arise when machines are asked to discover equivalence between meanings without being told directly that the equivalence exists.  That requires analysis of relevant rules.  To illustrate, consider the following simple example of two business rule statements on two separate machines.

Rule on Machine 1:  A customer always places at least 1 order.

Rule on Machine 2:  It is necessary that a client place some order.

Let's again assume c-u-s-t-o-m-e-r and c-l-i-e-n-t are specified by some business person or analyst to be synonyms.  In addition, the business person or analyst has already asserted two other ideas:  (1) "order" and (2) customers being able to "place" an order.  For simplicity, let's assume there are no other rules on either machine that might affect the meaning(s).

Through appropriate analysis the two machines can assume that these two sentences (propositions) are 'talking' about exactly the same meaning.  To arrive at that, the machines need to determine that each of the following pairs of words and/or word phrases represents the same fundamental idea in each case.

Rule on Machine 1	Rule on Machine 2
"places"	"place"
"at least 1"	"some"
"always"	"it is necessary that"

What does that determination require?  First, the machines must be able to understand what role each of these ideas plays in forming a complete natural-language sentence^[3].  Second, and even more basic, the machines must determine that the two rule statements are complete sentences.  Once they can do that, everything else follows more or less naturally.  For example, the machines can determine that "places" and "place" as used in the respective sentences are just niceties of English grammar, offering nothing more in terms of meaning.

To perform such analysis of rule-ish sentences, the machines must be privy to important bits of prepackaged semantics.  These bits cover all the roles that things can play in sentences commonly formed to express business rules, that is, each discrete idea in how their semantics can be structured.  You will want to refer to each of those discrete ideas (well maybe not you, but somebody anyway, probably a tool builder), so each idea must be given an appropriate name.  The set of all those names (terms), and of all the representations of what ideas they denote (definitions), forms a vocabulary.

The essence of SBVR then turns out to be a vocabulary — a painfully deep and complete vocabulary covering all the discrete ideas needed to structure the semantics of rule-ish sentences^[4].  Obviously, these prepackaged SBVR semantics are far more extensive than the simple example above suggests — as too is the associated new-found potential for detecting equivalences (and conflicts) in meanings expressed by natural-language business rules^[5].

What Vocabulary Is Visible to Business People and Analysts

Fortunately, business people and analysts will never have to see or even know about the large majority of the SBVR vocabulary.  It is strictly for tool builders and associated logicians and linguists.  However, there are two areas of vocabulary that must be visible to business people and analysts in some way, as follows:

• The SBVR 'surface' vocabulary for building rich, well-structured business vocabularies.  This involves terms such as "category", "property", etc.  — the stuff of fact models.^[6]  This vocabulary is an important part of SBVR.  If you want to develop a business vocabulary, SBVR is the standard for you.^[7]
  
  
• The 'surface' vocabulary and syntax for expressing the rule-ness of sentences.  This involves words and phrases such as the "it is necessary that" that appeared in one of the earlier sample rules.  It is important to note that SBVR does not standardize this rule-ish vocabulary or, indeed, any rule language at all.  I'll have more to say about that momentarily.^[8]  So, you can use RuleSpeak® (that's naturally my own preference^[9]), ORM, or any other conforming rule language.  You can also speak rule-ishly in Spanish, Mandarin, French, or any other natural language.  To be truly business-friendly, how could it be otherwise?!  No Esperanto (or technical language) is ever going to fly in the world-wide business community.  SBVR is truly for real-world business people, the world over.

What Makes SBVR So Unique

An important thing to understand about SBVR is that it does not standardize any language.  I'm sure that will be a common misconception or misrepresentation, if not already.  It's so easy to slip into saying 'the SBVR language'.  But there is no such thing!  In fact, SBVR's languagelessness sets it apart from just about every other standard or computer specification you can think of, whether for semantics or more traditional business computing.

If not a language, then what exactly is SBVR?  Again, SBVR is a vocabulary (or more accurately, a set of inter-related sub-vocabularies) that permits capture of semantics for the kinds of sentences commonly used to express business rules.  That may seem odd at first, but the more you think about it, the more elegant, powerful, and necessary the SBVR approach becomes.

Think about it this way.  If you were to invent a new generalized language to capture and communicate real-world semantics, no matter how good it is, we'd come right back to the traditional paradigm of translating user-speak into computer-speak.  (That means you too, OWL!)  Don't we know better by now?!  Business people and IT professionals alike are painfully familiar with the pitfalls and miscommunications of any approach involving translation from natural language to computer language.  What you really want is simply business-speak, which inevitably moves you as close to natural language as you can possibly get.

As above, SBVR's avoidance of a standardized, one-size-fits-all surface language for business rules is a defining characteristic of its approach.  What about machine-to-machine communication?  Obviously that’s a 'must' in today's pervasively connected world.  Does SBVR offer a language for machines to 'talk' among themselves about things 'semantically'?

SBVR-compliant tools capture the meaning of business vocabularies and rules in 'semantic formulations'.  Technically, these formulations are facts^[10] based on the standardized SBVR concepts, which are defined in excruciating detail in the SBVR specification.  For example:  It is a fact that there is a rule expressed by the sentence "An order must be shipped within 24 hours."  Other bits of the meaning of that sentence are precisely captured by additional facts.  These facts can be communicated between different tools in an XML-based format that is also standardized by SBVR.

Does that format constitute an internal ‘SBVR language’?  Perhaps.  I’ll leave that to computer scientists.^[11]  If so, it’s at a very deep level.  In any case, I would note that SBVR’s style of machine-to-machine communication is highly consistent with human-style communication.  Let me explain.

As above, SBVR-style formulations of semantics are facts.  Facts are propositions — in essence, sentences — taken to be true.  Sentences are how people communicate knowledge "semantically" too.  That's what you (the reader) and I, in a more general sense, are doing this very moment.

Computers, of course, are abjectly illiterate, so they have to be told every last detail (fact) about meaning.  That's SBVR's role, to provide a standard way for software tools to capture the structure of meaning for business rules to the nth degree.  If I had to give that much detail in writing this column, I'd literally have to write volumes.  Fortunately, machines are very, very fast about 'reading volumes'.  Surpassingly dumb, but blistering fast ... and getting even faster all the time.  Ultimately, fast wins over dumb.  Indeed, that's precisely the communication breakthrough SBVR signals for business logic.

Have It Your Way Then

How can I summarize SBVR capabilities?  To be very clear, we are not talking about any Star Trek fantasy technology, where you can say anything you want and be instantly understood by the computer.  And there is much vocabulary work to be done.^[12]

Clearly though, SBVR does pass over a new threshold of expressive power.  How should we characterize it?  Perhaps the first true fifth generation programming language?  Well maybe, except that it's not a language and it's not really so much about programming.  How about new semantic language?  No, not a language.  First declarative approach to specifying business logic?  No, not really.

One thing I'm relatively certain about is that SBVR's languagelessness will come to be seen as a defining characteristic.  So perhaps we can also label it the first true non-translative approach.  A more positive spin on that, the flip side, would be that SBVR heralds a new vocabulary-based denotative or fact-oriented style of expressing and communicating operational business knowledge.

Labels aside, in plain English (take a deep breath), SBVR is the first truly general-purpose, multi-lingual, natural-language-based, business-vocabulary-and-business-rule standard for real business people.  All of you who dislike or grow tired of computer-ese, take heart!  Now you can express operational business knowledge in your own native language, your way, the SBVR way.

References

[1]  Merriam-Webster Unabridged Dictionary defines "semantics" as "a system or theory of meaning."  

[2]  But on a personal note, what's there not to love about movies like 2001:  A Space Odyssey, and more recently, I, Robot?!  

[3]  Predicate, quantification, and modal claim of necessity, respectively.  The article "a" in both rules also represents quantification, but as used here, means "each" rather than "at least one".  

[4]  This vocabulary happens to be in English, but it would not have to be.  

[5]  And other structured natural-language sentences such as questions and answers.  

[6]  This vocabulary again happens to be in English, but does not have to be either.  For an easily digested introduction and explanation of fact modeling, see my handbook Business Rule Concepts, 2nd edition, available through www.BRSolutions.com, Chapters 1 and 4.  

[7]  There are other standards for terminology (e.g., ISO 1087 and 741) — indeed, SBVR builds on them — but these cannot be used to form the richer, sentence-oriented vocabulary needed for expressing business rules.  

[8]  SBVR does, however, detail what kind of rule-ish business statements you can make.  That's all based in modal logic.  Refer to Clause 12 of the SBVR standard.  

[9]  For background, refer to Chapters 8-12 of my 2003 book, Principles of the Business Rule Approach published by Addison-Wesley and to Annex F of the SBVR standard.  RuleSpeak was one of three reference rule languages used in developing the SBVR semantics.  

[10]  I.e., as facts about the semantic formulation of the meaning.  From the introduction to Clause 9 of SBVR.  

[11]  The argument runs as follows (paraphrasing from Mark Linehan, IBM Research):  SBVR provides an interchange format for communicating vocabularies and rules among tools, which may be on different machines.  The interchange format is a representation of an instance of SBVR's semantic formulations.  The interchange format uses XMI and MOF, which are based on Extensible Markup Language (XML).  XML, of course, is a language — an extensible language that allows users to define their own elements.  Thus it can be said that SBVR defines an XML extension language for communicating vocabularies and rules between machines.  

[12]  The SBVR surface vocabulary is currently in English — that must be translated to other natural languages.  In addition, structured syntax for expressing rules in other languages must be developed.  (RuleSpeak, for example, is for English, although Spanish and Dutch versions are well along in development.)