‘Concept Model’ vs. ‘Fact Model’ … Where in the World are the Instances?
In a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use.[1] Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR[2] has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class. Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world. But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world. Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used. In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVR The world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning[3] and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart. What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:- The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”.
- The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”
- A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential.
- Some diagram(s) – although often quite useful.
[1] But not in the underpinning of SBVR in formal logic.
[2] Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
[3] I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
[4] I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.
Tags: concept, concept model, concept model vs. fact model, fact, fact model, fact type, factbase, noun concept, SBVR, verb concept, vs. data model
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
Dave Duggal
| #
Hi Ron,
Enjoyed your post as always.
The problem with the 20th century was the lack of ‘shared understanding’ (ie Context) between systems and between systems and systems.
This was a big intellectual conceit of the system designers, who much like the Deist ‘clockmaker’, thought they could set up a system and just let it run – they just needed to get the model right. This unfortunately did assume one universal version of truth, and it left out the environment and the need for adaptation to context.
The answer is in a system of concepts, which are contextualized at run-time. That provides for the most adaptable and extensible architecture. We’ve done it, works like a charm : )
Best,
Dave
Goto, Shoichi
| #
Hi, Ron,
Thank you for your interesting post which let me know SBVR update.
When having read your book ‘Business Rule Concepts”, I’d confused “Fact Model” with “Concept Model” in OOA(Object Oriented Analysis) context.
Concept Model, which is different from “Conceptual Data Model”, represents business concepts of stakeholder’s mind as entities and relationships, and serves as business vocabulary. Many modelers find SVO relationships at the beginning of Concept Modeling. Fact Model is similar to it, I grasped.
Can I understand that the new SBVR release supports their sameness?
regards,
Ronald G. Ross
| #
Short answer: Don’t know. Anybody else know?