SBVR11 — Definition of Vocabulary

In the course of discussion for Issue 13835 (re: "Fact Model"), I discovered what I believe to be a significant problem with the SBVR definition of "vocabulary" in Clause 11. To avoid complicating that original issue, I aim raising the problem here as a new issue. (Aside: I hope this new issue has not been overtaken by events ... it's been a long time since we've had a convenience document.)

Included in this document:
· pp. 1-2 Discussion and proposed resolution for the problem with "vocabulary" plus some additional observations about "terminological dictionary".
· pp. 3 (for convenience only) Mark's response (08:48 AM 6/28/2010) to my e-mail summarizing a resolution on issue 13835. Mark's response caused me to look closely at the SBVR definitions of "terminological dictionary" and "vocabulary".
· pp.4-7 (for convenience only) My original e-mail summarizing a resolution for issue 13835 (06/25/2010 07:54 PM).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DISCUSSION:

The current definition of "vocabulary" in SBVR reads as follows: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings

As far as I see, the definition says nothing directly or indirectly about definitions. This is inconsistent with (a) ISO, (b) MWUD, and (c) How real-world business people think of a "vocabulary". In these important ways, I believe the current SBVR definition is broken and needs to be fixed.

(a) ISO says (1087):

3.7.2 vocabulary
terminological dictionary (3.7.1) which contains designations (3.4.1) and definitions (3.3.1) from one or more specific subject fields (3.1.2)
NOTE The vocabulary may be monolingual, bilingual or multilingual.

RGR: Note the "and definitions (3.3.1)". We always based terms on ISO when we can - especially terms from their area of expertise.

(b) MWUD says:

1 : a list or collection of words or of words and phrases usually alphabetically arranged and explained or defined;

RGR: Note the "and explained or defined". This is the first and most common real-world meaning of "vocabulary".

(c) When business hear or say "vocabulary" they don't think simply of a list of words, they think of what the words mean. The words are of little use by themselves without definitions. Clause 11, the business-facing side of SBVR, must cater to commonly accepted usage of terms in the real-world.

PROPOSED RESOLUTION:

Change the definition of "vocabulary" in SBVR to be: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings and the definitions for those concepts

Also add: Source: based on ISO 1087-1 English (3.7.1) [vocabulary]

~~~~~~~~~~~~~

ADDITIONAL DISCUSSION

Re: "terminological dictionary"

Here is ISO's definition (expanded) ...

3.7.1 terminological dictionary
technical dictionary
collection of terminological entries (3.8.2) presenting information related to concepts (3.2.1) or designations (3.4.1) from one or more specific subject fields (3.1.2)

3.8.2 terminological entry
part of a terminological data collection (ISO 1087-2:2000, 2.21) which contains the terminological data (3.8.1) related to one concept (3.2.1)
NOTE Adapted from ISO 1087-2:2000.

3.8.1 terminological data
data related to concepts (3.2.1) or their designations (3.4.1)
NOTE The more common terminological data include entry term (3.8.4), definition (3.3.1), note (3.8.5), grammatical label (3.8.6), subject label (3.8.7), language identifier (3.8.8), country identifier (3.8.9) and source identifier (3.8.10).

RGR: The bottom line is that for ISO, "terminological dictionary" seems to be simply a more complete, formally organized version of a vocabulary. Both are listed along with other terms under the heading: 3.7 Terminological products.

I believe there is no reason not to stick as close as possible to the ISO sense of this term too. Otherwise, I question its usefulness for SBVR.

At 08:48 AM 6/28/2010, Mark H Linehan wrote:

Ron,

On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ".

(On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".)
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 784-7002 or IBM tieline 863-7002
internet: mlinehan@us.ibm.com

06/25/2010 07:54 PM
To: sbvr-rtf@omg.org
From: "Ronald G. Ross" <rross@BRSolutions.com>
Subject: [issue 13835 - "Fact Model"] Re: issue 13139 comments

All,

While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome.

1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11?

2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is positioning the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering, such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself.

3. It is increasingly clear that the missing concept should be one that distinguishes the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community.

4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly.

5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ...

• have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations").
• thereafter, include any extensions to that necessary set of concepts based evolving business needs.
• primarily include elementary fact types.

An ABC would not include ...

• any deontic elements of guidance whatsoever.
• any ground facts you couldn't specify in advance of "day one of business operations".

6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following:

conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world

"Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...".

7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following:

fact model FL
Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)

"Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.)

8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following:

body of shared meanings
Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community

"Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.)

body of shared concepts
Definition: all of the concepts within a body of shared meanings

"Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.)

9. What can ABC be called? ISO has the term "concept system".

3.2.11 concept system
system of concepts
set of concepts (3.2.1) structured according to the relations among them

"Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition.

Possible objections:

• The ISO definition doesn't seem friendly to unary fact types (" ... relations among them").
• It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts. (It's is not clear to me whether this is so.)

10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC?

"verbal model" or "verbalization model" -

A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose.

MWUD
["verbal"]: 2 a : of or relating to words : consisting in or having to do with words
["verbalize"]: 2 : to state something in words : make a verbal statement

Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms.

"structured business vocabulary" -

Clearly, that's what SBVR itself is – SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is structured (i.e., has verb concepts, etc.).

Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard).

The current definition of "vocabulary" in SBVR is:

vocabulary
Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings

"Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.).

Add the following Note to the entry for "vocabulary":
Note: Enumerating the designations in a vocabulary is not a matter of listing signifiers, but of associating signifiers with concepts, and a concept can be identified by a definition.