Name: 'state of affairs' is an individual concept, not a thing
Doc: dtc/06-08-05
Date: August 2006
Version: Interim Convenience Document
Chapter: 8.6

Description:

The diagram in 8.6 says that a state of affairs is (intended to be) a thing, and 'actuality' is a state of affairs that occurs in the reference world. Both of these statements are incorrect. An actuality is indeed a 'thing'. A 'state of affairs' cannot be.

The definition of fact type says that all its instances must be actualities. This implies that a possible state of affairs that is not an actuality does not correspond to any fact type. And that is correct, because a (possible) state of affairs is intrinsically conceptual.

If one replaces the roles in a fact type with specific things, one gets a proposition, which, according to 8.6, 'corresponds to' a (potential) state of affairs. But that proposition must be a concept: it has an instance that is a state of affairs, and a state of affairs is a 'thing'. If it is impossible, that state of affairs is an instance of the proposition, but if it is actual, it is also an instance of the fact type. This makes no sense. The problem lies in trying to distinguish states of affairs from propositions and fact types.

If one replaces the roles in a fact type with specific things, one gets a specialization of the fact type – an individual concept. Therefore, a proposition must be an individual concept. That individual concept is a potential state of affairs, and an actuality is the thing it corresponds to, if any. Therefore, a 'state of affairs' is not a 'thing', it is an individual concept, and it is a synonym for 'proposition'. And an actuality is not a subtype of 'state of affairs'; it is rather the instance it corresponds to.

States of affairs are not individual concepts. Every state of affairs is a thing. SBVR defines ‘thing’ as anything perceivable or conceivable. A conceivable situation might be actual or not. It might have been actual in the past, not actual in the present and actual again in the future. It might be wanted, whether actual or not. It might occur intermittently. It might be obligated. States of affairs that are not actual are involved in actualities. E.g., each instance of the verb concept (was fact type) (from SBVR 12.4.1) ‘element of guidance obligates state of affairs’ is an actuality, regardless of whether that element of guidance is an operative rule that is being violated. If the rule is violated, the obligated state of affairs is not an actuality. But that state of affairs, despite failing to be actual, fills the ‘state of affairs’ verb concept role (was fact type role) in the instance of the verb concept (was fact type) ‘element of guidance obligates state of affairs’, and that instance is an actuality.
There is an important difference between a conceived thing and the concept that corresponds to that thing. For example, a possible world is a conceived thing. It is also a state of affairs. But a possible world is not a concept. It is an instance of the concept ‘possible world’ and also an instance of the more general concept ‘state of affairs’.
States of affairs are not individual concepts. States of affairs are things.

Disposition: No Change

STATEMENT

The following two definitions in Clause 8.1.2 of the SBVR Specification are wrong and need to be fixed:

In SBVR deontic logic is about organizational behaviour and nothing else. In SBVR alethic logic is about organizational meaning (“true by definition”) and nothing else.

1. The definitions need to be reworded without using deontic logic

2. Wording to make these two points absolutely clear needs to be added to the normative part of the SBVR Specification

The problem is that the definitions are phrased using "must" and "may", which, per Annex C means they state rules or advices rather than necessities. Rephrase them to use the 'acceptable world' terminology.

Name: Definition of 'fact type'
Doc: dtc/06-08-05
Date: August 2006
Version: Interim Convenience Document
Chapter: 8.1.1

Description:

In clause 8.1.1, the key concept 'fact type' is defined as:
"concept whose instances are all actualities and that is a basis for atomic formulation, having at least one role".
And 'noun concept' is defined as: "concept that is not a fact type"

This effectively makes all forms of 'concept' in SBVR dependent on whether or not they are the "basis for atomic formulation", which is a form of representation. It makes the whole idea of being able to separate meaning from formulation/representation a sham. The reference to atomic formulation is out of place and unnecessary.

Recommendation:

In 8.1.1, Replace the definition of 'fact type' with:
"concept whose instances are all actualities in which at least one role is distinguished, and which differ from one another in the things that play the roles."

Add a Note:

Note: An actuality in which roles are not distinguished is an instance of a noun concept, not a fact type. But whether roles are distinguished or not is a part of the conceptualization of the situation that is the actuality.

Change the definitions of 'noun concept' and 'fact type'.

Name: Vocabulary should be mandatory
Doc: dtc/06-08-05
Date: August 2006
Version: Interim Convenience Document
Chapter: 11.1.1

In SBVR, support for Clause 11 is a separate 'compliance point', not required for conformance. The 'vocabulary' concept is defined in Clause 11. Therefore, support for the 'vocabulary' concept is effectively a feature of only some SBVR implementations.

On the other hand, most of the SBVR specification is structured around the vocabulary concept. Moreover, an implementation that does not support the 'vocabulary' concept cannot usefully support business rules. Support for the vocabulary concept should be mandatory.

The appropriate solution would appear to be to move 'vocabulary' to clause 8. In fact, 'vocabulary' (in clause 11) and 'vocabulary namespace' (in clause 8) are coextensive, and the "incorporated characteristics" of the two concepts differ only in minor facets important to different users. The proper solution is to merge these concepts in clause 8.

Resolved by the Resolution to Issue 9955.

ISSUE STATEMENT

The definition of “individual concept” in SBVR is:

SBVR does not provide a means to specify what the instance of the individual concept is at any given point in time.

Since the instance of an individual concept can clearly be different at different points in time (possible worlds), we need a way to specify whether ‘Air Force One” in the example below is “the Boeing 777 with tail number nnn”, “the Apache Helicopter number xxxx”, or some other aircraft.

Air Force One

Definition: aircraft that the President of the United States is on board

Concept Type: Individual Concept

Add the new concept 'definite description'.
Clarify the definition of 'meaning corresponds to thing'.
Remove the necessity that an individual concept corresponds to exactly one thing.
Add a necessity that a referring individual concept always corresponds to the same thing.

This resolution resolves Issues 9942 as well.

SBVR has “thing equals thing” as a synonymous form of “thing is thing”, but “equals” should not be used in this way by SBVR. The integer 2 is not the same number as 2.0. But 2 equals 2.0. “Equals” can mean the same as “is” when talking about things other than quantities, but “equals” means something a little different for quantities.

“equals” is defined in the dictionary differently than “is”.
A model of quantities and units of measure that would extend SBVR would define “equals” differently than SBVR now defines it so that the model would fits normal usage.

Recommendation:

Remove “thing equals thing”, “thing is equal to thing” and “thing = thing” from the list of synonymous form of “thing is thing”.
Change the two uses of “equals” in SBVR (in 8.1.1.1 and 8.6.2) that mean “is” to say “is”.

1. Remove "thing equals thing", "thing is equal to thing" and "thing = thing" from the list of synonymous form of "thing is thing".
2. Change the two uses of "equals" in SBVR (in 8.1.1.1 and 8.6.2) that mean "is" to say "is".
3. Add 'quantity equals quantity'.

Issue: implicit passive form for partitive fact type that uses the verb
"includes"

To avoid the need to define an explicit Synonymous Form clause of "is
included in" for every partitive fact type that uses the verb "includes",
SBVR Structured English should provide for this as a special, implicit case.

(From the SBVR-FTF telcon of Feb. 2, 2007)

Deferred to the SBVR RTF for the lack of time.
Since there is a workaround of making the passive form of the verb "includes" explicit for each use of it in a verb concept by using the Synonymous Form feature of SBVR Structured English, this deferral to the SBVR RTF will not materially diminish the quality of the SBVR Available Specification.

The unary fact type/characteristic "category is inactive" is included in the business-facing vocabulary (Clause 11).

This characteristic was originally intended to document that "a vocabulary management decision was taken to have this concept as a category even though it may never play any role in any fact type."

Note, however, that the meaning of this fact type says that its instances are automatically derived for all (and only) cases of a category that does not participate as a role in a fact type, so this "vocabulary management decision" is not a direct one; it is a function of the ‘decision’ to define a category and then that category not currently being used in any fact type. In other words, any 'unused' category in an SBVR vocabulary will automatically be deemed to be “inactive”.

Now that 'role' has been specialized as ‘situational role’ and ‘fact type role’, no tool/technique should assume that a role that does not participate in a fact type is an error. Thus, the "category is inactive" fact type is not needed to communicate that the category is intentional/not an error.

Furthermore, the meaning of "is inactive" as specified by this entry is not the typical sense in the business world that makes core use of categorization schemes – e.g., marketing research product category schemes and financial charts of account (to name two). In those contexts, "is inactive" means the category is retained for historical reference/reporting while specifying that the category is not to be used for current population. Presenting this same verb phrase in the SBVR business-facing vocabulary with a vastly different business meaning will be confusing.

Resolution:

Simplify the Clause 11 Vocabulary and remove the potential misunderstanding by deleting the "category is inactive" fact type.

Simplify the Clause 11 Vocabulary and remove the potential misunderstanding by deleting the "category is inactive" fact type.

Doc: SBVR, dtc/06-08-05
Date: September 2006
Version: FTF Interim Specification
Chapter: 11.2.1.4
Related issues: none

Title: definition of 'prohibited symbol'
Source: Ed Barkmeyer, NIST, edbark@nist.gov

Description:

In clause 11.2.1.4, the definition of 'prohibited symbol' is:
"symbol that is declared unacceptable by its owning speech community
creating a vocabulary that excludes the symbol"

It is not clear how to parse this.

If it said just:
"symbol that is declared unacceptable by its owning speech community",
it would be clear what is meant. And there does not seem to be a need for SBVR to deal with how such a declaration is phrased. (It can clearly be formulated in SBVR by Referent (expression) 'is prohibited symbol'.)

If the intent is "symbol that is declared unacceptable by the fact that its owning speech community creates a vocabulary that excludes the symbol", that is simply wrong. Failing to include a symbol in the vocabulary does not prohibit its use, although it may implicitly deprecate it.

Recommendation:

In clause 11.2.1.4, in the definition of 'prohibited symbol', DELETE
"creating a vocabulary that excludes the symbol"

In clause 11.2.1.4, the definition of 'prohibited symbol' is:
"symbol that is declared unacceptable by its owning speech community
creating a vocabulary that excludes the symbol"

The clause "creating a vocabulary that excludes the symbol" should be removed.

Clause 7.1.2 is titled:
Other Namespaces and Rule Sets Presented in this Document
and it defines the symbol Vocabulary-to-MOF/XMI Mapping Rule Set
as: "General Concept: set"

Clause 13 specifies the mapping of vocabularies and rule sets from the SBVR Structured English form to a MOF/XMI exchange form. And clause 13 defines several information resources that are said to be "rule sets".

Clause C.4 is titled: Specifying a Rule Set

But the concept 'rule set' is not defined anywhere in the specification!

This term should not be used in so fundamental a way without being formally defined.

Further, 7.1.2 should specify that the individual concept 'Vocabulary-to-MOF/XMI Mapping Rule Set' is an instance of 'rule set', i.e.,
"General Concept: rule set"

The use of “rule set” in the introduction to clause 7 is left over from an old version and should be removed, because clause 7 does not contain any rule sets.
The term “rule set” is used by the SBVR Structured English and is not intended to be normative. Its use in the Annex on SBVR Structured English must be clarified.

Description:

In clause 8.2, p. 21, the entry for URI contains:
"Concept type: role"
"General concept: text"

This is incorrect, in both regards. Per RFC 2396, a URI is a category of symbol or term that has a particular expression syntax and refers to some information element or information resource that is nominally available on the Internet. The URI expression plays the signifier role in the designation of that information resource.

It might be acceptable to leave URI as a subtype of 'text', but that is a narrowing of the definition given in the cited source.

Recommendation:
a. delete: "Concept type: role"
b. replace: "General concept: text" with:
"General concept: term"

Change 'URI' from being a role to being a category (not a role).

SBVR supports restrictions on variables introduced by quantifications, but does not support them on variables introduced by projections. The result is that projections fails to fully formulate meanings in some cases.

Consider the following two statements:

A receptionist at a hospital may decide what doctor employed by the hospital sees a given patient.

A receptionist at a hospital may decide what doctor is employed by the hospital and sees a given patient.

These two statements clearly have different meanings. In the first case, there is no stated permission for a reception to decide about who is employed by a hospital. The receptionist is permitted to decided from among doctors employed by the hospital which one sees a patient. But in the second, the permission to decide applies to the conjunction of a doctor being employed and seeing a patient (a decision not likely to be given to a receptionist).

The problem is that SBVR currently supports formulating only the second statement, not the first. An attempt to formulate the first ends up with the formulation of the second because SBVR does not support restrictions on variables introduced by projections. Formulations of both statements incorporate an answer formulation having a projection on a variable that ranges over the concept ‘doctor’. For the second statement, the projection is constrained by a conjunction of two atomic formulations based on ‘hospital employs person’ and ‘doctor sees patient’ respectively. For the first statement, the variable should be restricted by an atomic formulation based on ‘hospital employs person’ and the projection should be constrained by an atomic formulation based on (‘doctor sees patient’) showing that a receptionist’s decision is about what doctor sees the patient and the choice is restricted to doctors employed by the hospital. But SBVR does not allow the restriction on the variable because it is introduced by a projection.

In the original conceptualization of restrictions on variables, they were supported for all variables, but at that time it seemed that there was no need for restrictions on variables introduced by projections, so the “restricts” fact type was moved to ‘quantification’ so that it would only apply to variables introduced by quantifications. But now it is clear from examples that the “restricts” fact type needs to be moved from ‘quantification’ to ‘variable’ where it can be used for all sorts of variables.

Replace the fact type 'logical formulation restricts quantification' with 'logical formulation restricts variable'. Fix reference schemes, necessity statements and examples accordingly.

In the interim version and in the 2nd FTF a number of normative changes have been made in the base vocabulary for elements of guidance. This requires a number of editorial changes to Annex E to align this elaborate example, and the text of some of the explanations with the changes in the formal vocabulary and the specifications for the Structured English. So that this Annex does not mislead implementors, it is important that the Annex be repaired to align it with the normative text and the changes to Annex C.

Deferred to second SBVR Revision Task Force because there were more foundational issues that had to be resolved first, and it was very important SBVR v1.1 out as soon as they were done.
Disposition: Deferred

Doesn't the fact type "closed logical formulation formalizes statement" associate such formulations directly to representations? Isn't that in conflict with the indirect relationship in the general SBVR design, which is that "closed logical formulations formulates meaning", and then "statement expresses meaning". Isn't this an error?

Note: this issue relates to existing issue 9945

Improve the definition of 'closed logical formulation formalizes statement' and add an example of how it relates to 'closed logical formulation means statement'. Similarly, improve the definition of 'closed projection formalizes definition' and add an example.

Correction of Unintended Effect of Issue 9475 Resolution ISSUE DESCRIPTION: There was an unintended effect of the Issue 9475 Resolution that was approved in Ballot 2 which removed the longstanding definitions of Structural Rule and Structural Rule Statement when they should have been kept as second definitions. The removal of these two definitions was not discussed explicitly either in meetings or on the SBVR FTF email list. The removal of these definitions was not explicitly shown in the Issue 9475 editing instructions that were submitted to ballot. In addition, the team agreed, with regard to another related point, not to make changes under Issue 9475 that affected Issue 9613. SUGGESTED RESOLUTION; Restore these two definitions as they appeared before the Issue 9475 Resolution was applied as second definitions; not to make them permanent, but so they can be dealt with as needed under the other open SBVR Issues.

Resolved by the resolutions to Issues 10571-10575

ISUUE TITLE: "Decided or Calculated" Should Read "Understood" to be Consistent with the Rest of Clause 12 ISSUE DESCRIPTION: In other parts of Clause 12 it was agreed that "understood" carried an aceptable meaning in place of 'decided or calculated". SUGGESTED RESOLUTION: On page 139 in the definition of 'element of guidance is practicable', replace "decided or calculated" with "understood".

Replace "decided or calculated" with "understood".

ISSUE TITLE: Semantic Community and Speech Community are not in SBVR's Core Compliance Point ISSUE DESCRIPTION: The entry for each term in in an SBVR vocabulary, among other things, is an existence assertion that "there exists in the minds of the members of the Semantic Community of the Speech Coomunity of this Vocabulary a concept that is known to the Speech Community of this vocabulary as ...(character string that expresses the term)...". No concept documented in an SBVR model exists outside the minds of the members of of a Semantic Community

As a result of the resolution of Issue 9957, this is no longer an Issue.

ISSUE TITLE: Need to Be Able to Distinguish Between Concepts that have No Instances in an SBVR model and Those That Do ISSUE DESCRIPTION: SBVR says that it is a vocabulary for business vocabulary and business rules. There are some concepts that are essential for vocabulary specialists (terminologists) and rule stewards to use to communicate well with each other when they are using SBVR that will never have instance in an SBVR model (or in an SBVR XMI interchange file). This kinds of concept is critical to the semantic communities wanting to create quality vocabulary and rule content. Currently, some of these critical concepts are being resisted because we are not being explicit that they will not appear in an SBVR XMI interchange file. We need some indicator like the "FL" symbol to identify such concpets. SUGGESTED RESOLUTION: Create an indicator "VO" (vocanulary only)and use it like "FL" to identify this kind of concept.

Classes in the SBVR Metamodel are changed to be abstract for cases where there should be no instance in a MOF-based SBVR model that is not an instance of a more specific class. In this way, things and states of affairs in general are excluded from an SBVR model, but the specific kinds of things in the SBVR subject area (like individual concepts and statements) can be included and can be interrelated. The generally defined fact types (e.g., ‘thing is in set’, ‘concept has extension’) will remain useful, but only for relating things that are in the SBVR subject area (e.g., a term is in a vocabulary, a concept is in the extension of a concept type).
The clause 15 files must be changed to reflect that certain classes in the SBVR metamodel are abstract.

ISSUE TITLE: Major Disconnect Between Structural Rule and a Concept's Characteristics and Definition ISSUE DESCRIPTION: There is currently an incomplete and therefore ambiguous connection between 'necessity' (proposition represented by 'necessity statements' in SBVR SE; 'proposition that another proposition is a necessity'), and 'essential characteristic sets' and/or 'implied characteristics'. Without knowing whether a given 'necessity' is intended to specify an 'essential characteristic set' or an 'implied characterisitc' for a given concept, it is not possible to determine what the concept is and whether its intension is correct (i.e. characteristics not in an essential characteristic set are implied by it). This is true for all the concepts that a given 'necessity' applies to. - Need a required way to specify that each 'necessity', for each concept it applies to, either provides the specification for an essential characteristic set or that it does not. If the 'necessity' does not provide the specification for an essential characterisitc set, it must meet the requirements above of being a characteristic implied from each of the essential characteristic sets that create any of the concepts that the 'necessity' applies to. How this is expressed in an SBVR vocabulary must be unambiguous.

Add a section that describe the relationship between structural rules and concepts.

ISSUE TITLE: Some Way is Required to Identify Which Characteristics of a Concept are Referenced in its Definition Directly, or Indirectly Through the More General concept; and Which are Not Butare Instead Implied by the Definition ISSUE DESCRIPTION: The characteristics that are made explicit in an intension in an SBVR vocabulary and that are not in a given essential characteristic set must be able to be implied from that essential characterisitc set plus the other concepts in the semantic community's body of shared meanings related to the concept. Otherwise they cannot be in the intension of the concept. - This requires the ability to ask the question "Is each explicit characteristic that is incorporated into a concept and that is not part of each given essential characterisitc set implied by that essential characteristic set and related concepts in the body of shared meanings?" and to get a consistent answer from members of the semantic community. - to document the assessment that a characteristic can be implied, or simply assert that, the following is required: - 'implied characteristic' - 'essential characteristic set' sufficiently defining 'concept' implies 'characteristic'" (or some other form of this) NOTE: This provides the ability to assess that even though the explicit characteristics in the intensions of two concepts that have equivalent essential characterisitc set are different, the concepts are still equivalent because it can be shown that the explicit implied characteristics in one are also implied in the other. Again no one is saying this must be automated, but it must be possible for people to do consistently or SBVR is without foundation.

Add 'necessary characteristic', 'concept has necessary characteristic', and 'implied characteristic'.

ISSUE TITLE: SBVR Does Not Make It Clear How to Tell Whether Two Concepts are Really the Same Concept or Two Different Ccncepts ISSUE DESCRIPTION: The definition of 'concept' and the concepts it references should together give two people or communities an objective basis for agreeing whether or not two concept entries are really the same concept or two different concepts. The only sound basis for defining (meaning, not representation) concepts is a set of essential (necessary & sufficient) characteristics. This is what creates the concept. If two sets of essential characteristics are equivalent, the two concepts they create are the same concept. - This requires (some binary/ternary form of): - "'characteristic' is essential to 'concept'" - 'essential characterisitc' - "'characterisitc set' sufficiently defines 'concept'" - 'essential characteristic set'. - these SBVR verb concepts must make it clear that it is the set (of essential characteristics) that 'creates' the concept, while necessary characteristics 'make up' a concept individually. - In addition there must be an unambiguous way to identify all the essential characteristics in a concept's essential characterisitc set from the concept's intensional definition and the intensional definitions of all its more general concepts using the more general concept and delimiting characteristics represented by the intensional definition. - In addition determining the equivalence of two essential characterisitc sets requires the ability to assert the equivalence between two characteristics and between a characteristic and a set of characteristics. This is provided in "Issue9613-v5.doc" by: - characteristic1 is equivalent to characteristic2 - characteristic is equivalent to characteristic set - essential characteristic set1 is equivalent to essential characteristic set2 - equivalent set of essential characteristic sets NOTE: There is nothing here that says a tool must be able to do this, but we must have the vocabulary and criteria so that people can do it. If tools do it, so much the better, but it does not need to be required as a tool function by SBVR.

Add explanatory notes to the definitions of 'noun concept' and 'fact type'.
A note added under 'concept incorporates characteristic' in the resolution to Issue 10571 explains what characteristics are incorporated by a concept and that two noun concept definitions define the same concept if they produce the same set of incorporated characteristics.
Note that because 'noun concept' and 'fact type' are defined to be mutually exclusive, there is no confusion about how to tell that two concepts are different if one is a noun concept and the other is a fact type. Note also that is it possible to assert that a concept A and a concept B are the same concept using SBVR's fact type 'thing1 is thing2'.

Have any expression be a bindable target, rather than just a text. Note the referent of the binding is the expression itself, not a meaning of the expression. The reason the initial SBVR submission was limited to ‘text’ is that only ‘text’ expressions occur in XMI. But other sorts of expressions should work just fine if a reference scheme is used.

Change the definition of bindable target to use 'expression' in place of 'text' and add notes to explain the interpretation of a bindable target.

1. "Essential Characterisitc" is not defined as "Necessary and Sufficient Characterisitc" is it is considered to be in ISO 1087 from which it is adopted. 2. "Essential Characteristic" is not defined as it is in ISO 1087 to be the sum of all the Delimiting Characterisitcs up the chain of 'more general concepts' to the top.

1. The entry "characteristic is essential to concept" is synonymous with the entry for "concept incorporated characteristic".
2. 'essential characteristic' is synonymous with 'incorporated characteristic'.
3. 'delimiting characteristic' is related to 'intensional definition' rather than to 'concept'.

ISSUE DESCRIPTION: 1. "'Concept' incorporates 'characteristic'" is ambiguous with respect to the relationship between the characteristics in the intension that makes up a concept that are part of each essential characteristic set that creates the concept, and those that are not. Since there can be many characteristics in the intension (necessary characterisitc set) of a concept that are not, and do not need to be made, explicit in an SBVR vocabulary, "'concept' incorporates 'characteristic'" is additionally ambiguous for the above purposes. Using this SBVR verb concept without the additional language and criteria below gives a false sense of adequacy. - It might be better not to have this fact type so this ambiguity cannot be inadvertently introduced. Otherwise we need a necessity something like "any characterisitc incorporated into a concept must be either in each essential characterisitc set that creates the concept or implied by any essential characteristic set that it is not in".

Add further clarification to the definition of 'concept incorporates characteristic' and add an explanatory note.
Add a second definition for the concept 'definition'.

These simple corrections are combined as one issue.

In 8.1.2 add “FL” to entries for ‘proposition is true’ and ‘proposition is false’.

In 8.3.2 move the second Necessity under ‘definition’ that starts “Each closed projection…” into 9.3 and put it in place of the 7th Necessity under ‘closed projection’ which says the same thing but not as well.

In 8.3.4 move the second Necessity under ‘statement’ that starts “Each closed logical formulation…” into chapter 9 and add it at the bottom under “closed logical formulation” (which is where this Necessity belongs).

In 8.6.1 add “FL” to the entries for ‘concept has extension’ and ‘concept has instance’.

In 8.6.2 in the seventh Necessity which says “Each actuality of a fact type involves some thing in each role of the fact type”, add the words “that is an instance” after the word “actuality”.

In 9.2.3, Figure 9.5, show the inverse reading of “binds to”, which is given in the text as “is bound to”.

In 9.2.7, Figure 9.9, show the inverse reading of “binds to”, which is given in the text as “is bound to”.

In 9.2.8, Figure 9.10, show the inverse reading of “binds to”, which is given in the text as “is bound to”.

In 9.2.9, Figure 9.11, show the inverse reading of “binds to”, which is given in the text as “is bound to”.

In 9.2.9 remove the Necessity under ‘question nominalization’ and the Necessity under ‘answer nominalization’. They are not necessarily true.

In 9.3, remove the first Necessity under ‘closed projection’ (“Each closed projection that defines a fact type is a set projection”). It is not necessarily true.

In 11.2.2, Figure 11.7, show the inverse reading of “is commented on in”, which is given in the text as “comments on”. Or preferably, change “note comments on meaning” to be the preferred fact type form and have no synonymous form – ‘is commented on by’ then becomes the implicit passive voice. The active form ‘comments on’ is used in multiple places. The passive form now given as the primary entry is never used.

In 12.1, remove the second Necessity under ‘element of governance is directly enforceable’ (“An element of governance that is not directly enforceable is not practicable.”). It is plainly does not hold for structural rules.

In 13.1, remove the two footnotes about MOF 2 and XMI for MOF 2 being in finalization. Verify that the names given for the specifications of MOF 2 and XMI for MOF 2 are correct.

In C.1.1.3, change “(often modified to be infinitive)” to “(often modified to be subjunctive)”.

In C.1.2 in the description of “a given”, replace “demonstrative expression” with “logical formulation”. Add the following sentence to the description: “Within a definition, ‘a given’ introduces an auxiliary variable into the closed projection that formalizes the definition.”

Make the recommended changes except for the change to Figure 9.10 which is already handled in the resolution to Issue 9731 and the change to 12.1 which is already handled in the resolution to Issue 9475.

SBVR provides the Integer Namespace having designations for all integers, but SBVR provides no standard means to represent all decimal numbers nor to represent common fractional numbers having Unicode symbols that are common in business expression. A Numbers Namespace is needed in order to support a common means of representing numbers occurring in the formulations of rules and definitions.

Recommendation:

Change “Integer Namespace” to “Number Namespace”. Change its definition to this:

the vocabulary namespace that consists of the following designations for numbers:

1. any sequence of one or more decimal numerals

2. any sequence of zero or more decimal numerals followed by a decimal point and a sequence of one or more decimal numerals

3. any sequence of zero or more decimal numerals followed by a Unicode vulgar fraction

4. any of the above preceded by a minus sign (“-“)

Example: 2, 25, 2.5, .5, ?, 33?, -10.00

Move the note under ‘integer’ to be under ‘number’ and make it refer to the Number Namespace.

Alternatively, is there any ISO standard namespace or other standard namespace that we can refer to using a URI for this purpose?

Remove the Integer Namespace and add the ISO 6093 Number Namespace.

There should be a fact type that relates a vocabulary to a vocabulary namespace. That fact type could be instantiated for any vocabulary whose designations and fact type forms are distinguishable. If this is done, the “vocabulary has URI” fact type can be removed because a vocabulary namespace can have a URI.

Resolved by the Resolution to Issues 9955 and 9941

Scope of Rules & Advices – Body of Shared Guidance – Rule Sets In evaluating SBVR support for ‘dark’ rules, Mark Linehan has observed that it is important to know the precise intended scope of a ‘dark’ rule – that is, what are all the rules and advices it affects. One suggestion for indicating intended scope is the notion of ‘rule sets’. Don Baisley pointed out that SBVR already has a concept that might serve to delimit intended scope – body of shared guidance. The question arises – is that concept as currently defined in SBVR adequate for the purpose? Keri Anderson Healy noted that there is currently no means to specify sub-bodies, which might be useful or necessary for applying the concept for many organizational needs. Ed Barkmeyer and I have both (in our own ways) expressed very strong reservations about the un-SBVR-like way the notion of ‘rule set’ is often understood and used by current rule technologies. Various people, including Ed, have noted the importance of resolving these questions for the sake of consistent interchange. Ed stated, “I think that failing to deal with rule relationships, … and properties of 'bodies of shared guidance' is a failing of SBVR that may become crippling in certain exchange situations.” (However, Ed also stated, “I also think dealing with it now is out of scope for the FTF. All of this is fodder for SBVR v2, if there is ever a v1.” But I believe I disagree with that. Also, emerging resolutions of 10504, 10505 & 10506 are addressing exceptions and priorities, which he also mentions.) In any event, I pointed out that the issue of intended scope for rules and advices does not apply simply to ‘dark’ rules and authorizations, but to the issue of conflicts in general. More precisely, the potential for conflicts exists even without ‘dark’ rules and authorizations. Therefore, the questions above cannot be resolved under 10504, whose scope is merely the former, but requires its own issue.

The Resolution of Issue 10504 has adequately addressed these points.

Under-the-Covers SBVR Support for ‘Dark’ Rules The scope of Issue 10504, which focuses on ‘Dark World’ Assumptions and Authorizations, extends only to section 12, which is the business-facing side of SBVR. A draft resolution is now reasonably well-defined for Issue 10504 (but not finalized), which outlines how ‘dark’ rules and authorizations can be expressed in SBVR-compliant fashion. Mark Linehan has pointed out that the specific mechanisms for SBVR support of ‘dark’ rules and authorizations have not been worked out in SBVR. There seems to be general agreement on that point. Andy Carver has pointed out that Terry addressed the issue in one of the examples in section 10 to some degree. He has suggested that such support could be provided via a new fact type and derivation rule. Discussion of specifics has ensued. I have noted that it appears the derivation rule (and possibly the fact type) could be derived automatically. The current situation is therfore as follows. Evolving resolution of Issue 10504 has now demonstrated the need for some under-the-covers support by SBVR for ‘dark’ rules. However, that support is outside the scope of section 12, which therefore makes it out of scope for Issue 10504. It therefore requires its own issue

The under-the-covers solutions lies in the idea of 'entailment', also known as 'logical implication'. The revised text below adds three fact types that relate elements of guidance to states of affairs based on entailment.

Here are some minor clean-up items needed in chapter 13. These were discovered in two ways: (1) while generating and verifying a MOF metamodel for SBVR and (2) parsing the chapter contents using Unisys Rules Modeler.

In 13.1, the entry labeled “Vocabulary to MOF/XMI Vocabulary” shows “Logical Formulation of Semantics Vocabulary” as an included vocabulary. Actually, the vocabulary that needs to be included is the Meaning and Representation Vocabulary. The reference to the Logical Formulation of Semantics Vocabulary appears to be a remnant of a time before the Meaning and Representation Vocabulary was formed. In 13.1, page 159, under the entry for “Vocabulary to MOF/XMI Vocabulary”, change the paragraph that says:

“Included Vocabulary: Logical Formulation of Semantics Vocabulary”

to say:

“Included Vocabulary: Meaning and Representation Vocabulary”.

Then change the occurrence of “Logical Formulation of Semantics Vocabulary” in the first paragraph of clause 13 to “Meaning and Representation Vocabulary”.

Also, there is a typo: hyphens are missing in the entry heading. The entry heading should say “Vocabulary-to-MOF/XMI Vocabulary” (and also in the index).

A fact type is missing from 13.1 that is used by the rules in 13.3. Add the following at the end of 13.1:

expression1 combines expression2 with expression3

Definition: the expression1 is the result of concatenating the expression2 to the front of the expression3

Two fact types are missing that are used by the rules in 13.3. These should be added after ‘property’ in 13.1.2:

property has lower bound

property has upper bound

In 13.1.3 in the entry for “XMI name”, “XMIname” should be “xmiName” in the Source paragraph and in “org.omg.xmi.XMIname” in the Definition. In 13.1.3 in the entry for “XMI name”, change “XMIname” to “xmiName” in the Source paragraph and in “org.omg.xmi.XMIname” in the Definition.

In 13.3.2, rule 10, change the word “is” to “comes”.

In 13.3.3 in rule 5 replace the words “text that represents” with “expression of”.

In 13.3.3 in rule 6 replace the word “represents” with “is the expression of”.

In 12.3.4 in rule 1 replace “is mapped to” with “maps to” and replace “be mapped to” with “map to”

Also, 13.3.2 (Designation Mapping Rules) does not have a rule about the XMI name for the attribute of an Instantiation subclass. A new rule is needed, similar to the rule for attributes of Fact subclasses, in order for XMI to work properly for Instantiation subclasses. In 13.3.2 add rule 12 as follows:

12. The XMI name of the owned attribute of each class that comes from a designation must be derived from the name of the owned attribute.

Make the recommended corrections.

Exceptions – It has been pointed out by Markus and others that SBVR does not currently address "exceptions" adeqately in its discussion of practicable elements of guidance (e.g., rules). This is a significant omission. I believe this warrants a new section - 12.4. I will circulate a draft separately, as requested by the team in last Wednesday's meeting. Note that resolution to this issue depends on the new 12.3 material on Authorizations. The good news is that as for "Authorizations", nothing new is really required for SBVR.

This Issue was subsumed by Issue 10504 and its Resolution is reflected there.

Clause 12.1 shows that "business rule" is derived from "business policy". A similar relationship should be shown for "advice" (or "advice of permission" or whatever we call it in the resolution of issue 9475) and "business policy".

Consider this example, derived from one given by Ron Ross:

Fact type: person makes payment
Rule Statement: A person may make a payment only if making the payment is expressly permitted for the person.
Advice Statement: A senior manager may make a payment.

How could it be that one of these is derived from business policy but not the other?

Add to clause 12. a fact type "advice is derived from business policy" similar to the existing "business rule is derived from business policy".

Issue: It is unclear from the specification how to formulate a restricted permission or restricted possibility statement. From the definition, of these statements as "... permission (or possibility) being granted only when a given condition is met" it would appear that these statements should be formulated as the permission or possibility modality applied to an implication. However, this formulation would be indistinguishable from a conditional advice of permission or possibility.

Another formulation could be derived from the rephrasing of restricted permission or possibility statements as their corresponding conditional prohibition or impossibility statements.

A third formulation has been suggested by an FTF member as:

if <some condition> then it is permitted (or possible) that <some statement>

... in other words, embedding the permission or possibility modality in the consequence of an implication.

Requested resolution: extend the glossary entries for restricted permission and possibility statements, by adding notes and examples describing the logical formulation of these statement forms. This will avoid confusion among implementers, and support interoperability among tools.

Add an example to the entry for 'obligation formulation'.

ISSUE NAME: Authorizations & Support for "Dark World" Assumptions PROBLEM: The current approach in SBVR is based on a "light world" assumption (everything permitted unless expressly prohibited). As has been pointed out by Mark Linehan and others, there are cases where the opposite assumption ("dark world") is appropriate (everything is prohibited unless expressly permitted), especially for authoization. PROPOSED RESOLUTION: SBVR already has the support necessary for 'dark world' assumptions; it simply needs to be explained and illustrated. I propose the following text be inserted into SBVR at the appropriate point, perhaps in 12.1. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (PROPOSED TEXT TO BE INSERTED) Authorizations SBVR makes a ‘light world’(1) assumption about rules. In a ‘light world’, anything that is not expressly prohibited is assumed permitted. Business rule practice indicates that this choice is the appropriate one for the large majority of business problems. Occasionally, practitioners may discover cases in which the opposite assumption is appropriate. In such ‘dark world’ circumstances, anything not expressly permitted is assumed prohibited. Such cases might involve use of, and/or access to, resources that are deemed especially sensitive, dangerous, scarce, and/or valuable. For that reason, it makes sense to grant permission for use and/or access explicitly. Such permissions are often called “authorizations”. SBVR does not offer any specialized support for authorizations. None is needed. Support for authorizations is accomplished as follows: * A rule is expressed to declare that some general area of business activity is prohibited except where expressly permitted (i.e., ‘dark’). * Specific advices of permission, qualified as appropriate, are given to indicate selective authorizations. The following examples illustrate. Example 1. Fact type: person makes payment ‘Dark’ Rule Statement: A person may make a payment only if making the payment is expressly permitted for the person. Advice of Permission Statements: * A senior manager may make a payment. Note: This rule statement could also be expressed: A person may make a payment if the person is a senior manager. * Jane Smith may make a payment. Note: This rule statement could also be expressed: A person may make a payment if the person is “Jane Smith”. Example 2. Fact type: ice road is used by vehicle ‘Dark’ Rule Statement: An ice road may be used by a vehicle only if using the ice road is expressly permitted. Advice of Permission Statements: * An ice road may be used by a vehicle if the ice road is north of the arctic circle. * The ice road with the name, Yukon 12,000 Foot Lake Road, may be used by a vehicle. * An ice road may be used by a vehicle if the average temperature at the southern-most point has been below 0o C for at least 5 days. 1 (footnote) Ronald G. Ross, "The Light World vs. the Dark World ~ Business Rules for Authorization," Business Rules Journal, Vol. 5, No. 8 (August 2004), URL: http://www.BRCommunity.com/a2004/b201.html

No Data Available

Universal AND – SBVR assumes a universl AND between all elements of guidance stated separately/individually, but doesn't say so explicitly in Clause 12. This problem was noted in last week's meeting, and I was requested to create an issue and proposed resolution for it.

This Issue was subsumed by Issue 10504 and its Resolution is reflected there.

SBVR makes a 'light world' assumption about rules. In a 'light world', anything that is not expressly prohibited is assumed permitted. Business rule practice indicates that this choice is the appropriate one for the large majority of business problems.
Occasionally, practitioners may discover cases in which the opposite assumption is appropriate. In such 'dark world' circumstances, anything not expressly permitted is assumed prohibited. Such cases might involve use of, and/or access to, resources that are deemed especially sensitive, dangerous, scarce, and/or valuable. For that reason, it makes sense to grant permission for use and/or access explicitly. Such permissions are often called "authorizations".
SBVR does not offer any specialized support for authorizations. None is needed. Support for authorizations is accomplished as follows:
· A rule is expressed to declare that some general area of business activity is prohibited except where expressly permitted (i.e., 'dark').
· Specific advices of permission, qualified as appropriate, are given to indicate selective authorizations.
The following examples illustrate.
Example 1.
Fact type: person makes payment
'Dark' Rule Statement: A person may make a payment only if making the payment is expressly permitted for the person.
Advice of Permission Statements:
· A senior manager may make a payment.
Note: This rule statement could also be expressed: A person may make a payment if the person is a senior manager.
· Jane Smith may make a payment.
Note: This rule statement could also be expressed: A person may make a payment if the person is "Jane Smith".
Example 2.
Fact type: ice road is used by vehicle
'Dark' Rule Statement: An ice road may be used by a vehicle only if using the ice road is expressly permitted.
Advice of Permission Statements:
· An ice road may be used by a vehicle if the ice road is north of the arctic circle.
· The ice road with the name, Yukon 12,000 Foot Lake Road, may be used by a vehicle.
· An ice road may be used by a vehicle if the average temperature at the southern-most point has been below 0o C for at least 5 days.

Add the new subsections below to the end of Clause 12.
Note that the material below incorporates the material agreed for Issue 10562, and this Resolution indicates the placement of that material.
Note also that this Resolution subsumes and completes Issues 10505 and 10506.

Basing Clause 12 Vocabulary on Clause 10 Vocabulary. The structure of SBVR features layering from surface expression to deep meaning, independent of surface expression. Based on recent work, SBVR will now have a Clause 10 (especially modalities) that will express all concepts from pure logic needed for Clause 12 (rules, etc.). So the entries for Clause 12 should all be based on the vocabulary of Clause 10, rather than the vocabulary of Clause 9, which is more in the nature of engineering specifications.

This issue is resolved by the resolutions of issues 9475 and 9945, which change Clause 12 such that Clause 10 terms for modalities are used in definitions of the concepts 'rule' and 'advice' along with specializations of those concepts. No further changes are needed.

Location: SBVR Clause 10.1.1.4, last sentence of the paragraph following Table 10.2 (p. 86).

Issue: This sentence has an error.

In principle, these rules could be used with double negation to get by with just one alethic modal operator (e.g., ...

Proposed Resolution: Change sentence to:

In principle, these rules could be used with double negation to get by with just one alethic and one deontic operator (e.g., ...

Correct the sentence.

Examples in the normative part of the specification should be given using the "SBVR Structured English" expression form described in Annex C. This avoids confusion by using one way to express the examples.

It may be desirable in some cases to provide alternative expressive forms of some examples. Such cases should be clearly labelled as using RuleSpeak (Annex F) or UML Notation (Annex H) or whatever. Such cases should also always be additional to giving the same examples in "SBVR Structured English" so that readers will not be forced to learn these alternative forms in order to understand the examples.

Note: this issue is NOT requesting that examples always be given in prefix form. Mixed-fix form is described in Annex C and thus should be fine for use in examples.

Specific sections that should be addressed in this issue include:

clause 12.1.2 in the entry for "business policy"
clause 12.1.4 in the entry for "admonition"
clause 12.1.4 in the entry for "affirmation"
clause 12.2.1 in the entry for "admonition statement"
clause 12.2.1 in the entry for "affirmation statement"
clause 12.2.2 in the entry for "impossibility business rule statement"
clause 12.2.2 in the entry for "restricted possibility business rule statement"

I scanned all the other examples in the normative section of the specification, and in Annexes C and E. There are remarkably few rule examples. The list above identifies the ones I could find that are not expressed in "SBVR-SE".

Examples will remain in natural language and not be styled based on SBVR Structured English or any other notation. A note is added to explain that natural language is used for examples.

There is some clean up needed with respect to completing changes introduced by previously accepted issue resolutions and which come from reading the updated interim specification. The clean up is combined here as one issue.

Per the accepted resolution of Issue 9467, implicit passive forms are not supposed to be explicitly shown in the SBVR specification. Many of these were removed in the editing instructions of that issue. There are some others that were missed:

Remove “Synonymous Form: concept is ranged over by variable”.

Change “Synonymous Form: bindable target is referenced by role binding” to “Synonymous Form: role binding references bindable target”, and change Figure 9.4 accordingly.

Remove “Synonymous Form: variable is introduced by quantification”.

Remove “Synonymous Form: quantification is restricted by logical formulation”.

Remove “Synonymous Form: logical formulation is scoped over by quantification”.

Remove “Synonymous Form: logical formulation is considered by objectification”.

Remove “Synonymous Form: logical formulation is considered by proposition nominalization”.

Remove “Synonymous Form: projection is constrained by logical formulation”.

Remove “Synonymous Form: definition is formalized by closed projection”.

Remove “Synonymous Form: concept is defined by closed projection”.

Remove “Synonymous Form: question is meant by closed projection”.

Replace the entry “speech community is of semantic community” with “semantic community has speech community” and then remove “Synonymous Form: semantic community has speech community”.

Replace the entry “subcommunity is of community” with “community has subcommunity” and then remove “Synonymous Form: community has subcommunity”.

The synonymous form ‘note comments on concept’ was missed in the resolution of Issue 9934. It needs to be changed to ‘note comments on meaning’.

Change “Synonymous Form: note comments on concept” to

“Synonymous Form: note comments on meaning” per Issue 9934.

In the definition of ‘necessity’, “fact” needs to be changed to “proposition”, and Figure 8.1 needs to be changed accordingly. This was widely agreed in light of the resolution to issue 9882.

In the first paragraph of clause 9 on page 37, the words “conjuncts, disjuncts, negands” are used, but those have been removed from the clause 9 vocabulary by the resolution to issue 9258. I recommend that the words be replaced (such as by “disjunction”) so that the concepts given by way of example in that paragraph are representative of actual content of clause 9.

Also in the introduction to clause 9, but in the middle of page 38 in the paragraph that starts, “Within the one …”, the final statement needs a little editing to be clear (no change in meaning). Change the sentence that says:

But the obligation claim has a meaning (the rule), and even the logical universal quantification within the obligation claim each has a meaning because each of those two formulations is closed.

to say this:

But the obligation claim has a meaning (the rule) and so does the universal quantification within the obligation claim because both are closed.

On page 39 in the last paragraph of the introduction to clause 9 that starts, “A propositional nominalization is …”, the last sentence can be made more clear and grammatically correct with some minor editing. Change the sentence that says:

Furthermore, rules about change often involve concept formulations, which are special formulations that allow concepts to be a subject or object of a proposition in much the same way that proposition nominalization allows propositions to a subject or object.

to say this:

Furthermore, rules about change often involve concept formulations, which are special formulations that allow a concept to be a subject or object of a proposition in much the same way that proposition nominalization allows a proposition to be a subject or object.

Make all of the recommended changes with the exception of the change in the definition of 'necessity' which must be considered when addressing Issue 9721.

Annex C.1.1.3 includes the following text about "only if"

The key word phrase “only if” is used in combination with some of the key words and phrases shown above to invert a modality.

… may … only if p obligation claim over an implication
it is permitted that q only if p obligation claim over an implication
it is possible that q only if p necessity claim over an implication

The key word “only” can also be used with “may” in an expression before a preposition to invert a modality.

… may … only … obligation claim over an implication

However, there is nothing to explain what is meant by "invert a modality". This section should be extended to define "invert a modality", for example

it is permitted that q only if p (apparently) is equivalent to it is obligatory that p if q

And an example would help.

Without this material, different readers undoubtly will interpret the concept "invert a modality" differently. For example, it would be reasonable to assume this is the same as "negate a modality" and then assume that the text about (for example) "obligation claim over an implication" must be ignored as being inconsistent.

Show modal inversions caused by using the word "only" in terms of equivalences and examples.

In the Interim SBVR specification, in H.4.3 (Term for a Role in a Form of Expression), page 323-324, the first example does not match SBVR, which has ‘characteristic’, not as a role of ‘unary fact type’, but as a synonym. A different example is needed to illustrate the point being explained.

Remove the first (the erroneous) example from Figure H.12 and adjust the explanatory paragraphs accordingly.

The discussion of 'reference scheme uses characteristic' on page 29 or 30 in section 8.4 is poorly worded and confusing:

• The diagram and text can be misread to imply that a reference scheme can be based solely on a characteristic. Perhaps there should be a necessity
  rule along the lines of "Each reference scheme simply uses at least one role or each reference scheme extensionally uses at least one role" and
  a possibility rule such as "Each reference scheme uses some characteristics".

• The Note is garbled, where it says "Using a characteristic in a reference scheme is equivalent to using a binary fact type with a Boolean role whose
  value is true then ...." This could be misread as saying that using a characteristic is equivalent to using a binary fact type, which of course is not true.
  Or one could parse this as "a binary fact type with a Boolean role" which also doesn't make sense. What's really meant is something like "... using a
  binary fact type in conjunction with a Boolean role ...."

• The last sentence of the Note doesn't make sense. It says "But business vocabularies don't tend to define binary relationships to Booleans, but, rather,
  they define characteristics." Booleans are unary (not binary) fact types. So what would it mean to "define binary relationships to Booleans?

Clarify the notes under "reference scheme" and "reference scheme uses characteristic". Add examples of references schemes and of references based on them.

A quick search of the Final Adopted Specification shows that the terms 'term' and 'symbol' are consistently used to mean 'signifier'. This view is clearly outlined in Annex A.3.4:
SBVR supports mapping of business meaning to concrete language by associating elements of the body of shared meanings with signifiers, e.g., terms such as “customer”, “car”, “branch” for concepts, and fact symbols (often verb phrases) such as “rents”, “is located at” for fact types. Logical formulations provide the structure, and signifiers are placed in logical formulations to provide the expression.

So what Don meant was that a "fact symbol" is an expression that means a fact type. Note please that
an expression that means a fact type
and
the representation of a fact type by an expression
are lingustically entirely different things. The first is a noun concept that refers to a thing characterized by its use. The second is a noun concept that refers to a state of affairs – a relationship – that involves two kinds of thing. The second is a nominalization (gerund) of
expression represents fact type

In ISO, in the NODE, and in Merriam-Webster, 'term' is defined to be an expression or a sign, whereas (in M-W) 'designation' (4) is the relationship and 'designation' (3) is the expression.

It was my perception (when I reviewed the penultimate revised proposal for SBVR) that 'representation' and 'designation' are consistently used in SBVR to mean the relationship of expression to meaning, rather than the expression itself. A quick search reveals the following possibly inconsistent usages:

In Table

Under 'form of expression' several Examples speak of "the designation 'rents'" and others, and the Note refers to forms of expression involving designations.

'placeholder' is said to be a representation (relationship) but it has a "starting character position". This appears to be assigning the attribute to the wrong object. It is rather the (sub-)expression of the placeholder that has the starting character position.

In 'placeholder uses designation', the Synonymous Form should probably be "is used by" or "is used in" rather than "is used for".

Under 'role namespace', "a designation ... is typically a role" is clearly wrong. And "a designation ... can be for a characteristic" should be "can designate". And "the designation 'assigned'", etc., is inconsistent.

Under 'integer', "designations for all of the integers" should be "designations of ..."

In the introduction to Clause 9, "designations like 'rental' ... are used to refer to concepts" seems also to mean the thing and not the relationship.

In 11.2.1, symbol and all of its subtypes are said to be representations, and that might be made consistent with the SBVR definition with enough weasel wording, but it is completely at odds with the terminology of linguistics and semiotics, and the DictionaryBasis confirms that: "a thing representing ..."

This issue is resolved by the resolution to issue 9952.

Based on the Feb. 23 FTF meeting, I retracted a correction that I had sent in for the RuleSpeak Annex, as below. It was pointed out that my correction was improperly worded (especially regarding "represented"), and that the phrase did not convey my actual intent. *** Replace "if all roles for" with: *** "If all noun concepts represented by roles for" The correct phrasing may need to reference "fundamental concepts". In any event, the correct wording involves a larger issue than simply RuleSpeak, or the specific point I was making here.

Provide clear wording of the appropriate criteria