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.

SBVR clause 8.1.2 defines 'proposition' as 'meaning that is true or false'.
The Date/Time specification, and some SBVR examples, show that some propositions are used for their "content" – the situation that the proposition describes – without regard to their truth value. For example, "Each rental car must be inspected before it is available for rental" uses the proposition 'rental car r is inspected' (for each referent of r) to refer to situation in which the car is inspected, and the proposition 'rental car r is available for rental' to refer to the situation in which the car can be rented. The rule relates these situations without requiring any true/false evaluation of either of them. Further, the situation in which a given rental car is available is only sometimes an actuality; the proposition 'r is available for rental' can be sometimes true and sometimes false in the actual world.
Thus, being true or false is not the most important characteristic of a proposition, and may not be well-defined.

Recommendation: 'proposition' should be defined as: conceptualization of an event, activity, situation or circumstance. Such a definition would be consistent with the idea that it 'corresponds to' a 'state of affairs'. It is also consistent with the idea that true and false are defined in terms of correspondence to an actuality. Those properties would be dependent on the situation that is identified in the proposed definition. This change of definition does not change the intent of the term 'proposition' in any way. It just avoids having the concept depend on having a truth value in usages that don't care. (It may be that the proposed definition needs some additional characteristic to distinguish it from a noun concept that corresponds to events, like 'heart attack'. For example, the proposition must be based on one or more fact types and involve things in fact type roles.)

Define ‘proposition’ more clearly while remaining consistent with the existing concept and structural rules. Add a note pointing out that a proposition is true or false regardless of whether its truth value is known or of interest. Modify the definitions of “is true” and “is false” to be consistent with the definition of proposition. Also, add a note that a proposition is true or false independently of whether the state of affairs to which it corresponds has been or will be actual.
Add “a statement of the proposition” as a reference scheme to ‘proposition’, as there is currently no way to identify a proposition except by creating a semantic formulation of it, and the natural language statement is the most people-oriented way to do it.

Problem Statement: "Quantification" is currently defined in Clause 9.2.6 to be a logical formulation. This usage of the term is counterintuitive for several reasons.
(1) Logical formulations are a way of structuring meaning particular to SBVR.
(2) "Quantification" can be used to mean the 'process' of projecting, rather than the result of projection, as usually preferred in SBVR.
(3) "Quantification" should be included in SBVR under its appropriate real-world meaning.

Resolution:

1. Change each instance of "quantification"" in Clause 9.3 and elsewhere to "quantifying formulae"

2. Inspect every other instance of "quantification" in SBVR to determine whether it refers to "a quantifying formulae" or to the process of quantification ("quantifying ), and adjust accordingly.

3. Add a real-world concept definition for "quantification". (It needs to be determined where in SBVR this entry should be included.)

SBVR is clear that a ‘quantification’ is a kind of logical formulation and uses the term consistently. Since there is no ambiguity within the SBVR specification or no significant likelihood of misinterpreting the SBVR specification based on a different widely-used meaning for the term, making such a wide-spread change is not justified.
Any problems regarding another meaning for “quantification” not being included in SBVR requires a separate Issue stating how the SBVR specification is broken.
Revised Text:
No change.
Disposition: Closed, No Change Required

The value of a comprehensive and coherent SBVR example seems to be generally accepted, but there have been some concerns expressed about the size and complexity of the EU-Rent example (Annex E).
Section E.2.2.1.1 Car Movement is a particular problem. It is presented first in the detail of EU-Rent‘s vocabulary but is quite complex. It introduces the idea of ‘car movement’, a component that is used in two different contexts ­ as part of the definition of a rental, and as part of the definition of a logistical car movement made by a EU-Rent employee.
Annex E could be made more digestible, without substantially changing its content, by:
1) Presenting the sections in a different sequence, with sections that introduce simpler ideas presented earlier.
2) Presenting ‘car movement’ in a simpler form
This issue can be resolved alongside Issue 10628: Align Annex E with the normative text.
To avoid delay in updating the SBVR specification, updating EU-Rent to comply with the SBVR Date-Time Vocabulary is outside the scope of this issue, and will be addressed later.

The updated version of Annex E that is attached implements all the points in the above summary of this Issue. Timing permitted the inclusion of the concepts adopted from the Date-Time Vocabulary by this EU-Rent Example.
This updated Annex E aligns with the normative text and has been validated by the same software that is used to import the normative SBVR Structured English text for SBVR and Date-Time Vocabulary specifications and produce their machine readable files.
The reorganization of Annex E so that the concepts build on each other for easier understanding required much movement of vocabulary entries from one part of the Annex to another. Because of this, it is not feasible to present the updates to Annex E as either typical editing instructions or a change-tracked Word document. The moves all show as deletions from the old spot and insertions in the new spot even if the content is not changed

SBVR says (in clause 8.6.2, as of ballot RTF 1 ballot 5) that "Each proposition corresponds to exactly one state of affairs." For example, the proposition "each driver of a rental is qualified" (as may be embedded within an obligation statement) corresponds to a single state of affairs in which all drivers of a rental are qualified. Per clause 8.1.2, such a proposition is true or is false according to whether the corresponding state of affairs is actual.

This idea is meaningful to logicians but not to business people. Business users of SBVR will not care about a state of affairs in which "all drivers of a rental are qualified". What is meaningful to business users is the actualities that comprise that state of affairs – in this case, whether each driver, taken individually, is qualified. If the overall proposition is false, an immediate question will be, "which driver is not qualified, and why not?"

To support this kind of analysis, SBVR should have a verb concept that relates a proposition to the actualities that make the proposition true or false. The relationship already exists indirectly through the "state of affairs1 includes state of affairs2" verb concept introduced by the disposition of issue 16526. The current issue proposes a direct relationship, built on and consistent with "state of affairs1 includes state of affairs2", that avoids the need for business users to understand the logician's idea of "proposition corresponds to state of affairs".

see pages 27 - 28 of dtc/2013-07-01

Is a 'boolean variable' a proposition? It is defined to be a variable whose referents are truth values, and I have no idea whether it is a 'meaning'.

I believe 'variable' is used in SBVR in the sense of 'formulaic variable' ... but it's not clear from its definition alone. The point needs to be clarified; otherwise, it will only continue to cause problems. We shouldn't have real-world words being used in a special sense in SBVR

The term “boolean variable” is not used in the SBVR specification.
The concept ‘variable’ is clearly defined in Clause 9 and all the kinds of its referents (instances) is made very clear in the Note in the entry for ‘variable’. The concept ‘variable’ is, of course, a meaning, The instances of the concept ‘variable’ are things in the universe of discourse. Propositions are meanings in an SBVR model.
Revised Text:
No change.
Disposition: Closed, No Change Required

"Objectification" is currently defined in Clause 9.2.7 to be a logical formulation. This usage of the term is counterintuitive for several reasons. (1) Logical formulations are a way of structuring meaning particular to SBVR. (2) Objectification can be used to mean the 'process' of objectifying, rather than the result of objectifying, as usually preferred in SBVR.

Resolution:

1. Change each instance of "objectification" in Clause 9.2.7 to "objectifying formulae".

2. Inspect every other instance of "objectification" in SBVR to determine whether it refers to "an objectifying formulae" or to the process of objectification ("objectifying"), and adjust accordingly.

3. Add concepts, definitions, and terms for the three kinds of results from the process of objectification, and if appropriate, a more general concept for the three (probably called objectification).

Note: At least one of these three kinds of objectification, the one pertaining to open variables, should be included Clause 11.1.5. Probably all three should be. "Objectification" (meaning the result of objectifying) is clearly an 'element of structure' in the sense of 'characterization', 'categorization', etc. (albeit more complex).

As per the Issue Summary, the SBVR specification conflates two meanings into one under the signifier “objectification.” This resolution removes the ambiguity and de-conflates the two meanings by adding entries for the second meaning to Clause 11 and making minor adjustments to the related material in the two Annexes. Also, editorial corrections are made to clarify uses of the term ‘objectification’. The changes in the resolution of this Issue are limited to those involving the word “objectification’. Other changes related to “fact type’ and “verb concept’ will be dealt with in another Issue.

SBVR’s explanation of the concept ‘state of affairs’ could be improved by clarifying how states of affairs include or exclude each other. This is relevant to distinguishing involvement (already defined in SBVR) from inclusion. It is also relevant to understanding the relationship between a situation and the circumstances it includes

The only reason for including ‘state of affairs’ as a concept in the SBVR Meaning and Representation Vocabulary is to be able to talk about the referent in the universe of discourse (the universe of organization that uses the SBVR Business Vocabulary) of propositions, verb concepts and some kinds of noun concepts.

States of affairs never go in an SBVR Business Vocabulary or Rulebook or even a database. Meanings (via their representation) that correspond to the states of affairs go into SBVR Business Vocabularies as concepts and propositions.

If relationships between states of affairs in the universe of discourse need to be referenced in an SBVR Business Vocabulary or Rulebook, they are entered as relationships between the propositions that correspond to them using Semantic Formulations. SBVR Clause 9 provides full support for relationships between propositions and for referencing states of affairs via closed logical formulations of the propositions that correspond to them.

There is no need to add direct relationships between states of affairs to SBVR.

Revised Text:
No Change

Disposition: No Change

Problem Statement: "Projection" is currently defined in Clause 9.3 to be a semantic formulation. This usage of the term is counterintuitive for several reasons.
(1) Semantic formulations are a way of structuring meaning particular to SBVR.
(2) "Projection" can be used to mean the 'process' of projecting, rather than the result of projection, as usually preferred in SBVR.
(3) "Projection" should be included in SBVR under its appropriate real-world meaning.

Resolution:

1. Change each instance of "projection" in Clause 9.3 to "projecting formulae"

2. Inspect every other instance of "projection" in SBVR to determine whether it refers to "a projecting formulae" or to the process of projection ("projecting"), and adjust accordingly.

3. Add a real-world concept and definition for "projection" and for "bag" as currently used in "bag projection". (It needs to be determined where in SBVR this entry should be included.)

SBVR is clear that a ‘projection’ is a kind of semantic formulation and uses the term consistently. “Bag projection” has a formal definition in SBVR that is unambiguous as it is. Since there is no ambiguity within the SBVR specification or no significant likelihood of misinterpreting the SBVR specification based on a different widely-used meaning for the term, making such a wide-spread change is not justified.
Any problems regarding another meaning for “projection” not being included in SBVR requires a separate Issue stating how the SBVR specification is broken.
Revised Text:
No change.
Disposition: Closed, No Change Required

Problem Statement:
1. "Aggregation" is currently used on page 47, but as far as I can tell is not defined anywhere. "Aggregation" should be included in SBVR under its real-world (MWUD). meaning. What is it meant to be (real-world sense).
2. For consistency, "Aggregation Formulation" should probably be renamed "Aggregating Formulae". See other issues submitted concerning "objectification" and "nominalization".

Resolution:

1. "Aggregation" should be included in SBVR under its real-world (MWUD) meaning, and included in the appropriate section.

2. Change each instance of "aggregation formulation" in "aggregating formulae".

SBVR is clear that a ‘Aggregation Formulation’ is a kind of logical formulation and uses the term consistently. Also in Clause 9 “aggregation” is used consistently in context in relation to ‘aggregation formulation’. Since there is no ambiguity within the SBVR specification or no significant likelihood of misinterpreting the SBVR specification based on a different widely-used meaning for the term, making such a wide-spread change is not justified.
Any problems regarding another meaning for aggregation not being included in SBVr requires a separate Issue stating how the SBVR specification is broken.
Revised Text:
No change.
Disposition: Closed, No Change Required

Problem Statement: "Nominalization" is currently defined in Clause 9.2.8 to be a logical formulation. This usage of the term is counterintuitive for several reasons.
(1) Logical formulations are a way of structuring meaning particular to SBVR.
(2) "Nominalization" can be used to mean the 'process' of nominalizing, rather than the result of nomalization, as usually preferred in SBVR.
(3) "Nominalization" should be included in SBVR under its real-world (MWUD) meaning.

Resolution:

1. Change each instance of "nominalization" in Clause 9.2.7 and 9.2.8 to "nominalizing formulae".

2. Inspect every other instance of "nominalization" in SBVR to determine whether it refers to "a nominalizing formulae" or to the process of nominalization ("nominalizing"), and adjust accordingly.

***Note: This includes the definition of the critical term "state of affairs" (in the convenience document available as of 8/2011).

3. Add concepts, definitions, and terms for the three kinds of results from the process of nominalization, and if appropriate, a more general concept for the three (probably called nominalization).

Note: It needs to be determined where in SBVR these entries should be included.

SBVR is clear that a ‘nominalization’ is a kind of logical formulation and uses the term consistently. Since there is no ambiguity within the SBVR specification or no significant likelihood of misinterpreting the SBVR specification based on a different widely-used meaning for the term, making such a wide-spread change is not justified.
Revised Text:
No change.
Disposition: Closed, No Change Required

In clause 8.3.4 of SBVR v1.0, the concepts: 'placeholder has starting character position' and 'placeholder uses designation' model the syntax of the non-normative Structured English language described in Annex C of the spec. These may not be properties of the syntax of other vocabulary and rules languages, and are unsuitable for graphical languages.

The abstract syntax of any such language must be that a placeholder is an expression and must be unique within the fact type form. These requirements should be stated in the definition of placeholder. The placeholder expression is a designation for the role that is used only in definitions of the fact type, and its forms and roles.

The idea of its "character position" is meaningless in graphical languages. The idea specified in 'placeholder uses designation' is a language convention that is not consistently used in SBVR and may well be different in other languages. The semantics of that syntactic construct is captured by 'role ranges over object type' in 8.1.1. Any convention for the syntax used by a tool is out of scope for SBVR. Therefore, both of these fact types should be deleted from the normative specification.

The use of a starting character position to locate a placeholder within a fact type form is meaningful only for fact type forms whose expressions are sequences of characters. Business vocabularies are generally defined using such expressions and so are SBVR’s own vocabularies. However, fact types can be represented by expressions that are not sequences of characters. SBVR provides a reference scheme only for placeholders in fact type forms that are sequences of characters. SBVR does not prohibit use of other reference schemes for placeholders, nor does it prohibit nontextual fact type forms.
The text is revised to add clarifying notes regarding textual fact type forms. Also, the definition of ‘placeholder uses designation’ is modified.

The concept in SBVR Clause 8.1.1 defined as:

“concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities”

has as its preferred term the signifier “fact type” This signifier, “fact type,” badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition.

Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept.

In addition, this same signifier, “fact type,” is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification.

Recommended Resolution:

Remove “fact type” as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier “actuality type” as that is what the definition is defining.

The ambiguity referred to in this issue is that 'fact type':
1. is defined in Clause 8 as "concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities"
2. is used in Clause 10 with a different meaning - not formally defined, but used in the text with the meaning 'kind of facts e.g. “Employee works for Department”' (in parentheses in paragraph 3 of 10.1.1.2).

When Terry Halpin was asked recently to clarify the Clause 10 meaning, he responded "A fact type is the set of all possible facts of interest, using "fact" in the sense that I gave you. In logical terms, a fact type corresponds to a set of one or more typed predicates, where I use 'predicate' in a semantic sense, rather than a syntactic sense (i.e. predicate reading)."
In RTF discussion there has been some resistance to removing the signifier 'fact type' from either the SBVR metamodel (Clauses 8, 9, 11, 12, 13) or from Clause 10. If we follow SBVR's own guidance, the signifiers for the two meanings of 'fact type' need disambiguation, such as 'fact type (actualities)' and 'fact type (facts)'.

The resolution is:
1. Remove the ambiguity from the term “fact type” and ‘object type’ (Clause 10: ‘ type of individual’) as currently used in Clause 8 and Clause 10 by distinguishing ‘verb concept’ and ‘fact type’:
a. Remove ambiguity surrounding the difference between the Clause 8 entry currently having the signifier “fact type’ with the Clause 10 concept ‘fact type’:
i. In Clause 8 remove ambiguity surrounding the ‘fact type’ entry.
ii. In Clause 10.1.2.1: create a formal definition of 'fact type'. based on Terry's input (as above); continuing to use 'fact type' as the signifier throughout Clause 10.
b. Remove ambiguity surrounding the difference between the Clause 8 entry currently having the signifier “object type’ with the Clause 10 concept ‘fact type’:
i. In Clause 8: make 'general concept' the primary term and use 'general concept' in place of “object type” as the signifier throughout Clauses 1-9 and 11-13.
ii. In Clause 10.1.2.1: create a formal definition of 'object type'. based on wording in Clause 10.1.1.2 for “type of individual”; continuing to use 'object type' as the signifier throughout Clause 10 in place of “type of individual”.
2. Describe the relationship between ‘verb concept’ in Clause 8 and ‘fact type’ in Clause 10 and between ‘general concept’ in Clause 8 and ‘type of individual’ in Clause 10 at an overview level of detail. Create a spin-off Issue to add a subclause to Subclause 10.1.1 to discuss to an appropriate level of detail all aspects of the relationship between the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 and the formal interpretation in Subclause 10.1.1, as well as removing ambiguity from Clause 10.1.1 by consistent use of terms intension, extension, fact population, and the set of all possible facts..
3. Revise introductory text for Clause 10 and in Subclause 10.1.1.1 to make it clear that Clause 10 is not part of the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12, and has the purpose of providing formal interpretation / semantics for the concepts in SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12.
4. Create a spin-off Issue to correct the existing definitions in Clause 10.1.2.1
5. Update SBVR Scope-related Statements (un-styled use of “fact”)
6. Create a separate spin-off Issue to deal with the point about “defining that Clause 10 ‘fact models’ are by default closed world models”.

In 11.2.1 we have an entry for something termed 'fact type role designation' – its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept.

This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.)

Revise the definition of ‘fact type role designation’ and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added.

Clause 8.7 introduces the idea of set and cardinality in order to support 'at least n' and 'at most n' constraint concepts. 'set' is defined to be an unordered collection of zero or more things. Marking 'set' a formal logic concept "FL" raises the issue of identity of things. Cardinality of a set is defined as "the number of distinct elements in the set, The definition of 'set' should also refer to 'distinct' or 'distinguished' things. The ability to distinguish makes it possible to determine the truth value of 'thing is in set' for an arbitrary thing.

The 'set' entry should probably also include a Note, such as:
Note: The means of distinguishing things as elements of a set is dependent on the kind of thing and the viewpoint taken in constructing each kind of set. Reference schemes may be used in this regard. Where the SBVR specification defines concepts that are 'sets', the defined reference scheme is used to distinguish elements.

The issue of distinguishing elements of a set is complex. The easier solution is the one chosen in clause 10, to define a set as a collection of things “without regard to ordering or repetition”.
The definition of cardinality will be corrected to match the definition of ‘set has cardinality’, and a form of the recommended Note will be added.

In SBVR clause 8.7, the terms 'quantity' and 'number' are marked as "FL", which means that they are formal logic concepts that are defined in Clause 10. The same is true of 'quantity equals quantity' and 'quantity is less than quantity'. Formal logic does not deal with physical quantities – there is a whole science for that. And formal logic per se does not deal with numbers other than non-negative integers. The 'signed integer' concept is part of a specific mathematical theory. There is not, and should not be, any definition of these concepts in Clause 10. The FL marks should be removed.

Further, these concepts should not be part of the Meaning and Representation Vocabulary, although they are useful business concepts that might be appropriate in Clause 11. Nonnegative integer is needed for the 'cardinality' concept; 'positive integer' is used in quantifications. 'Positive integer' is misused to represent an ordinal concept in 'starting character position' and as an identifier convention for instances of 'variable'.

The RTF agrees that ‘quantity’ and ‘number’ are not formal logic concepts. The ‘FL’ designation will be removed.
While these concepts are not used in the normative text, they are used in examples, and there is no particular reason to delete them from the adopted specification. Since the “is less than” and “is equal to” fact types are used in the normative text, and integer inherits these usages, moving the concepts is not a simple matter. So this part of the issue will result in no change.
The use of ‘positive integer’ in ‘starting character position’ will be raised as a separate issue

SBVR Clause 3 identifies ISO 6093 (Representation of numerical values in character strings) as a Normative Reference. SBVR 7.1.2 defines the symbol 'ISO 6093 Number Namespace' as a term for a namespace derived from a clause of ISO 6093. But there is no normative reference to the use of this namespace anywhere.

Clause 8.7 says in a Note (informative) that ISO 6093 defines a set of designations for numbers, but it does not normatively specify that the ISO 6093 vocabulary is included in the SBVR Meaning and Representation Vocabulary. Either clause 7.1.2 or Clause 8.7 should say this normatively (if that is intended).

Clause 13.2.7 refers to ISO 6093 in the (informative) Rationale section. Clause 13.2.7 defines the MOF representation of 'integer' to be the UML Primitive Type integer, but it uses CMOF:Class to represent 'number'. XMI 1.2 defines the exchange representation of CMOF:integer to be that defined for the "integer" type defined in XML Schema Part 2 Datatypes, and XML Schema Part 2 defines that representation directly without reference to ISO 6093. Nothing specifies the representation of instances of class "number".

So, in terms of normative specification of signifiers for 'number', SBVR is not clear, and SBVR uses XML Schema Part 2 Datatypes, not ISO 6093, as the specification of signifiers for 'integer', which is said to be a specialization of 'number'. In practice, both standards specify the same representation for decimal numbers – ISO 6093 NR2 and XML Schema 'decimal' – but they state different rules for interpreting the precision of decimal fractions. The issue is completeness and consistency of the SBVR specification.

Add clarification into the normative part of clause 13.2.7 regarding use of the ISO 6093 Number Namespace to identify numbers. Also, clarify the conformance requirements for an SBVR processor by stating they include the ability to accept the clause 15.3 SBVR exchange documents, which include the XML document that describes the 6093 Number Namespace. This is not a new requirement because it is implicit in an existing requirement.

The following wording was captured as part of the Issue 13716 notes, as part of some wording agreed in a long-ago meeting:

From the meeting discussion notes on this Issue, the wording below was the agreed for the change instruction to Clause 8:

This change has raised some concerns and, since it is not directly a part of the Resolution to Issue 13716, it needs to be its own issue.

Change the wording of the definition of Clause 8 ‘fact type’ to make it absolutely clear that each Clause 8 fact type is a category of the concept ‘actuality’.

11.1.5.1 Kinds of Fact Type

Problem Statement
[Verb concept] templating could be interpreted to mean that SBVR gives templates for fact types, but that is not really the case.
Template or 'templating' fails to accurately convey that the section is simply listing the common business-facing kinds of fact types practitioners would regularly want to define.
Template or 'templating' connotes purpose, but a good name for a concept should indicate only essence.
Proposed Resolution

• A better signifier for the concept meant by verb concept templating should be based on the word structural. Structural is already accepted in SBVR for signifying things related to establishing the meanings of concepts (i.e., definitional matters). Specifically, it has been used in structural rules.
• I used the term "element of structure" in Business Rule Concepts, 3rd Ed (several 1000 copies not distributed). So I would like to see some use of "structural" here.
• Possible signifiers include "structural shape, "structural form", "structural purpose", "structural role" or "structural pattern".

Note

I the interest of moving forward with RTF work, I could live with synonyms for any use of "template" or "templating" in this section.

Resolved by the Resolution of Issue 13716.

Problem:

In clause 14.3, page 193, the example XML is wrong because it relates roles to the objectTypes ranged over using <sbvr:concept1SpecializesConcept2> instead of <sbvr:roleRangesOverObjectType> as required in the remainder of the specification, as shown in the diagram on page 192, and as shown in the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is an editorial error that remains from when the SBVR FTF created the "role ranges over object type" verb concept.

Also, the <sbvr:factType> element should be <sbvr:binaryFactType> and the <sbvr:designation> element should be <sbvr:factSymbol>

On page 192, in the diagram, the box labelled ": fact type" should instead be labelled ": binary fact type", and the box labelled ": designation" (the one that is connected to the text box with "value=appoints") should instead be labelled ": fact symbol".

Proposed Resolution:

Update the diagram on page 192 as follows:

• replace the text in the box labelled ": fact type" with the replacement text ": binary fact type:
• replace the text in the box labelled ": designation" that is connected to the text box with "value=appoints", with the replacement text ": fact symbol"

See this screen shot to identify the boxes that should be updated:

Make these changes to the example XML on page 193:

<sbvr:factType xmi:id="cao-c" role="cao-r1 cao-r2"/> --> <sbvr:binaryFactType xmi:id="cao-c" role="cao-r1 cao-r2"/>
<sbvr:designation xmi:id="appoints" signifier="appoints-t" meaning="cao-c"/> --> <sbvr:factSymbol xmi:id="appoints" signifier="appoints-t" meaning="cao-c"/>
<sbvr:concept1SpecializesConcept2 concept1="cao-r1" concept2="company-c"/> --> <sbvr:RangesOverObjectType role="cao-r1" objectType="company-c"/>
<sbvr:concept1SpecializesConcept2 concept1="cao-r2" concept2="officer-c"/> --> <sbvr:RangesOverObjectType role="cao-r2" objectType="officer-c"/>

The example is revised as proposed. However, the <sbvr:designation> element is not replaced with <sbvr:factSymbol> to avoid introducing a clause 11 concept into the example.

SBVR recognizes the notion of "property" in Clause 11.1.5 in "is-property-of", but never defines the concept directly. This omission should be corrected because "property" is a term used naturally by business people and business analysts. SBVR should own up to any term used commonly in the real world to form concepts and organize vocabulary.

Resolution:

Add the term "property" to Clause 11, defined as:

Property: thing playing a role in a fact wherein the thing is perceived as being closely held by or descriptive of the thing playing the other role in the fact

Dictionary Basis: a quality or trait belonging to a person or thing; [MWUD property]

Necessity: The fact must be for a binary fact type.

Example: In 'George was born on 22 February 1732', '22 Feb 1732' plays the role "birthdate", but "birth date" is a property of the person 'George'. The role has a range (date); the property has an owner (person).

Example: "ceiling" denotes a property of a room and a property of an aircraft, two different properties of two distinct things

An entry defining ‘property’ is needed to avoid misunderstanding and misinterpreting the signifier “property” as it is used in SBVR.
This is especially important because the SBVR meaning of “property” is different from the meaning of “property” and “attribute” is used in UML, E/R and other data/structure models

In clause 9.2.8, on page 71, the first example under "noun concept nominalization" is incomplete. The text says "In this example, ‘petrol’ is a mention of the concept ‘petrol’ which is used in the ‘type’ role of a fact type ‘quantity is of type’. " However, the formulation shown is missing the use of that fact type. Proposed resolution:
Revise the example to read as follows. New/changed text indicated in red.
Example: EU-Rent stores at least 300 kiloliters of petrol.”
In this example, ‘petrol’ is a mention of the concept ‘petrol’ which is used in the ‘type’ role of a fact type ‘quantity is of type’.
The statement is formulated by an at-least-n quantification.
. The minimum cardinality of the quantification is 300.
. The quantification introduces a first variable.
. . The first variable ranges over the concept ‘kiloliter’.
. The quantification scopes over an existential quantification.
. . The existential quantification introduces a second variable.
. . . The second variable ranges over the concept 'type'
. . . The second variable is restricted by a noun concept nominalization.
. . . . The noun concept nominalization binds to the second variable.
. . . . The noun concept nominalization considers a projection.
. . . . . The projection is on a third variable.
. . . . . . The third variable ranges over the concept ‘petrol’.
. . The existential quantification scopes over an atomic formulation.
. . . The atomic formulation is based on the fact type ‘company stores thing’.
. . . . The ‘company’ role is bound to the individual concept ‘EU-Rent’.
. . . . The ‘thing’ role is bound to the first variable.
. The at-least-n quantification is restricted by an atomic formulation.
. . The atomic formulation is based on the fact type 'quantity is of type'
. . . The 'quantity' role is bound to the first variable.
. . . The 'type' role is bound to the second variable.

(an alternate, and perhaps better, formulation would move the existential quantification of 'type' to the start)

Revise the example to read as follows. New/changed text indicated in red.
Example: EU-Rent stores at least 300 kiloliters of petrol.”
In this example, ‘petrol’ is a mention of the concept ‘petrol’ which is used in the ‘type’ role of a fact type ‘quantity is of type’.
The statement is formulated by an at-least-n quantification.
. The minimum cardinality of the quantification is 300.
. The quantification introduces a first variable.
. . The first variable ranges over the concept ‘kiloliter’.
. The quantification scopes over an existential quantification.
. . The existential quantification introduces a second variable.
. . . The second variable ranges over the concept 'type'
. . . The second variable is restricted by a noun concept nominalization.
. . . . The noun concept nominalization binds to the second variable.
. . . . The noun concept nominalization considers a projection.
. . . . . The projection is on a third variable.
. . . . . . The third variable ranges over the concept ‘petrol’.
. . The existential quantification scopes over an atomic formulation.
. . . The atomic formulation is based on the fact type ‘company stores thing’.
. . . . The ‘company’ role is bound to the individual concept ‘EU-Rent’.
. . . . The ‘thing’ role is bound to the first variable.
. The at-least-n quantification is restricted by an atomic formulation.
. . The atomic formulation is based on the fact type 'quantity is of type'
. . . The 'quantity' role is bound to the first variable.
. . . The 'type' role is bound to the second variable.

(an alternate, and perhaps better, formulation would move the existential quantification of 'type' to the start)

The restriction of the definition of “business rule” to include only those rules that “the semantic community can opt to change or discard” is inappropriate.
The SBVR definition of “rule statement” (“a guidance statement that expresses an operative business rule or a structural rule”) excludes those operative rules that are not business rules, for no obviously good reason.

The quoted phrase in the first sentence above is from the Note for 'business rule' rather than its Definition clause.
After discussion it was decided to improve the text of that Note to clarify the relationship between regulation/law ('external' to an organization) and the organization's own business rules:
• In the Note for the 'business rule' entry, add a reference to the Business Motivation Model [BMM], which has more to say about how regulations/laws relate to business rules and add clarifying examples and narrative.
The definition of rule statement needs no change since, by definition, there are no operative rules that are not business rules.

Assortment fact types are not even fact types but facts since they make assertions about instances, “Graham Witt is a man” is of the same ilk as “Graham Witt is a citizen of Australia” (i.e. a fact).

This was corrected in the Resolution of Issue 13716.
Revised Text:
None needed.
Disposition: No Change

One of the example fact types provided in section 11.1.5.2 under “is-role-of fact type” is “rental car plays the role ‘replacement car’ in the fact type ‘breakdown during rental has replacement car’.” with the comment that “An instance of the fact type would be a particular breakdown during a particular rental having a particular replacement car.” I have a few concerns with this:
1. some of the text in this fact type should be in verb style
2. the underlining in ‘replacement car’ should be continuous both times
3. trying to instantiate the fact type produces something like “(The car registered) ’ABC123’ plays the role ‘replacement car’ in the fact type ‘breakdown during rental has replacement car’.” if we assume that underlined strings inside single quotes are not placeholders, while “(The car registered) ’ABC123’ plays the role ‘replacement car’ in the ??? ‘Breakdown #1234 has replacement car’.” is a more reasonable fact, except that a) this involves inconsistent handling of underlined strings inside single quotes, and b) ‘Breakdown #1234 has replacement car’ is neither a fact nor a fact type.
4. from this I deduce that the example seems to be a fact about the model rather than a fact type from which facts about EU-Rent can be generated
5. to support the latter argument, the EU-Rent examples in section E.1.4 has no ‘is-role-of’ fact types but does have ‘related facts’ such as “The noun concept 'return branch' is a role that ranges over the noun concept 'branch.’”.

"Is-role-of fact type" was revised as part of the Resolution of Issue 13716. Discussion of this issue identified some changes needed in the wording of the examples. (Details below.)
For the concerns specifically stated in the issue Summary:
1. This Example applies the conventions used for an Example clause, i.e., verbs do not have any special styling in examples.
2. The underlining was corrected to be continuous.
3. This concept is no longer a kind of fact type so this point is no longer applicable.
4. This concept is now a kind of proposition (fact about the model).
5. The examples in Annex E are being revised to reflect changes made under Issue 13716 (et al).
Note: The title of this issue also mentions "is-category-of fact type" but nothing on this was included in the issue detail. In any case, "is-category-of fact type" was also revised as part of the Resolution of Issue 13716.

Summary:

There are two minor editorial issues regarding the verb concept "closed projection defines noun concept" in clause 9.3

1. In figure 9.12 on page 77 of the adopted specification and on page 79 of the ballot 3 convenience document, the verb concept is shown as "closed projection defines object type", rather than "... noun concept". Any noun concept should be definable this way, not just object types. The text is right and the graphic is wrong.

2. In the Acrobat Reader "Bookmarks" tab of the ballot 3 convenience document, the verb concept is shown as a sub-entry under "logical formulation constrains projection", rather than as a separate entry (as for "closed projection defines fact type". The problem occurs only in the convenience document, not in the formal adopted specification. See attached screen shot.

Suggested Resolution:

1. Change the figure to match the text.
2. Fix the bookmark tab entry.

1. Fix Figure 9.12 as recommended to make the figure consistent with the text.
2. The problem with the bookmark tab entry is not a problem in the adopted specification. However, the problem will be corrected.

Line 58 of the MeaningAndRepresentation-Model.xml file reads as follows:

<ownedMember xmi:type="cmof:Class" name="object type" xmi:id="objectType" superClass="concept"/>

The "superClass" attribute says that an Object Type is a kind of "Concept". This is inconsistent with clause 8.1.1, which defines 'Object Type' as a kind of 'Noun Concept'. This inconsistency causes problems (for example) when populating the "nounConcept=" attribute of the XMI tag <sbvr:closedProjectionDefinesNounConcept> because only a nounConcept can be referenced by this attribute, and an objectType is not a kind of NounConcept.

Proposed resolution:

Change line 58 of the MeaningAndRepresentation-Model.xml file to read:

<ownedMember xmi:type="cmof:Class" name="object type" xmi:id="objectType" superClass="nounConcept"/>
--------------------------------

Correct the XML file to match the normative text

The example fact type in section 11.1.5.1 under “is-property-of fact type” is “engine size is property of car model” yet the examples in Annex E do not have this form. Further if one tries to instantiate this fact type, one gets something like “351 cubic inches is property of Holden Marina” which misses essential information. I believe that ‘is-property-of’ fact types should each have the 2 forms “engine size of car model is cubic measurement”/“car model has engine size of cubic measurement” allowing for instantiations such as “engine size of Holden Marina is 351 cubic inches”/“Holden Marina has engine size of 351 cubic inches”.

"Is-property-of fact type" was revised in the Resolution of Issue 13716.
Specifically, the concept 'property association' (formerly 'is-property-of fact type') now gives these as examples:
Example: the association 'engine size of car model'
Example: the association 'person has eye color'
The concept 'engine size' handles, as needed, appropriate units-of-measure as part of its definition. For example, here is a typical definition of 'engine size':
Engine size: volume swept by all the pistons inside the cylinders of an internal combustion engine in a single movement from top dead centre (TDC) to bottom dead centre (BDC) [Engine size is commonly specified in cubic centimeters (cc), litres (l), or cubic inches (cid).]
Example instances of engine size could be: 61 cid (cubic inches), 151 cid, 351 cid, etc. And an example fact could be "The car model 'Buick' has the engine size '151 cid'." Alternatively, this could be expressed as "The car model 'Buick' has an engine size '2.5 liter'." since '151 cid' and '2.5 liter' are alternative expressions of the same engine size value.
The examples in Annex E are being revised to reflect changes made under Issue 13716 (et al).
Revised Text:
None needed.
Disposition: No Change

Title: What is a fact type form?
Specification: SBVR
Version: 1.0
Source: Ed Barkmeyer, NIST, edbark@nist.gov

Summary:

In SBVR, clause 8.3.4, 'fact type form' has the definition:
"representation of a fact type by a pattern or template of expressions based on the fact type".

According to clause 8.3(.0), 'representation' is "actuality that a given expression represents a given meaning". Is "a pattern or template of expressions" an "expression"? According to 8.2, a 'signifier' is "expression that is a linguistic unit or pattern [of sounds or symbols]". So apparently there are expressions that are patterns and they can be signifiers.

Per 8.3.1, designation is the "representation of a concept by a sign", and a fact type is a concept, so it may have a representation that is a designation. But the UML diagram shows that a fact type form is not a designation. So presumably a 'pattern or template of expressions' is not a 'sign'. But a signifier, which is a pattern, must be a 'sign', because it is the expression that participates in a designation. But the expression of a fact type form is apparently not a signifier, since only designations have a 'signifier' role, and a fact type form is not a designation. The inconsistency in the terminology, and the failure to make clear parallels and distinctions, is very confusing.

It seems that the idea here is that an 'expression' can be a structure of individual sub-expressions, and that, in representing a fact type, the structure and the sub-expressions play distinct roles in the "actuality" of representing the fact type. This means that at least this idea of structured expressions should be described in clause 8.2, as a kind of expression more interesting than "text".

It appears to be the intent that a fact type form expression always has a structure with representation sub-behaviors. Is that what distinguishes a fact-type form from a designation? The text is completely silent as to what the delimiting characteristic is.

The remaining question then is: what kind of representation is exemplified in a terminological entry for a fact type in the SBVR vocabulary itself? E.g., is "designation has signifier" a designation for a fact type or a fact type form for it? (According to the UML diagram it cannot possibly be both.) And if the latter, does an SBVR fact type not actually have a designation? More confusion.

Recommendation:
1. Define the concept that is "pattern or template of expressions" in 8.2
2. Use these structure concepts to define the nature of a fact type form in 8.3.4. For example, a placeholder is a sub-expression.
3. Specify the distinguishing characteristic of a fact-type form that makes it different from a designation.
4. Specify what the vocabulary entries for fact types are: fact-type forms or fact-type designations.

1. A fact type form is a model of some surface syntax that represents the fact type as a set of grammatical elements. As such the details of a fact type form are irrelevant to the intent of SBVR. Thus, the model in SBVR should involve only those “abstract syntax” elements that are common to all such representations.
2. A fact type form is not a designation – it is a grammatically structured expression serving as a pattern for usage of the fact type designation in some language. A designation for a fact type is a term or symbol that has business meaning, is a vocabulary entry, and may occur in a number of different fact type form structures for the fact type. The designation’ signifier can also be a signifier of designations of other fact types. A fact type form is a usage pattern for a language in which definitions, facts and rules are stated. The text will be revised to make this clear.
3. The glossary headings for fact types in SBVR itself are fact type forms. As specified in Annex C, each terminological entry for a fact type gives a designation for the fact type and the concepts that determine the context in which the signifier of that designation represents that fact type. The text will be revised to make this clear.
4. In order to define ‘fact type form’ as a kind of representation, the text will be revised to refer to an expression that involves signifiers for the fact type and its roles. The modeling of expression syntax is out of scope.

A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of facts. Finally, the order of the entries needs adjustment as a result of the above.

The four items being changed from kinds of 'fact type' to kinds of 'fact' ('proposition') under this proposal were always intended to characterize 'fact', but since these are meta-facts (having the appearance of fact types) people mistook them for fact types and wrote them up as such. This proposal corrects that error. In summary, this proposal:
• Makes the necessary changes to correct the entries for assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type from being specified as 'fact type' to 'fact' (kinds of 'proposition').
• Fills a gap in the Scheme by adding two categories that had inadvertantly been left out ('characteristic' and 'characterization').
• Adds a fact type to relate 'facet' to 'concept' (in parallel to what is in place to relate 'role' to 'concept')
• Makes minor styling corrections throughout 11.1.5, in particular in the Examples.

Please see attached Word document for Issue details.

This SBVR spin-off Issue is a part of a package of three proposed Issue resolutions:

• the proposed resolution of this spin-off Issue which will be posted when it has a number;

• the proposed resolution to Issue 12540; and

• the proposed resolution of the 11296-1a / 11303-b spin-off Issue which will be posted when it has a number.

1. Sub-clause 8.5 is, for all practical purposes, disconnected from the rest of Clauses 7, 8, 9, 11 & 12 in that the terms (i.e. conceptual schema, fact model) defined in Sub-clause 8.5 are hardly used at all in Clauses 7, 8, 9, 11 & 12, and none of those uses are styled.

Conversely Clause 10.1.1 “SBVR Formal Grounding Model Interpretation” (as well as the non-normative Annex L: “A Conceptual Overview of SBVR and the NIAM2007 Procedure to Specify a Conceptual Schema”) makes high use of the terms defined Sub-clause 8.5.

The vocabulary entries in Sub-clause 8.5 are moved to the context where they are used normatively i.e. in Clause 10.

2. Clarify that the uses of “conceptual schema” and “fact model” in Clause 2 “Conformance” refer to their use in Clause 13 “SBVR’s Use of MOF and XMI”.

3. Make clear that the uses of “conceptual schema” and “fact model” in Clause 13 “SBVR’s Use of MOF and XMI” are as defined in Sub-clause 10.1.2.1

4. Clarify that the Sub-clause 8.6.2 necessities are about the distinction between what is in the SBVR model and what is the Universe of Discourse of the SBVR Model

The fact type "role ranges over object type " appears in section 8.1.1. As defined – due to the "open world" aspect of SBVR – it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types.

This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types.

Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type".

Add a clarifying note to the entry for ‘role ranges over object type’.

Clause 8.1.1

Concept: individual concept

The Definition of 'individual concept' is:
concept that corresponds to only one object [thing]

The Note says:
"each referring individual concept has exactly one and the same instance in all possible worlds"

"Corresponds to only one object" (in any possible world) is not at all the same thing as "corresponds to exactly one and the same object in all possible worlds". One of the definition and the Note should be corrected. I would prefer changing the definition to match the note.

Note also that changing the definition means that "the President of the United States" is an 'individual concept' that denotes an office, but not a person. And the concept "the person who is President of the United States" is not an 'individual concept'.

Change the definition to match the note

p. 150 (PDF p. 162), Clause 11.2.1.2,
to the entry for 'fact type form incorporates fact symbol':

Add the following caption, to appear after the current Synonymous Form caption:

Synonymous Form: fact type form demonstrates designation

using term styling where underlined (above) and verb styling for italics (above)

Also, on this same page, there is a typo in the Definition caption under the entry for 'fact symbol':

In 'fact type form' (which ends the Definition) the first space needs to be underlined — i.e., apply term styling to the space.

Replace the Definition of the Clause 11 fact type with a See caption. The fact type is a synonymous form for 'fact type form demonstrates designation', and its Definition is therefore redundant.
Also, in the definition of ‘fact symbol’, correct the typo and make the definition fully formal, using 'fact type form demonstrates designation'.

attached is a dcument containing SBVR typos

These SBVR types are all well within the boundary of edit corrections, and therefore no Issue needed to be raised to make these edit fixes.
Revised Text:
None
Disposition: Closed – No Change

SBVR currently has multiple concepts for organizing vocabularies and rules:

• conceptual schema (clause 8.5)
• fact model (8.5)
• body of shared meanings (11.1.1)
• body of shared concepts (11.1.1)
• terminological dictionary (11.1.1)
• vocabulary (11.1.1)
• rulebook (11.2.2.4)

Some issues:
3) A terminological dictionary should be able to incorporate other
terminological dictionaries, as with "vocabulary incorporates vocabulary".
Otherwise, we cannot structure terminological dictionaries in parallel with
vocabularies

In SBVR vocabularies are lists of designations and fact type forms. Vocabularies are packaging containers for SBVR business ontologies that are designed for particular audiences and/or uses. Vocabularies may be assembled from other vocabularies using the fact type vocabulary1 incorporates vocabulary2.
Terminological Dictionaries are terminological products that incorporate facts for related SBVR concepts, such as definitions, synonyms, and examples.
The content of a terminological dictionary is determined by a vocabulary:
terminological dictionary presents vocabulary
Definition: the terminological dictionary sets forth representations related to the designations and fact type forms of the vocabulary
Since there can be many vocabularies for (groupings of) a given speech communities designations and fact type forms and since vocabularies are oriented to audience / use, full modular capability is currently available for any terminological dictionary via terminological dictionary presents vocabulary and vocabulary1 incorporates vocabulary2. All that need be done is to define a vocabulary whose sole purpose is to specify the designations and fact type forms for a given terminological dictionary. If other vocabulary contents are desired in the terminological dictionary, all that has to be done is to add another “included” vocabulary to the terminological dictionary’s vocabulary.
Conclusion: no additional SBVR function is needed to provide the desired capability.

In section 9.2.8, on page 70, the example for "aggregation formulation"
introduces several variables. All but one of the introduced variables is
specifed as ranging over some concept. For example, ". . . . The second
variable ranges over the concept ‘number’."

My issue: there is no corresponding "ranges over" line for the third
variable. It is true (per 9.2.1) that variables need not range over any
concept. But this example would be clearer if the "ranges over" line were
included for that third variable.

I believe this third variable is supposed to range over the concept 'set'.

Add to the example, a line indicating that the third variable ranges over the concept ‘set’.

Section 11.1.2.2 "Kinds of Characteristic" on page 136 says that
"characteristic type" is "General Concept: concept type". I suggest that
"General Concept: categorization type" would be more accurate.

Given this proposal, in EU-Rent, making "branch type" a "characteristic
type" would enable statements such as "if there exists a branch that is a
city branch ...."

Correct the entries for categorization type and characteristic type to reflect that categorization type is a special kind of concept type, and characteristic type is a specialized kind of categorization type. Also, update the discussion in Annex D that explains/illustrates these concepts.

SBVR currently has multiple concepts for organizing vocabularies and rules:

• conceptual schema (clause 8.5)
• fact model (8.5)
• body of shared meanings (11.1.1)
• body of shared concepts (11.1.1)
• terminological dictionary (11.1.1)
• vocabulary (11.1.1)
• rulebook (11.2.2.4)

Some issues:
4) A rulebook should have a URI, so that the rulebook can be addressed over
the Internet.

Add “rulebook has URI” in clause 11.2.2.4.

The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

Add the following two lines into the xs:complexType of the SBVR XML schemas for each association of the SBVR metamodel.
<xs:attribute ref="xmi:id"/>
<xs:attributeGroup ref="xmi:ObjectAttribs"/>

mismatch between diagram where speech community is associated with exactly one semantic community but 07-09-04 version of the XMI/CMOF has speech community mapping to multiple semantic community e.g. <ownedMember xmi:type="cmof:Association" name="semantic community has speech community" xmi:id="semanticCommunityHasSpeechCommunity" memberEnd="semanticCommunityHasSpeechCommunity.semanticCommunity semanticCommunityHasSpeechCommunity.speechCommunity"> <ownedEnd xmi:type="cmof:Property" name="semantic community" xmi:id="semanticCommunityHasSpeechCommunity.semanticCommunity" type="semanticCommunity" lower="0" upper=""/> <ownedEnd xmi:type="cmof:Property" name="speech community" xmi:id="semanticCommunityHasSpeechCommunity.speechCommunity" type="speechCommunity" lower="0" upper=""/> </ownedMember>

The SBVR XMI file referenced is not the current published 1.0 version. The current 1.0 version is correct. This is not an Issue.
Revised Text:
None
Disposition: Closed, No Change Required

'Vocabulary' is defined in clause 11.1.3 as "set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings ".

'Rulebook' is defined in clause 11.2.4 as "the set of representations determined by a given speech community to represent in its language all meanings in its body of shared meanings ".

How does 'vocabulary' relate to 'rulebook'? When would an SBVR tool vendor use one or the other? The specification should either explain why it defines both these two concepts and when one would use one versus the other.
--------------------------------

A vocabulary contains only designations, whereas a rulebook contains all representations (designations, definitions, notes, examples, etc.) A rulebook may also include representations of the elements of guidance in a body of shared guidance. A terminological dictionary contains representations of only terminology.
The issue is addressed by adding clarifying informative text to the specification.

The note under "state of affairs" reads:

"A state of affairs can be possible or impossible. Some of the possible ones are actualities. A state of affairs is what is denoted by a proposition. A state of affairs either occurs or does not occur, whereas a proposition is either true or false. A state of affairs is not a meaning. It is a thing that exists and can be an instance of a concept, even if it does not happen. "

Although unstyled, the use of "denoted by" is likely to confuse readers. The fact symbol "denotes" is used in clause 11.2.1.3 in the fact type "term denotes thing ". But a proposition is not a term, so this fact type is not what is meant in the note. The note is trying to use a passive version of "meaning corresponds to thing" from clause 8.6.1.

Proposed resolution:

1. Add a synonymous form to "meaning corresponds to thing" such as "thing is meant by meaning".
2. Revise the note under "state of affairs" to use the new synonymous form and style the wording to make clear the reference to this formal SBVR concept.

1. Add a synonymous form to "meaning corresponds to thing" such as "thing is meant by meaning".
2. Revise the note under "state of affairs" to use the new synonymous form and style the wording to make clear the reference to this formal SBVR concept.Resolution:

A Note for Is-Facet-of Fact (Type) currently reads: "A given community may choose to include only one facet." The Note could be read as a rule: It is permitted that a given community include only one facet." The Note should probably read: A given community may choose to include any number of facets, including just one or none at all.

Change the Note to read: “A given community may choose to include any number of facets, including just one or none at all.”

The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "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)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11.

With ‘fact model’ (and ‘conceptual model’) moved to Clause 10 (Issue 13138), the confusion that came from the use of “fact model” is removed. (The definition and uses of “fact model” and ‘conceptual model’ are now all contained within the Clause 10 material, which is where these terms are used.)
This Resolution adds the synonym ‘concept model’ to the existing concept 'body of shared concepts" to provide a business-friendly term

Title: Model expression structure
Specification: SBVR
Version: 1.0
Source: Ed Barkmeyer, NIST, edbark@nist.gov

Summary:

SBVR clause 8.2 defines 'starting character position' as a means of reference to a substring of a Text object. And the definition of placeholder in clause 8.3.4 treats the placeholder as a syntactic substring that is identified by its starting character position.
This is a junior programmer model of expressions – a poor PSM – and it doesn't work reliably for a number of surface languages.

The idea is that the unspecified representation of a concept may involve an expression that has a syntactic structure. Since SBVR has no idea what that syntactic structure is (because it belongs to an undefined surface language for which SBVR is the metamodel), it must define a general model of expressions sufficient to support the idea that a placeholder is a subexpression, and has a surface-language-defined means of identification.

Recommendation:

In 8.2, Delete 'starting character position'. Replace it with a model of expressions that makes clear the point at which surface-language grammar and orthography determine the technical structure of the expressions.

In 8.3.4, delete all references to 'starting character position' in the entry for 'placeholder', and replace them with references to the structural concepts (to be) defined in 8.2.

In 8.3.4, delete 'placeholder has starting character position' and replace it with a relationship to a structural concept (to be) defined in 8.2.

The issue is resolved by the resolution to Issue 13802, which adds a caveat to the section on fact type forms:
The elements defined here are intentionally minimal and may or may not be adequate for specific languages.
It is not intended that the scope of SBVR expand to include language structure.
Revised Text:
No change.
Disposition: Resolved

Title: Definition of signifier
Specification: SBVR
Version: 1.0
Source: Ed Barkmeyer, NIST, edbark@nist.gov

Summary:

SBVR clause 8.2 defines 'signifier' to be a role in a 'designation'.
But the concept 'designation' is defined in 8.3.1.

Recommendation:

Move the entry for 'signifier' to 8.3.1, where it is used.

Move the glossary entry for 'signifier' from 8.2 to 8.3.1, with no text change.

'Actuality' is a specialization of 'state of affairs'.
Clause 8 says:
fact type (synonym: verb concept): concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities
There are other instances of fact type that need to be accommodated, such as:
§ states of affairs that are planned to become actualities
§ states of affairs that might be actualities, but the semantic community does not yet know for sure
Instances of a fact type should be states of affairs.

Clause 8 ‘fact type’ has been renamed ‘verb concept’

1. Change the definition of ‘verb concept’ to specialize the concept ‘state of affairs’ to make it possible to structure propositions that are not known to correspond to actualities without having to use objectifications.
2. Separate the concept of verb concept as a structure of roles and a verb phrase from the more specific concpet of a verb concept with at least one open role (how it has always been understood in SBVR) to clarify ambiguity and support the addition of Unitary Verb Concept and Individual Verb Concept.

According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected:
1. Closed world assumption; state of affairs interpretation
2. Closed world assumption; actuality interpretation
3. Open world assumption; state of affairs interpretation
4. Open world assumption; actuality interpretation.

For convenience it is recommended to add the following four meta fact types:

1. The population of all fact types in <conceptual schema> is considered <closed_or_open>
2. The population of all fact types in <conceptual schema> is considered <state-of-affairs_or_actuality>
3. The population of <fact type> is considered <closed_or_open>
4. The population of <fact type> is considered <state-of-affairs_or_actuality>

Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality.

SBVR works with all business applications that are based on business vocabularies and rules, regardless of open/closed assumptions and regardless of whether fact models are interpreted as representing the real world or as representing hypothetical worlds.
Closed world assumption – SBVR supports both open and closed world assumptions. Wherever there is a desire to assert that all fact types in a given conceptual schema are closed (or open), that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a conceptual schema C:
Each fact type that is in C is closed in C.
Any default selections of open or closed by tools that create conceptual schemas are a matter for tool builders to decide and are not a subject of the SBVR specification.
Characterizing a fact type as open or closed independently of any conceptual schema or fact model is inappropriate because the same fact type can be in multiple conceptual schemas. A fact type is a meaning. Since it is logically possible that the same meaning is in multiple conceptual schemas created by different people for different purposes, it is impractical to assume that anyone would know whether closure is universal. Therefore, no new fact type characterizing fact types as open or closed will be added.
However, any tool can certainly have defaults or allow defaults to be set regarding closure for the conceptual schemas that are created by that tool.
State-of-affairs interpretation – SBVR defines ‘fact’ to be “proposition that is taken as true”, not as “proposition that is true”. A fact is a proposition that is taken to be true in the world that is the subject of discourse, whether that world is real or hypothetical.
Any tool can have its own default behavior with respect to assumptions about possible worlds. Defining such defaults is outside of the scope of the SBVR specification.

Disposition: Resolved with NO CHANGE

Figure 12-1 shows 'merged' arrowheaded lines from 'element of guidance' and 'rule' into 'propositiion'. While this is not formally meaningful our graphics have used a convention to bring the lines together for elements that are mutually exclusive and to show the lines separate when not — ref. the separate lines into 'rule'. I suggest that Figure 12-1 be updated to show separate arrowheaded lines into 'proposition'.

Update Figure 12-1 to show separate arrowheaded lines into 'proposition'

Title: Inconsistent use/definition of keyword 'or'
Spec: SBVR
Version: 1.0

Source: Ed Barkmeyer, NIST, edbark@nist.gov

Summary:

In clause 9.2.1, p.52, 'bindable target' is defined as:
variable, expression or individual concept
In clause 11.1.5, 'contextualization fact type' is defined as:
is-role-of fact-type or is-facet-of fact-type
In clause 11.1.5, 'contextualized concept' is defined as:
role or facet
At the end of section C.3.2.1 in Annex C, the example is:
contextualized concept
Definition: role or facet
In Annex E, p.327, 'fuel level' is defined as:
full or 7/8 or 3/4 or 5/8 or 1/2 or 3/8 or 1/4 or 1/8 or empty

In all these, 'or' is stylized as a keyword. According to Annex C.3.2.1, these represent extensional definitions, i.e., the unions of the extensions of the concepts. But according to Annex C.1.1, the
keyword 'or' is defined to mean logical disjunction between two
propositions. So the definition of keyword 'or' is inconsistent with the usages.

One solution is to change the definitions.
E.g., for contextualized concept:
Definition: concept that is a role or is a facet
This form has a direct translation to the concepts in Clause 9.

An alternative is to change the meaning of the keyword in C.1.1, assuming it is never used for logical disjunction of propositions.
Another alternative is to introduce a new keyword.

Clarify the example at the end of C.3.2.1

Subclause 8.5 is about the interchange files defined in Clause 15.
The syntax for these files is (mostly) defined in Clause 13; the content of Subclause 8.5 should be placed in Clause 13.

From Issue 13138 (as of 5 Dec 2008):
"Subclause 8.5 includes concepts conceptual schema and fact model that have no bearing on the content of the SBVR metamodel (as defined in the Clause 15.1 XMI file) or an SBVR model (to be illustrated by Clause 15.3 SBVR model of SBVR file). Rather they explain the structure of the SBVR model file in Clause 15.3 as an XML file containing a fact model population for an externally referenced SBVR XSD conceptual schema."

The conceptual schema for interchange is the XSD, the facts are the XML content of the interchange file.

Supporting arguments for making the change:
• The specification does not place the syntax of Clauses 8, 9, 11 and 12 in Clause 8 - it is in Annex C
• The specification does not place (most of) the syntax of Clause 15 in Clause 8 - it is in Clause 13
Some corrections are needed:
• 'fact model' has two parts: 'conceptual schema' and 'fact population'
• 'fact model is based on conceptual schema" should be 'fact population is based on conceptual schema'
• 'conceptual schema includes fact' should be 'fact population includes fact'

Dependencies with other Issue Resolutions
Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10
This issue removes the definitions in Subclause 8.5 from the scope of Issue 13138.
Resolution:
Move the content of Subclause 8.5 into Clause 13, with the corrections listed in Discussion, above.

Resolution:
Resolved by the resolution of Issue 13838
Revised Text:
None
Disposition: Closed, no change required

The definition-based model specified in Clauses 8, 9, 11, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns:
1. Separation of the two different meanings of 'fact type' into different models
2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption.

Merged with Issue 15623
Revised Text:
No change.
Disposition: Duplicate or Merged

The segmentation 'Thing in Context' is inconsistent with the definitions of 'role' and 'facet'. The segmentation is based on an assumption that the extensions of 'role' and 'facet' are completely disjoint. But there is nothing in the definitions of 'role' or 'facet' that cause them to be disjoint. It is possible that a situational role is relevant only from a certain viewpoint. Recommendation: Remove 'Thing in Context' and all references to it. Change Figure 11.1.5 to not show segmentation between 'role' and 'facet'.

Remove 'Thing in Context' and all references to it. Change Figure 11.1.5 to not show segmentation between 'role' and 'facet'.”

The concept "Partitive Fact Type" is based on the Concept "Partitive Relation" in ISO 1087. However, SBVR did not pick up the ISO synonym "Part-Whole Relation". This could raise questions about how the SBVR notion is being based on the ISO notion. Also, "Part-Whole" is more business-friendly than "Partitive". Proposed Resolution: Add "Part-Whole Fact Type" as a synonym of "Partitive Fact Type". (If for some reason this is deemed inappropriate or undesirable, a note should be added as to why.)

Add "Part-Whole Fact Type" as a synonym of "Partitive Fact Type".

The definition of is-property-of fact type is based on the notion of ‘essential quality’. Use of the word ‘essential’ is misleading since ISO and therefore SBVR talks about ‘essential characteristic’ in quite a different sense. The three Dictionary Bases are poorly chosen (probably because they were chosen before the ISO notion of characteristic was introduced into SBVR). In any event, the current definition of is-property-of fact type does not accurately express the intended meaning of the concept. Resolution: 1. Change the definition of "Is-Property-Of" fact type to: associative fact type that is defined with respect to a given concept such that each instance of the fact type is an actuality that an instance of the concept has a particular quality or trait 2. A better Dictionary Basis should replace the existing ones. Use the following definition from MWUD: 1 a : a quality or trait belonging to a person or thing;

1. Change the definition of "Is-Property-Of" fact type to: associative fact type that is defined with respect to a given concept such that each instance of the fact type is an actuality that an instance of the concept has a particular quality or trait
2. A better Dictionary Basis should replace the existing ones. Use the following definition from MWUD: 1 a : a quality or trait belonging to a person or thing;

Problem Description: The signifier "Explicitness of Representation" for a categorization scheme in SBVR 11.1.3 is not intuitive, and the reason for the choice is not explained.

Explicitness of Representation
Definition: the categorization scheme of the concept definition that classifies a definition based on whether it is owned by its speech community or adopted by its speech community

Resolution: Change the signifier for the concept to "Origin".

Change the signifier "Explicitness of Representation" to “Definition Origin”.

All, In resolving Issue 15950 it has come to our attention that "community" and "semantic community" are used in Clause 12 in ways that are not really appropriate. I believe we are currently missing a very important concept for SBVR – namely, the "business" part of "business rule". Attached is discussion and proposed resolution.

Title: Governed Community & Adoption of Business Rules

Source: Ronald G. Ross, Business Rule Solutions, LLC, rross@BRSolutions.com

Summary:

SBVR currently lacks a concept and term for the kind of community that creates business rules. This glaring omission was separated by agreement of the team from resolution of Issue 15959 (Inappropriate definitions of Business Rule, Rule Statement).

The current definition of “community” is: group of people having a particular unifying characteristic in common

The current definition of “semantic community” is: community whose unifying characteristic is a shared understanding (perception) of the things that they have to deal with

By these definitions, any of the following could qualify as (semantic) communities: atheists, deists, communists, surfers, Francophiles, Anglophiles, futurists, business travelers, rappers, wine lovers, car surfers, baseball fans, diabetics, business travelers, psychics, nudists, philatelists, Egyptian protesters, Japanese earthquake victims ...

Such communities do not, and cannot, create business rules. They lack the authority, standing and charter to do so. Unlike societies, organizations and businesses, they are not governed communities.

Currently, SBVR has no concept for the special kind of communities that are governed. In effect, SBVR has no meaning for the “business” part of “business rule”. This omission is a significant one.

In addition, SBVR currently does not adequately recognize or treat adoption of business rules. Adopting business rules is an act of free will (by a governed community) and should explicitly satisfy the “under business jurisdiction” test in the definition of “business rule”.

Resolution:

Add a category of “community” called “governed community” as follows.

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

Definition: community that by virtue of some recognized standing, authority or charter can create, adopt and apply business rules

Dictionary Basis [MWUD “govern”]: 1a: to exercise arbitrarily or by established rules continuous sovereign authority over; especially : to control and direct the making and administration of policy in

Examples: societies, chartered organizations, businesses, government bodies

Example: EU-Rent is a legal entity, makes business rules for itself, and is therefore a governed community. Eu-Rent is also a member of each governed community (country) where it does business, as well as the European Union, a yet broader governed community.

Note: A governed community can adopt sets of business rules (and advices) as-is, just like vocabulary. The decision to adopt business rules ‘as-is’ is an act of free will and therefore satisfies the “under business jurisdiction” test in the definition of “business rule”.

Note: The “business” part of “business rule” is a popular, informal term for “governed community”.

Note: The question “Who makes the rules?” for a governed community is outside the scope of SBVR.

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

Revised Text:

Previously, I did a search of Clause 12, and sent my findings and recommendations. There are 5 segments of text where “semantic community”, “community” or “communities” appear. Below are (revised) recommendations for each.

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

[1] body of shared meanings includes body of shared guidance

Definition: the body of shared guidance is the set of all elements of guidance in the body of shared meanings uniting a semantic community that takes the elements of guidance as true

RGR: This definition is problematic. Alethic elements of guidance might “unite” a semantic community (no real opinion), but I don’t see deontic elements of guidance as (a) “uniting” anything, or (b) pertaining to semantic community at all (unless the semantic community just happens to be a society, organization or business).

Also, from a business perspective (as appropriate for Clause 11), a “community” doesn’t “take … elements of guidance to be true”. That’s a logician’s view. It would be more accurate to say ‘recognizes … as applicable’.

Recommendation: Delete the phrase starting “uniting ...”.

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

[2] business rule

Definition: rule that is under business jurisdiction

General Concept: rule, element of guidance

Note: A rule’s being under business jurisdiction means that it is under the jurisdiction of the semantic community that it governs or guides - that the semantic community can opt to change or discard the rule. Laws of physics may be relevant to a company (or other semantic community); legislation and regulations may be imposed on it; external standards and best practices may be adopted. These things are not business rules from the company’s perspective, since it does not have the authority to change them. The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them. Similarly, it will create business rules to ensure that standards or best practices are implemented as intended. See subclause A.2.3.

RGR: There are 3 instances of “semantic community” in this note.

Recommendation: I would change this note to read as follows:

Note: A rule’s being under business jurisdiction means that it is under the jurisdiction of the governed community that it governs or guides - that the governed community can opt to change or discard the rule. Laws of physics may be relevant to a governed community; legislation and regulations may be imposed on it; external standards and best practices may be relied upon. These things are not business rules from the company’s perspective, since it does not have the authority to change them. The company will decide how to react to laws and regulations, and will create or adopt business rules to ensure compliance with them. Similarly, it will create or adopt business rules to ensure that standards or best practices are implemented as intended. See subclause A.2.3.

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

[3] advice of contingency

Definition: advice of possibility that is a claim of contingency

Note: The purpose of an advice of contingency is to preempt application of rules that might be assumed by some members of a semantic community, but are not actually definitional rules admitted by the community. Often, the reason for this assumption in a business is that other, similar businesses have such rules. Typically, the reason for providing such explicit advice is that people in the business have mistakenly applied the non-existent rule in the past.

RGR: There is one instance of “semantic community” in this note and one instance of “community”.

Recommendation: Both instances should be replaced by “governed community”.

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

[4] advice of optionality

Definition: advice of permission that is a claim of optionality

Note: The purpose of an advice of optionality is to preempt application of rules that might be assumed by some members of a semantic community, but are not actually behavioral rules imposed by the community. Often, the reason for this assumption in a business is that other, similar businesses have such rules. Typically, the reason for such explicit advice is that people in the business have mistakenly applied the non-existent rule in the past.

RGR: There is one instance of “semantic community” in this note and one instance of “community”.

Recommendation: Both instances should be replaced by “governed community”.

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

[5] Section 12.5, page 178, the paragraph that reads:

In cases where definitions of concepts taken together do not logically imply something proposed in a structural rule statement, there is an inadequacy or mistake in either the relevant definitions or in the rule statement. The case of inadequate definitions is common and is acceptable in some communities. It occurs when a community shares a tacit understanding of many of its concepts. Words either have no explicit definitions or have definitions that use words that have no explicit definitions. Structural rule statements in this context can be correct, even if they logically follow from a tacit understanding of what characteristics are incorporated by concepts.

RGR: There is one instance of “community” in this section and one instance of “communities”.

Recommendation: I have no strong feelings at present about whether these instances should be changed or stand.

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

Add a new subclause to Clause 12 containing:
• A new noun concept (general concept): ‘authority’
• Two new roles: ‘adopting authority’ and ‘owning authority’
• Four new verb concepts:
1. authority has business jurisdiction over element of guidance (by either defining or adopting it)
2. authority authors guidance statement
3. authority defines element of guidance
4. adopting authority adopts element of guidance from owning authority citing reference
• Notes , stating that:
1. Elements of guidance cannot be adopted in the abstract. They must be adopted via representations – guidance statements.
2. If elements of guidance are to be adopted, the concepts used in them must also be part of the body of shared meanings.

In SBVR C.1.6 there is an example, “thing [individual concept] is changed”, defined thus: “the extension of the individual concept is different at one point in time from what it is at a subsequent point in time”. In early SBVR thinking, the meaning of a singular definite description was an individual concept (a concept that corresponds to only one object [thing]) even if the description could refer to a different individual at a different time or in a different possible world. But that early understanding was later changed, as seen in a note in the SBVR entry for ‘individual concept’: “… each referring individual concept has exactly one and the same instance in all possible worlds”.

Therefore, the first and third examples in C.1.6 and the similar example in E.2.3.1 need to be changed to not use ‘individual concept’. Perhaps a new concept type is needed for the meaning of a singular definite description.

A new concept type, ‘unitary concept’, is added. The examples and explanations in C.1.6 are changed to use the new concept. Also, one example in clause 9 and a fact type in Annex E that involve intensional roles are changed to be consistent with the changes to C.1.6.

In clause 9.2.8, in the entry for 'noun concept nominalization', there is an Example that begins:
"'EU-Rent stores at least 300 kiloliters of petrol.'
In this example, ‘petrol’ is a mention of the concept ‘petrol’ which is used in the ‘type’ role of a fact type ‘quantity is of type’.
The statement is formulated by an at-least-n quantification.
. The minimum cardinality of the quantification is 300."

This creates a dubious fact type and misconstrues "at least 300 kilolitres" as an at-least-n quantification.
"At least 300 kilolitres of petrol" is not an at-least-n quantification. It is not a reference to the cardinality of a set of distinct kilolitres that petrol has. (By way of analogy, my refrigerator stores about 3.5 litres of milk, which is clearly not a cardinality.) It is rather a comparison of two quantities – the quantity (of petrol) stored and the quantity '300 kl' (of petrol). In SBVR SE, this statement should read:
"EU Rent stores a quantity of petrol that is greater than or equal to 300 kilolitres."

In a related previous issue, the FTF determined that a reference to "90 days" was an individual concept – an amount of time. "300 kilolitres" is also an individual concept – a 'quantity value'.

If the fact type in question is indeed 'company stores thing', then the 'thing' in question is an amount of a substance – a 'quantity'. But 'quantity is of type' looks like a synonymous form of 'type has quantity', using 'of' as a verb, and that is altogether the wrong idea for the relationship. In fact, quantities are modifiers of nouns – petrol (that is) in the amount of 300 kl – but we don't need to introduce this complexity into the example.

In general, inventories are based on the fact type 'facility stores quantity of kind-of-thing. The point of the example – that 'kind of thing' is a specialization of 'concept' and thus 'petrol' is mentioned/nominalized in this usage – would not be marred by using this fact type and avoiding strange characterizations of quantities. Reformulating the example statement using this fact type emphasizes the noun concept nominalization and eliminates the confusing and erroneous elements of the example.

The example is replaced by a straightforward example of mentioning a concept.

In recent RTF teleconferences, it was agreed that in Clause 11.1.3, Kinds of Definition, some additional notes are needed for “adopted definition” to explain that adoption of a definition is the mechanism for adopting the meaning of a concept.

Add notes to the entries in Clause 11.1.3 for “adopted definition” and “speech community adopts adopted definition citing reference” to reflect the discussion, above.
Replace the example under ‘adopted definition’ with actual examples from the SBVR specification, including adoption of the definition of ‘object’ from ISO 1087, and using the term ‘thing’ within SBVR

Clarify that objectifications based on a fact type can refer not only to actualities, but more generally to states of affairs, regardless of whether they are actual. Fix examples of objectifications to include objectifications of states of affairs that are not necessarily actual. Also, for SBVR Structured English in the explanation of using the demonstrative “that” for objectification, refer more generally to “state of affairs” rather than to “actuality”.

Clarify that objectifications based on a fact type can refer not only to actualities, but more generally to states of affairs, regardless of whether they are actual. Fix examples of objectifications to include objectifications of states of affairs that are not necessarily actual. Also, for SBVR Structured English in the explanation of using the demonstrative “that” for objectification, refer more generally to “state of affairs” rather than to “actuality”.

In clause 8.3.3, in the glossary entry for "statement", SBVR has the
Necessity "Each statement expresses exactly one proposition ". This
Necessity is also shown in figure 8.4 and is cited as an example on printed
page 6. The issue is that some statements do not express propositions
(i.e. a meaning that is true or false, per the definition of 'proposition'
in 8.1.2). There are at least two types of statements that are neither
true nor false: (a) paradoxes, such as "This statement is false"; (b)
atemporal statements used with temporal worlds. For example, the statement
"the board of director meets" is a proposition (i.e. either true or false)
in an atemporal world (i.e.a world that only contains facts about one
moment in time). But in a world that has records of multiple meetings of
the board of directors, the statement is ambiguous. It can be understood as
true if read as meaning "the board of directors meets at some time". It is
either true or false (according to the facts in the world) if it is read as
"the board of directors meets right now". Clearly a statement does not
express a proposition when the statement is paradoxical or ambiguous.

Suggested resolution:

Revise the Necessity to read "Each statement expresses at most one
proposition." Revise the figure and the example to match

Suggested resolution:

Revise the Necessity to read "Each statement expresses at most one
proposition." Revise the figure and the example to match.

Resolution:
A sentence that does not express a proposition is not an expression of a statement. It should be referred to simply as a “sentence”.
1. Add some clarifying words to the definition of ‘statement’ without changing the meaning.
2. Add a note to state that if an expression is an ambiguous sentence, one that represents two different propositions, each of the two representations is a separate statement.
3. Add a note that a paradoxical expression (e.g., “This sentence is false.”) that fails to represent a meaning that is true or false is not considered to be an expression of a statement.
4. Add a note that clarifies the use of “sentence” in relation to ‘statement’.
5. Add a note that time, if it is to be part of the proposition, must be explicit in the statement.
6. Add a Note that using a statement is a descriptive example is merely illustrative and is not an assertion of truth-value.
7. Add a note clarifying the relationship between closed logical formulations and statements of a proposition.
8. Add the fact type ‘expression is unambiguous to speech community’.

Summary: SBVR makes an important distinction between the meanings of the word “exists” (existential quantification) and the word “occurs” (used to describe a state of affairs). A state of affairs can exist and thereby be involved in other things (e.g., plans, desires, fears, expectations) even if it does not occur, even if it never occurs. SBVR should explicitly define and explain the characteristic ‘state of affairs occurs’, and should then use that characteristic to define ‘actuality’.

Note that this issue is related to issue 14849 and became important in discussing 14849, but its resolution should be independent of 14849.

1. Add a new characteristic, ‘state of affairs is actual’ and use it to define ‘actuality’ (“is actual” is taken as a preferred alternative to “occurs”).
2. Explain the difference between ‘is actual’ and ‘exists’.

There appears to be something missing ("is" – or, the more verbose, "that is") in the Definition given for "expression" (p. 26 – PDF p. 38),
i.e., ..."but is independent"... (... "but that is independent"...).

After discussion at the May 13, 2011 telcon, the wording "but considered independently" was agreed as the correction to the wording.

Issue Title: Conflation of the signifier “rulebook” with the concept/definition for Speech Community Representations (a container concept /set)

Clause: 11.2.2.3

Printer Page: 155

Issue Statement:

The concept (definition) in Clause 11.2.2.3 defined as:

the set of representations determined by a given speech community to represent in its language all meanings in its body of shared meanings

is conflated with the undefined concept most commonly associated with the signifier “rulebook.”

The set defined in this entry is only the representations for one speech community and does not include any semantic connections between meanings, which are required to compose the content of a rulebook.

Proposed Solution:

Separate the two concepts by creating a new entry for “rulebook”; provide a definition for rulebook that can be used to produce one; and replace the signifier “rulebook” on the existing entry with “speech community representations”.

Separate the two conflated concepts into two separate entries by creating a separate entry for rulebook with the appropriate definition and changing the signifier of the current entry to “speech community representations”.

An elementary fact quoted in section 10.1.1.2 is “The Prime Minister named ‘John Howard’ was born in the Country named ‘Australia’” using yet another typography. This ‘fact’ is no longer true as, while John is still Australian-born he is no longer prime minister. An example, perhaps of the inadvisability of using role names in rules if they are not relevant to the rule. The following facts are correct but not time-dependent:
a. The Man named ‘John Howard’ was born in the Country named ‘Australia’.
b. The Man named ‘John Howard’ was Prime Minister of the Country named ‘Australia’ from 1996 to 2007.

This discussion (on p. 88) is explaining 'elementary fact'. The phrases "Prime Minister named 'John Howard'" and "Country named 'Australia'" illustrate ways to refer to specific individuals — individuals denoted by definite descriptions. These examples are not for rules and they are not using role names.
For this discussion the sense of 'President' is not to be interpreted as meaning only the current office-holder. For example, another example could talk about "the President named 'George Washington'" to give another use of a definite description.
It was felt that this discussion of elementary fact could be improved by (1) replacing the Australian example with one from the US (where the sense of being 'President' is not time-dependent) and (2) continuing the example used in the first boxed example into the second boxed example (rather than introducing the new, Mary McAleese example).
The typography used in Clause 10.1.1 is that of ORM — see Annex I.

“Each FemaleAustralian is a Person who was born in Country ‘Australia’ and has Gender ‘Female’” (section 10.1.1.2) and “Each Australian is a Person who was born in Country ‘AU’” (section 10.1.1.7) fly in the face of the meaning of citizenship: I was born in the UK but am an Australian, having taken out Australian citizenship, whereas Rupert Murdoch was born in Australia but is not an Australian, having renounced his Australian citizenship as a prerequisite of taking US citizenship. By the way these rules use a non-standard typography.

Change the examples from using "born in" to being "a citizen of". By the way the typography is different but not "non-standard" — it uses ORM conventions (as explained in Annex I).