Semantics Of Business Vocabulary And Rules Avatar
  1. OMG Specification

Semantics Of Business Vocabulary And Rules — Closed Issues

  • Acronym: SBVR
  • Issues Count: 156
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SBVR_-60 'state of affairs' is an individual concept, not a thing SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-59 Definition of 'fact type' SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-58 Vocabulary should be mandatory SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-57 Two SBVR Normative Definitions Use Deontic Logic in Error SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-56 No Way to Specify What the Instance of an Individual Concept Is SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-55 SBVR Issue - "is" vs. "equals" SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-54 implicit passive form for partitive fact type that uses the verb "includes" SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-53 The unary fact type/characteristic "category is inactive" SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-52 definition of 'prohibited symbol' SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-51 Rule-Set is not a defined concept SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-50 URI is not a role SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-49 Align Annex E with the normative text SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-48 Closed logical formulation formalizes statement SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-47 Section: 12.1.2 & 12.2.1 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-46 SBVR Issue - Restrictions on Variables SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-45 Section: 12.1.1 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-44 Section: 11.1.1.1 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-43 Distinguish Between Concepts SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-42 Major Disconnect Between Structural Rule and a Concept's Characteristics SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-41 Section: 8.1.1 (02) SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-40 Section: 8.1.1 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-39 SBVR Does Not Adopt ISO 1087 "Essential Charactertic" Fully and Correctly SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-38 "'Concept' incorporates 'characteristic'" is ambiguous SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-37 ‘expression’ as a bindable target SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-36 Simple Fixes - editorial issues SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-35 Number Namespace SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-34 Relating Vocabularies to Namespaces SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-33 Scope of Rules & Advices – Body of Shared Guidance SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-32 Under-the-Covers SBVR Support for ‘Dark’ Rules SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-31 SBVR Issue: MOF/XMI Vocabulary and Rules Cleanup SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-30 SBVR Issue -- Relationship between "Business Policy" and "Advice" SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-29 Logical Formulation of Restricted Permission and Possibility Statements SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-28 Authorizations & Support for "Dark World" Assumptions SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-27 Exceptions SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-26 Universal AND SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-25 SBVR Issue on Authorizations / Dark World Assumptions SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-24 Section: 10 & 12 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-23 Error in sentence on double negation SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-22 SBVR Issue - Annex C.1.1.3 "only if" SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-21 Examples in the normative part of spec should use SBVR Structured English SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-20 Clean Up based on resolution of issue 9467, 9258, 9934, 9882 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-19 H.4.3 (Term for a Role in a Form of Expression), page 323-324 SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-18 clarification needed for 'reference scheme uses characteristic' SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-17 use of 'designation', definition of 'term' SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR_-16 Section: Section F.2.1.2 (RuleSpeak Annex) SBVR 1.0b2 SBVR 1.0 Resolved closed
SBVR-126 Mysteries & miscellany SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-125 Unnecessary Necessities SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-124 Corrected Fig. 11.6 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-123 corrected Figure 11.2 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-122 One global change too far SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-121 Correct the leading term of definition SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-120 Correct styling in characteristic SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-119 1. swap the sequence of two entries SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-118 SBVR Annex E minor corrections SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-117 In 8.7 in the definition of “cardinality”, remove the word “distinct” SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-116 Section 9.3 editorial SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-115 Section 9.2.5 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-114 SBVR Issue: OMG URLs SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-113 Sjir Nijssen Revisions to Clause 10 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-112 NIAM Annex SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-111 "Definition of Category" SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-110 Making Annex A Normative -- No Connection with SBVR Definitions SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-109 Location of and Notation for Formal Logic Grounding Examples SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-108 Making Annex A Normative SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-107 Association Names in UML Diagrams SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-106 Section: Clause 10 pages 71 - 108 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-105 Section: 8.3.4 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-104 Section: Clause 2 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-103 Section: 11.1.1 pages 110 - 113 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-102 Section: 11.1.1 page 112 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-101 Section: 8.1.1 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-100 Section: 8.3.5, 11.1.1, 11.2.1 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-99 Section: Annex C SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-98 Section: F.2.2 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-97 Section 2.2.1.1.1 Fac Type: "concept1 specializes concept2" SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-96 SBVR Issue - Projection Diagram - Variable Maps to Role SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-95 “Admonition” and “Affirmation” are the same concept SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-94 Section: 11.2.1.3 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-93 Section: 8 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-92 Section: 8.3, + 11.2 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-91 SBVR Issue - Logical Formulation Kinds of Quantifications SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-90 ‘vocabulary has URI’ SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-89 SBVR Issue - 'role has role binding' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-88 SBVR Issue - Bug in Namespaces Diagram SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-87 SBVR Issue - Concept Expression versus Meaning Expression SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-86 SBVR Issue - Is a representation an actuality? SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-85 SBVR Issue - 'meaning has representation' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-84 Section 1 - modeling based on MOF does not have all of the capabilities SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-83 Note and Example for “text is for placeholder” SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-82 Define ‘true’ and ‘false’ SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-81 Annex E - editorial issues SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-80 SBVR Issue: What is concept1? SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-79 Thing’ Defined Tentatively SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-78 wrong proposition in 8.1.2 and modal formulation SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-77 Correct specification of question and answer nominalization SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-76 Complete support for question nominalization SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-75 Correct glossary entry for proposition nominalization SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-74 Meaning of fact-type formulation and fact type projection SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-73 bindable target should be 'constant' not 'text' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-72 True/False meaning of logical formulations must be specified SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-71 Meaning of noun concept formulation SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-70 What is an aggregation formulation? SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-69 What is a projecting formulation? SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-68 Meaning of objectification is unclear SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-67 quantifications based on cardinality SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-66 Quantification definitions SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-65 SBVR Issue - wrong proposition in 8.1.2 and modal formulation SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-64 Definition of 'proposition' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-63 Use of 'modality' in 8.1.2 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-62 Projection position and reference scheme for variables SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-61 Definitions of 'projection' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-60 Definition of Body of Shared Guidance SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-59 SBVR Issue - Circular definition of logical operator and logical operand SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-58 business jurisdiction SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-57 What is the "business vocabulary" in 10.3 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-56 Mapping SBVR logical formulation terms to formal logic terms SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-55 Annex E/EU-Rent vocabulary's 'characteristic' entries SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-54 dictionary basis SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-53 Chapters 8,9,11,12 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-52 A fact is not a logical formulation SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-51 Clarification Remnants SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-50 Body of Shared Meanings SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-49 Binding to Individual Concepts SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-48 Page: 296 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-47 "Logic Rule" issue SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-46 The current notion of "actionable" falls short in several regards SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-45 Interchange issue SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-44 missing definitions SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-43 SBVR vocabularies SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-42 XMI has some internal inconsistencies SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-41 XMI in bei/05-08-02 and representing many vocabulary and rules aspects SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-40 supporting documents SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-39 specification does not address the mapping of rules to MOF and XMI SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-38 XML Schema and Namespace URIs SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-37 Implicit Passive Forms SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-36 Use Plural Rather than “Set of Each” SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-35 Synonymous Statement SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-34 Bad Example of Extensional Definition SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-33 XMI Names for ESBVR SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-32 Symbolization Diagram Error SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-31 Fact Type Templating Diagram Error SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-30 Tie Category and More General Concept to a Fact Type SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-29 Unnecessary Grammatical Structure SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-28 Reference Scheme’s Reference Scheme is Incomplete SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-27 Individual Concept Not Necessarily a Noun Concept SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-26 10 Examples - applying a standard pattern in the "10 Examples" SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-25 SBVR-FTF Issue: 10 Example Rules material SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-24 Add (and explain) styling for 90 days where it appears in formal statement SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-23 Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-22 Add 'Synonym: aspect' caption SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-21 Chapter 12 page 139: Add Synonyms SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-20 Issue: Improve linkage to Rule/Business Rule in 10.1.1 Narrative SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-19 description of the type theory of SBVR needs to be included in 10.1.1 SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-18 define 'is less than' on 'quantity' SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-17 Logical formulations are fact-types SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-16 Fact-types and templates (and subscripts) SBVR 1.0b1 SBVR 1.0b2 Resolved closed

Issues Descriptions

'state of affairs' is an individual concept, not a thing

  • Key: SBVR_-60
  • Legacy Issue Number: 10803
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Mon, 5 Mar 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Definition of 'fact type'

  • Key: SBVR_-59
  • Legacy Issue Number: 10801
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Mon, 5 Mar 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Vocabulary should be mandatory

  • Key: SBVR_-58
  • Legacy Issue Number: 10800
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Mon, 5 Mar 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Resolved by the Resolution to Issue 9955.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Two SBVR Normative Definitions Use Deontic Logic in Error

  • Key: SBVR_-57
  • Legacy Issue Number: 10798
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Fri, 2 Mar 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

No Way to Specify What the Instance of an Individual Concept Is

  • Key: SBVR_-56
  • Legacy Issue Number: 10790
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SBVR Issue - "is" vs. "equals"

  • Key: SBVR_-55
  • Legacy Issue Number: 10779
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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”.

  • Reported: SBVR 1.0b2 — Mon, 26 Feb 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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'.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

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

  • Key: SBVR_-54
  • Legacy Issue Number: 10639
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    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)

  • Reported: SBVR 1.0b2 — Fri, 2 Feb 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

The unary fact type/characteristic "category is inactive"

  • Key: SBVR_-53
  • Legacy Issue Number: 10633
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Sun, 28 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

definition of 'prohibited symbol'

  • Key: SBVR_-52
  • Legacy Issue Number: 10632
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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"

  • Reported: SBVR 1.0b2 — Fri, 26 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Rule-Set is not a defined concept

  • Key: SBVR_-51
  • Legacy Issue Number: 10630
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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"

  • Reported: SBVR 1.0b2 — Fri, 26 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

URI is not a role

  • Key: SBVR_-50
  • Legacy Issue Number: 10629
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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"

  • Reported: SBVR 1.0b2 — Fri, 26 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Align Annex E with the normative text

  • Key: SBVR_-49
  • Legacy Issue Number: 10628
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 26 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Closed logical formulation formalizes statement

  • Key: SBVR_-48
  • Legacy Issue Number: 10622
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Wed, 24 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Section: 12.1.2 & 12.2.1

  • Key: SBVR_-47
  • Legacy Issue Number: 10620
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Tue, 23 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Resolved by the resolutions to Issues 10571-10575

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SBVR Issue - Restrictions on Variables

  • Key: SBVR_-46
  • Legacy Issue Number: 10596
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Thu, 18 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Section: 12.1.1

  • Key: SBVR_-45
  • Legacy Issue Number: 10580
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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".

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Replace "decided or calculated" with "understood".

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Section: 11.1.1.1

  • Key: SBVR_-44
  • Legacy Issue Number: 10578
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Distinguish Between Concepts

  • Key: SBVR_-43
  • Legacy Issue Number: 10577
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Major Disconnect Between Structural Rule and a Concept's Characteristics

  • Key: SBVR_-42
  • Legacy Issue Number: 10575
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Section: 8.1.1 (02)

  • Key: SBVR_-41
  • Legacy Issue Number: 10574
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Section: 8.1.1

  • Key: SBVR_-40
  • Legacy Issue Number: 10573
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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'.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SBVR Does Not Adopt ISO 1087 "Essential Charactertic" Fully and Correctly

  • Key: SBVR_-39
  • Legacy Issue Number: 10572
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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'.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

"'Concept' incorporates 'characteristic'" is ambiguous

  • Key: SBVR_-38
  • Legacy Issue Number: 10571
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    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".

  • Reported: SBVR 1.0b2 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

‘expression’ as a bindable target

  • Key: SBVR_-37
  • Legacy Issue Number: 10570
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Thu, 4 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Simple Fixes - editorial issues

  • Key: SBVR_-36
  • Legacy Issue Number: 10569
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.”

  • Reported: SBVR 1.0b2 — Thu, 4 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Number Namespace

  • Key: SBVR_-35
  • Legacy Issue Number: 10568
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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?

  • Reported: SBVR 1.0b2 — Thu, 4 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Relating Vocabularies to Namespaces

  • Key: SBVR_-34
  • Legacy Issue Number: 10567
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Thu, 4 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Resolved by the Resolution to Issues 9955 and 9941

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Scope of Rules & Advices – Body of Shared Guidance

  • Key: SBVR_-33
  • Legacy Issue Number: 10563
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Thu, 4 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    The Resolution of Issue 10504 has adequately addressed these points.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Under-the-Covers SBVR Support for ‘Dark’ Rules

  • Key: SBVR_-32
  • Legacy Issue Number: 10562
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Wed, 3 Jan 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SBVR Issue: MOF/XMI Vocabulary and Rules Cleanup

  • Key: SBVR_-31
  • Legacy Issue Number: 10528
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Wed, 6 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Make the recommended corrections.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

SBVR Issue -- Relationship between "Business Policy" and "Advice"

  • Key: SBVR_-30
  • Legacy Issue Number: 10525
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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?

  • Reported: SBVR 1.0b2 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Logical Formulation of Restricted Permission and Possibility Statements

  • Key: SBVR_-29
  • Legacy Issue Number: 10523
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Tue, 12 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Authorizations & Support for "Dark World" Assumptions

  • Key: SBVR_-28
  • Legacy Issue Number: 10508
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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

  • Reported: SBVR 1.0b2 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Exceptions

  • Key: SBVR_-27
  • Legacy Issue Number: 10506
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Sun, 17 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Universal AND

  • Key: SBVR_-26
  • Legacy Issue Number: 10505
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Mon, 18 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

SBVR Issue on Authorizations / Dark World Assumptions

  • Key: SBVR_-25
  • Legacy Issue Number: 10504
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Section: 10 & 12

  • Key: SBVR_-24
  • Legacy Issue Number: 10470
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Wed, 22 Nov 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Error in sentence on double negation

  • Key: SBVR_-23
  • Legacy Issue Number: 10444
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    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., ...

  • Reported: SBVR 1.0b2 — Sun, 29 Oct 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Correct the sentence.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

SBVR Issue - Annex C.1.1.3 "only if"

  • Key: SBVR_-22
  • Legacy Issue Number: 10443
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Mon, 6 Nov 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Examples in the normative part of spec should use SBVR Structured English

  • Key: SBVR_-21
  • Legacy Issue Number: 10442
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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".

  • Reported: SBVR 1.0b2 — Mon, 6 Nov 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Clean Up based on resolution of issue 9467, 9258, 9934, 9882

  • Key: SBVR_-20
  • Legacy Issue Number: 10423
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Tue, 24 Oct 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

H.4.3 (Term for a Role in a Form of Expression), page 323-324

  • Key: SBVR_-19
  • Legacy Issue Number: 10422
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Tue, 24 Oct 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

clarification needed for 'reference scheme uses characteristic'

  • Key: SBVR_-18
  • Legacy Issue Number: 10377
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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?
  • Reported: SBVR 1.0b2 — Fri, 29 Sep 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:55 GMT

use of 'designation', definition of 'term'

  • Key: SBVR_-17
  • Legacy Issue Number: 10099
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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 ..."

  • Reported: SBVR 1.0b2 — Wed, 9 Aug 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    This issue is resolved by the resolution to issue 9952.

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Section: Section F.2.1.2 (RuleSpeak Annex)

  • Key: SBVR_-16
  • Legacy Issue Number: 9399
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    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.

  • Reported: SBVR 1.0b2 — Sat, 25 Feb 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0
  • Disposition Summary:

    Provide clear wording of the appropriate criteria

  • Updated: Sat, 7 Mar 2015 08:55 GMT

Mysteries & miscellany

  • Key: SBVR-126
  • Legacy Issue Number: 11300
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    Issue 10504 (Ballot 8) gave an instruction to add a Definition clause to an existing entry, but the Edit Instruction indicated the wrong Clause location of that existing entry. This resulted in duplicate fact types for "body of shared meanings includes body of shared guidance" in Clauses 11 and 12.

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Correct this by removing the entry from Clause 11 and adding the Definition text (specified by Issue 10504's Resolution) to the intended, existing entry in Clause 12

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Unnecessary Necessities

  • Key: SBVR-125
  • Legacy Issue Number: 11299
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    When "nonverbal designation" was added into the taxonomy, the Necessities specifying its mutual exclusivity with 'term' and 'name' were provided. Since it is now a category of 'nonverbal designation', 'icon' no longer needs to specify this as well. On p. 184, delete the two Necessities shown under "icon".

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove the two Necessities from the entry for "icon".

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Corrected Fig. 11.6

  • Key: SBVR-124
  • Legacy Issue Number: 11298
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    Two text changes from the global change ('symbol' to 'designation') were made in the text (see p. 181) but missed in the corresponding fact types in the Figure. Replace Fig. 11.6 (p. 180) with this: (email to issue 11298

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Replace Fig. 11.6 with one that reflects the correct wording of the two fact types (i.e., to match the text entries).

  • Updated: Fri, 6 Mar 2015 22:56 GMT

corrected Figure 11.2

  • Key: SBVR-123
  • Legacy Issue Number: 11297
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    The entry for 'general concept' was removed from Clause 11; accordingly, the box for it should be shaded. Replace Fig. 11.2 (p. 164) with this: figure attached to issue 11297 email

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Replace Fig. 11.2 with one showing a shaded box for 'general concept'.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

One global change too far

  • Key: SBVR-122
  • Legacy Issue Number: 11295
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    The "change all" of 'symbol' to 'designation' specified that 'fact symbol' was to be left unchanged. Revert the following two changes.

    • On p. 184, change the entry now shown as "fact designation" back to "fact symbol".
    • On p. 270, undo the strike-out of "fact symbols" (and its replacement with "designations").
      P One global change too far er Issue 9941: In clause 11 REPLACE each remaining occurrence of "symbol" with "designation" (including plural cases), keeping font and capitalization the same, EXCEPT RETAIN "fact symbol" unchanged, everywhere (including in its plural form "fact symbols").
  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Correct the leading term of definition

  • Key: SBVR-121
  • Legacy Issue Number: 11294
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    On p. 184, in the entry for "icon", the leading term should be "nonverbal designation" (not simply "designation").
    Per Issue 9941: In the definition of 'icon' (as updated in the resolution to Issue 9952) REPLACE 'designation' with 'nonverbal designation'.

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Correct styling in characteristic

  • Key: SBVR-120
  • Legacy Issue Number: 11293
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    On p. 171, in the entry for "definition serves as designation", the text for "serves as designation" should be entirely styled using verb styling.
    Per Issue 9952: In 11.1.3 REPLACE the entry for 'definition is used as term of concept' with this:
    definition serves as designation
    Definition: the definition acts as a designation of the concept defined by the definition
    Note: In the case of a concept for which no designation is given, the concept is represented by its definition.

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

1. swap the sequence of two entries

  • Key: SBVR-119
  • Legacy Issue Number: 11292
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    Multiple changes (different Issues) resulted in ambiguous instructions for placement of entries. On p. 169, move the new entry for "definite description" to follow the entry for "intensional definition uses delimiting characteristic".

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

SBVR Annex E minor corrections

  • Key: SBVR-118
  • Legacy Issue Number: 11291
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    In the final read through of Annex E (EU-Rent example) a few errors of content were noticed.
    Corrections are given below.

    Revised Text:
    E.2.2.1.1: rental car is assigned to car movement
    Necessity:
    replace "…car movement is of the car model …"
    with "…car movement is of some car model …"
    E2.2.1.2: transfer drop-off branch
    Definition:
    replace "branch from which the transferred car of a car transfer is picked up"
    with "branch at which the transferred car of a car transfer is dropped off"
    E.2.2.1.5: pick-up branch
    Necessity:
    replace "The pick-up branch of a rental may not be changed."
    with "The pick-up branch of a rental is not changed."
    E.2.2.1.5: rental
    Definition:
    replace "… specifying use of a car of a car group…"
    with "… specifying use of some car of a car group…"
    E.2.2.1.9 drop-off branch
    replace Necessity "A car may be returned to a location other than …"
    with Note "A car may be returned to a branch other than …"
    E.2.2.1.10 rental car is of car model
    Insert new entry immediately following:
    rental car is of car group
    Concept Type: associative fact type
    Necessity: A rental car is of a car group if and only if the rental car is of some car model that is included in the car group.
    E.2.2.1.11 renter is responsible for rental
    Necessity
    Replace "The renter of a rental may not be changed"
    With "The renter of a rental is not changed"
    E.2.2.2.5 Page 380, second rule
    Rule statement
    Replace "If the actual pick-up date/time of each rental is after the end date/time …"
    With "If the actual return date/time of a rental is after the end date/time …"
    Supporting fact types
    Replace "rental has actual pick-up date/time"
    With "rental has actual return date/time"
    Related facts
    Delete "the noun concept 'actual pick-up date/time' is a role that ranges over the noun concept 'date/time'"
    E.2.2.2.11.2 First rule
    Rule statement
    Replace "… is provisionally charged to a credit card …"
    With "… is provisionally charged to some credit card …"

    Repeated error in Necessity for inclusion in a segmentation
    In several places the Necessity is incorrectly stated as
    "aaa is included in Bbbbbbb" instead of
    "The concept 'aaa' is included in Bbbbbbb".
    For example, in E.2.2.1.3, city branch:
    replace "city branch is included in Branches by Type."
    with "The concept 'city branch' is included in Branches by Type."
    The same change needs to be made for:
    E.2.2.1.6 in-country one-way rental
    E.2.2.1.6 in-country rental
    E.2.2.1.6 international rental
    E.2.2.1.6 international inward rental
    E.2.2.1.6 international outward rental
    E.2.2.1.6 local one-way rental
    E.2.2.1.6 round-trip rental
    E.2.2.1.6 walk-in rental
    E.2.2.1.7 cash rental
    E.2.2.1.7 cash rental price
    E.2.2.1.7 driver charge
    E.2.2.1.7 extras charge
    E.2.2.1.7 penalty charge
    E.2.2.1.7 points rental
    E.2.2.1.7 points rental price
    E.2.2.1.11 corporate renter
    E.2.2.1.11 individual customer

    Characteristics used to define states.
    There is a mixture of use of the verb form and the gerund form. The verb form seems better for states. The changes are:
    Section Replace With
    E.2.2.1.6 advance rental being assigned advance rental is assigned
    E.2.2.1.6 advance rental being reserved advance rental is reserved
    E.2.2.1.6 rental being returned rental is returned
    E.2.2.1.9 rental being late rental is late
    E.2.2.1.9 rental being overdue rental is overdue
    E.2.2.1.9 rental car being in need of repair rental car is in need of repair
    E.2.2.1.9 rental car being in need of service rental car is in need of service
    E.2.2.1.9 driver being barred driver is barred

    Disposition: Resolved

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

In 8.7 in the definition of “cardinality”, remove the word “distinct”

  • Key: SBVR-117
  • Legacy Issue Number: 11290
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In 8.7 in the definition of “cardinality”, remove the word “distinct”. Note that “distinct” remains in the definition of “set has cardinality”, but is not appropriate for cardinalities of all collections types (e.g. bags).

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Make the suggested change.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section 9.3 editorial

  • Key: SBVR-116
  • Legacy Issue Number: 11289
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In 9.3 in some Necessity statements the term “scoped-over variable” is used, but is undefined. The Necessity statements need to be reworded.

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Correct the Necessity statements.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section 9.2.5

  • Key: SBVR-115
  • Legacy Issue Number: 11288
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In 9.2.5 in the definition of ‘binary logical operation’, CHANGE “logical formulation” to “logical operation”.

  • Reported: SBVR 1.0b1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Make the correction.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

SBVR Issue: OMG URLs

  • Key: SBVR-114
  • Legacy Issue Number: 11283
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The URLs of SBVR’s XML documents must be changed to match OMG’s new file structure whose base directory is www.omg.org/spec.

  • Reported: SBVR 1.0b1 — Thu, 16 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Change the affected URLs.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Sjir Nijssen Revisions to Clause 10

  • Key: SBVR-113
  • Legacy Issue Number: 11264
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    Sjir Nijssen Revisions to Clause 10 – "With respect to Clause 10 I would like to make the following suggestions which are primarily communication motivated:" 10.1.1.2 1. Facts refer to individuals ... please change to: Instantiated roles of facts refer to individuals 2. The schema declares ... please change to: The conceptual schema declares 3. Derivation rules indicate how a fact type may be derived from one or more fact types ... please change to: Derivation rules indicate how the population of a fact type may be derived from the populations of one or more fact types 4. machine-oriented technical language (such as C#, Java, or SQL) ... please change to: machine-oriented technical language (such as C# or Java) [It could be argued that SQL is another way of expressing first order logic and SBVR does not regard this as a machine-oriented language.] 5. An existential fact is used to simply assert the existence of an individual ... please change to: An existential fact is used to simply assert the existence and identification of an individual 6. The domain-specific component includes declarations of ... please change to: The domain-specific component includes the concept definitions and declarations of 7. The classification of facts as forwarded last saturday could help in Clause 10 or be put in Annex M.

  • Reported: SBVR 1.0b1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    The suggestions were reviewed, and agreed, by Terry Halpin, with the exception of number 5, to which Terry responded:
    It's much better for formalization purposes to leave the definition of existential fact the way I originally worded it. Identification claims are made separately (in ORM by asserting uniqueness and mandatory constraints, which may be in simple or composite reference schemes).

  • Updated: Fri, 6 Mar 2015 22:56 GMT

NIAM Annex

  • Key: SBVR-112
  • Legacy Issue Number: 11263
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Ron Ross)
  • Summary:

    NIAM Annex – NIAM is the grandfather of fact-based semantic approaches, and has significant current application. However, it is not represented in the SBVR document. Its approach should be represented among the Annexes, in a manner corresponding to SBVR-SE, RuleSpeak and ORM.

  • Reported: SBVR 1.0b1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    1. Re-letter Annex L as Annex M.
    2. Add the NIAM Annex as Annex L
    3. Add bibliography references in the new Annex L to Annex M.
    4. Add the Annex changes to Clause 6.2.1
    5. Add acknowledgement to 6.3

  • Updated: Fri, 6 Mar 2015 22:56 GMT

"Definition of Category"

  • Key: SBVR-111
  • Legacy Issue Number: 11153
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 11.1.2, the term 'category' is defined as:
    'concept in a generic relation having the broader intension'
    Similarly, the term 'more general concept' is defined as:
    'concept in a generic relation having the narrower intension'

    I don't know, and the text doesn't say, what a 'generic relation' may be. One might conclude that it means "any instance of the concept 'relation'", but SBVR doesn't define the concept 'relation', either.
    Assuming the 'relation' is an undocumented synonym for 'fact type', the only "relation" that involves these terms jointly is
    'concept1 has more general concept2'
    Synonymous Form: 'concept2 has category'

    (1) It appears that both of these are synonymous forms for 'concept1 specializes concept2', which is defined in clause 8.1.1. These could easily have been defined to be roles in that fact type, e.g.:
    category specializes more general concept
    This would make it clear that the relationship is 'specializes' and not some undefined 'generic relation'.

    (2) The terms 'broader intension' and 'narrower intension' appear to be assigned to the wrong concepts. Does a 'broader intension' mean
    "an intension that applies to more things"
    or
    "an intension that involves more characteristics"?
    For the existing text to be correct, the meaning must be the latter – the 'category' applies to fewer things, so its 'broader intension' must mean that it involves more characteristics. This usage is counterintuitive – people think of "more general concepts" being "broader concepts".

    Recommended action:

    These two definitions should be rewritten to
    (a) specify that the 'generic relation' is the "specializes" relationship, preferably by defining the roles as part of the definition of that relationship, in clause 8.1.1,
    and
    (b) discard "broader intension" and "narrower intension" in favor of wording that says specifically that it is about more "things" or more "characteristics".

  • Reported: SBVR 1.0b1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Regarding (a): no change.
    Regarding (b): add a note to "category" explaining the intended meaning of "broader intension" as "an intension that applies to more things". Add a similar note to "more general concept" explaining "narrower intension".

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Making Annex A Normative -- No Connection with SBVR Definitions

  • Key: SBVR-110
  • Legacy Issue Number: 9228
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    AB SBVR ISSUE: Making Annex A Normative – No Connection with SBVR Definitions There is nothing in Annex A that ties the formal logic grounding into normative SBVR concepts. A chart is needed cross-referencing current ORM concepts with SBVR concepts. If the FTF decides to require Annex A examples to be expressed in SBVR Structured English (see separate issue), a translation of the examples from ORM notation to SBVR Structured English is required. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would otherwise be preferable.)

  • Reported: SBVR 1.0b1 — Mon, 19 Dec 2005 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Location of and Notation for Formal Logic Grounding Examples

  • Key: SBVR-109
  • Legacy Issue Number: 9227
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    AB SBVR ISSUE: Making Annex A Normative – Location of and Notation for Formal Logic Grounding Examples Including a SBVR Structured English version of the formal logic grounding examples in the formal logic grounding content may be desirable: either in addition to the ORM examples, or in place of them. A decision is required regarding the location of the formal grounding examples: either embedded in the formal logic grounding text where they are referenced, or separated out into an different Annex. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would otherwise be preferable.)

  • Reported: SBVR 1.0b1 — Mon, 19 Dec 2005 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Making Annex A Normative

  • Key: SBVR-108
  • Legacy Issue Number: 9226
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    AB SBVR ISSUE: Making Annex A Normative – Incorporation into Clause 10 with ORM Tutorial Material Remaining in Annex All ORM tutorial material that does not not assert the formal logic grounding needs to be separated out and remain in the Annex and the formal logic grounding material moved to become Clause 10.1 in the normative section of the bei/05-08-01 (or whereever that section ends up in the FAS). Formal logic grounding examples need to be clearly labelled as such independent of the notation used to express them. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would be preferable.)

  • Reported: SBVR 1.0b1 — Mon, 19 Dec 2005 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Association Names in UML Diagrams

  • Key: SBVR-107
  • Legacy Issue Number: 9960
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Location: SBVR Annex H

    Issue: Is it legitimate in UML to have bidirectional association names with black triangles indicating direction, as in Figure H.4?

    Resolution: none proposed as yet - need to have the question answered first.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Clause 10 pages 71 - 108

  • Key: SBVR-106
  • Legacy Issue Number: 9959
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: Work Needed to Clean Up Mapping to Formal Logics (Clause 10) 1. Clause 10.1.1 – Leave only formal logic 'interpretation' material a. Move term definitions currently in Clause 10.1.1 to Clause 10.1.2 b. Add term definitions from ISO 247xx to Clause 10.1.2 c. Add definitions for terms used in Clause 10.1.1 not in Clause 10.1.2 now or from steps 1a. or 1b. to Clause 10.1.2 d. Remove any remaining tutorial material not required to specifiy the interpretation of the formal logic grounding from Clause 10.1.1 2. Clause 10.1.2 – Complete / Minimal Formal Logic Vocabulary a. In addition to steps 1a., 1b., and 1c., - remove all terms in Clause 10.1.2 not needed for the mapping in Clause 10.2 (was Clause 10.3). - add terms needed for the mapping in Clause 10.2 (was Clause 10.3) 3. Clause 10.2 (was 10.3) – Clear Mapping from SBVR o Formal Logics a. Renuber Clause 10.3 to 10.2 by combining Clause 10.3 into Clause 10.2 b. Identify any SBVR Vocabulary entries that should be marked 'FL' but are not c. Verify that all SBVR Vocabulary entries marked 'FL' have an entry in the Clause 10.2 mapping, or remove the 'FL' from the SBVR Vocabulary entry. d. Remove mappings in Clause 10.2 that do not and should not have an 'FL' marking next to the corresponding SBVE Vocabulary entry. f. Revise the mapping information in Clause 10.2 to remove any ambiguity in the interpretation of each SBVR Vocabu;ary entry (with an 'FL') in terms of the formal logic vocabulary in Clause 10.1.2 as elaborated in Clause 10.1.1

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    1. Replace the all the tables and introductory text in Clause 10.3 with the new single integrated table mapping SBVR to ISO Common Logic (ISO 24707) and OWL and introductory text for it.
    2. Add two supplemental Conformance Points: one for Restricted Higher Order Logic, and one for First Order Logic.
    3. Create a spin-off Issue for items not resolved because of lack of time:
    a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed
    b. Remove tutorial material from Clause 10.1.1
    c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO
    4. Create a spin-off Issue for SBVR metamodel formal logic-based errors and omissions:
    a. A reference scheme is needed for individual concept.
    b. The entries in Clause 8.5 "Conceptual Schemas and Models" need to be corrected to agree with the first paragraphs of Clause 10.
    c. In Clause 8.6 "Extensions" and other sections of Clauses 8-12 the definition of "corresponds to" in "meaning corresponds to thing" and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of "proposition corresponds to state of affairs" and " individual concept corresponds to thing" need to be clarified or added. How the relationship between concept and thing is different between the "use" and the "mention" of the concept needs to be made clear.
    d. Thee reference scheme for individual concept needs to be fixed to include the "mention" of object types, roles, fact types, propositions and subcategories of them.
    e. Definitions that cover all the uses of "individual" in Clauses 8-12 need to be added.
    f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.
    5. The resolution of this Issue also resolves Issues 9623 and 9707.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.4

  • Key: SBVR-105
  • Legacy Issue Number: 9958
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: Clean Up 'Form of Expression' 1. Pick a better signifier that is less confusing e.g. 'Verb Concept Reading' 2. Fix definition and necessities

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Change 'form of expression' to 'fact type form' throughout the SBVR specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Clause 2

  • Key: SBVR-104
  • Legacy Issue Number: 9957
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: Current SBVR Conformaance Clause Does Not Meet the Criteria for an OMG Specification The Conformance clause needs to be specified according to the follwoing rules from the OMG Specification tremplate: "The Conformance clause identifies which clauses of the specification are mandatory (or conditionally mandatory) and which are optional in order for an implementation to claim conformance to the specification. For conditionally mandatory clauses, the conditions must, of course, be specified. One side effect of this is that the clause numbering must be sufficiently fine grain to make it easy to distinguish between mandatory and optional clauses. It is for the writers of the specification to determine what material should be mandatory, conditionally mandatory, or optional for conformance. This is not easy. One way of summarising the difficulty is that it is probably impossible to define conformance such that the set of all conformant implementations is the same as the set of all useful implementations. However, you must try to ensure your conformance requirements means that all useful implementations are conformant, not that all conformant implementations are a subset of all useful implementations."

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Revise the conformance clause to specify conformance of a document, conformance of a tool that creates a document, and conformance of a tool that processes a document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1.1 pages 110 - 113

  • Key: SBVR-103
  • Legacy Issue Number: 9956
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: BRT Decisions about Relationships & Necessities Among Community, Langugage, Vocabulary, Vocabulary Version Didn't Make it into the SBVR Specification Add these decisions based on flipchart documentation. (See tp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Vocabulary%20Decisions.doc)

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution to Issue 9955

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1.1 page 112

  • Key: SBVR-102
  • Legacy Issue Number: 9955
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: SBVR Uses the Signifier 'Vocabulary' with Multiple Meanings which Require Separate Concepts Some of the meanings for which the signifier, "vocabulary", is used are: 1. Synonyn for Body of Shared Concepts 2. Synonym for Body of Shared Meanings 3. "representational vocabulary" composed of representations for a Speech Community a. including only all concepts b. including all concepts + all rules 3. 'Representations' sepearate from naked meanings as in " we must talk about shared concepts and not shared vocabulary". 4. A packaging unit of less than a. all concept b. all concepts and all rules 5. A document containing any of the above

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Make the informal glossary in clause 4 consistent with the definitions in clause 11. Change the uses of the signifier 'vocabulary' so that the signifier is used only for its meaning defined in Clause 11. Add a fact type relating a vocabulary namespace to a vocabulary. Combine the undefined fact types 'vocabulary includes symbol' and 'vocabulary includes fact type form' into one fact type and give it a definition.
    Note that the term "Vocabulary" used in the title of the document, "Semantics of Business Vocabulary and Business Rules" is consistent with the defined meaning of "vocabulary". The document is about the semantics of the designations and fact type forms in used in business and of the rules stated using them.
    Annex E needs some further changes to be done as part of the EU-Rent Clean-up issue. First, Figure E.2 shows use of an undefined fact type 'speech community creates vocabulary'. Secondly, E.2.1.2 should follow the patterns used in Clauses 7 through 12 in how it specifies and names its vocabularies (for anything listed that is intended to be a vocabulary). The term 'vocabulary' should not be used for anything intended to be a dictionary, glossary or book. The name of a vocabulary should refer to the vocabulary presented by the document or publication, not to the document or publication itself.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.1.1

  • Key: SBVR-101
  • Legacy Issue Number: 9953
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: 'Role' has Multiple Meanings that Need to be Separate Concepts 1. Role in Situation 2. Role in Process 3. Role as part of the composition of a 'fact type' or 'fact' 4. Role bound to a group of 'fact types' These needs to be clearly defined and contrasted.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add two specializations of 'role': 'fact type role' and 'situational role'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.5, 11.1.1, 11.2.1

  • Key: SBVR-100
  • Legacy Issue Number: 9952
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    Issue: Need to Check the Core Structures in the ISO Terminology Stnadards to Make Sure SBVR Builds on Them Correctly There may be some small adjustments needed to enable SBVR to build seemlessly on the ISO Terminology standards,, especially regarding 'term', 'subject field/area', and language. The concept adoption seems to be in good order.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    ISO's definitions of "designation", "term" and "name" are used.
    'placeholder' specializes 'designation'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex C

  • Key: SBVR-99
  • Legacy Issue Number: 9950
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: SBVR Structured English is Inadequate to Enable the Full Specification of SBVR in Terms of SBVR Fully specifying SBVR in terms of SBVR was a fundamental design objective and the basis for the expression of the SBVR metamodel. 1. Need a table to show how every SBVR metamodel construct can be expressed by SBVR Structured English. 2. Need to add SBVR Structured English Capability where the table shows it to be missing.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    A mapping from SBVR Structured English to XMI based on the SBVR Metamodel is added to Clause 13.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: F.2.2

  • Key: SBVR-98
  • Legacy Issue Number: 9949
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Precise Differentiation of Structural Rule vs. Operative Rule in RuleSpeak section. (1) Change the sentence that reads "If not followed (applied) in creating a booking, the booking is simply invalid." to "If not followed (applied) in attempting to make a booking, no booking results." (2) Change the sentence that currently reads "In borderline cases, RuleSpeak best practice is the following:" to "Refer to the RuleSpeak best practices presented in [Ross2005]." Retain the fotnote (7). Delete the boxed item entirely. (The use of "should" is too confusing without additional explanation.)

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Revise two sentences and delete a small section of text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.2.1.1.1 Fac Type: "concept1 specializes concept2"

  • Key: SBVR-97
  • Legacy Issue Number: 9948
  • Status: closed  
  • Source: MEGA International ( Antoine Lonjon)
  • Summary:

    Fac Type: "concept1 specializes concept2"

    This definition of this fact type includes the following example:

    "The role ‘sum’ specializes the noun concept ‘number’, the differentiator being that each sum is the result of adding up a set of numbers. It turns out that every number is a sum of that number added to zero, so the extensions of the concepts ‘sum’ and ‘number’ are always the same."

    Issue on: "the extensions of the concepts ‘sum’ and ‘number’ are always the same"
    The extension of a role is not a set of things but a set of involvement of things. In extension of sum example, it is not a set of numbers but a set of an involvement of numbers
    3 + 2 = 4 implies that 4 is involved in sum with an involvement of 3 and an involvement of 2
    2 + 2 = 4 implies that 4 is involved in sum with an involvement of 2 and an other involvement of 2
    Therefore, the extension of the "sum" role is:

    {..., "involvement of 4 in 3+2, involvement of 4 in 2+2, etc }

    .

    In version 6 of the SBVR specification, fact-type role was changed to "role", which is now a direct specialization of "concept". To express what concept can range over a role (play the role), the only available mechanism is concept specialization. Hence the example provided by Don:
    wife
    General Concept: woman

    Concept Type: role

    We should be able to specify the role of "wife" in the context of marriage with husband without specializing it from woman or even from person.
    We should then be able to define the range of concepts to which the wife and husband roles can be applied: "woman/men", "female/male" or in a Disney movie, like Robin Hood, "animals".
    I don't see the value of being forced to go to the hierarchy of concepts (specialization) has a fact-type between role and noun-concept.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Previously, a fact type role was an object type. But it is the nature of object types that two object types that incorporate the same characteristics are the same object type. Roles of fact types do not have this property. A role of a fact type is intrinsically tied to a point of involvement in a fact type, and in the case of invertible fact types like 'thing is thing' and 'person is married to person', and in some other cases, two fact type roles can incorporate the same characteristics, or a fact type role can incorporate the same characteristic as an object type. Also, an individual concept is not an object type because it includes the sense of there being one instance.
    The resolution of this issue makes the following changes:
    What was previously one concept termed 'noun concept' and 'object type' is split into two concepts. 'Noun concept' keeps its original definition, but 'object type' is changed to be a specialization of 'noun concept' that is intrinsically based only on incorporated characteristics and that excludes fact type roles. The necessity that was given for 'noun concept' goes with 'object type'. 'Fact type role' is then intrinsically tied to a point of involvement in a fact type such that its incorporated characteristics are those understood from the fact type.
    'Object type' is then understood to be what ISO intended by its 'general concept' and is one specialization of 'noun concept', with 'individual concept' and 'fact type role' being two other specializations.
    With these changes it is possible that a fact type role ranges over an object type that has exactly the same incorporated characteristics as the fact type role. For this reason, 'specializes' is not adequate to describe that relationship, so a "ranges over" fact type is added.
    The extension of a role is the totality of objects to which the role corresponds (as defined by ISO 1087-1). E.g. the extension of a role 'husband' would be all of the husbands. However, Antoine is correct that is it not necessary that a role be defined to specialize any particular concept or to range over a particular single concept. A note is therefore added to explain that roles need not be so constrained. Also, the range of a role, if given at all, can be given as coming from many concepts (an anonymous union). Also, advices of possibility can be used to indicate concepts whose instances can fill roles.
    The unresolved "role playing of thing in occurrence" and "involvement" have been submitted as two spin-off issues.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Projection Diagram - Variable Maps to Role

  • Key: SBVR-96
  • Legacy Issue Number: 9947
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In Figure 9.12 on page 67 there is a small error. In order to agree with the normative text, the box at the upper right that says “fact type role” must be changed to say only “role”. The fact type being shown is “variable maps to role” from page 70.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Change the diagram to match the normative text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

“Admonition” and “Affirmation” are the same concept

  • Key: SBVR-95
  • Legacy Issue Number: 9945
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Issue name: “Admonition” and “Affirmation” are the same concept

    Location: SBVR Section 12.1 Categories of Guidance

    Issue:

    “Admonition” and “Affirmation” are both elements of guidance that there is not a business rule where one might be expected (especially if members of the semantic community have been acting as if there were such a rule).

    There is only one concept there, and “Admonition Statement” and “Affirmation Statement” are two different forms of representation for it.

    Proposed Solution:

    Replace “Admonition” and “Affirmation” by a single concept. The detail of the change may depend on the restructuring around “Directive” and “Guidance” that was discussed at the London face-to-face meeting.

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution of Issue 9475

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1.3

  • Key: SBVR-94
  • Legacy Issue Number: 9944
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: Better Term and Definition for 'Res' Change definition of 'res' to "thing that is not a meaning" and find a more common term for this concept. (see related Issue on Major Categories of Thing)

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Recommendation: change the definition; retain the term.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8

  • Key: SBVR-93
  • Legacy Issue Number: 9942
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    : Representations of 'Objects' Belong in Vocabularies Indications of 'objects' by representations (that can be treated as existential assertions) need to be able to be included as entries in 'vocabularies' without having to form an'individual concept' about them. The original justification for omitting this capability "because ISO requires everything in a vocabulary (terminology) to be a concept" turns out to be based on a lack of knowledge about the ISO TC 37 position on this subject. In conjunction, 'definite' description' for 'objects' needs to be added to support statements that uniquely identify (not form or define a concept about) 'objects'. SEE: 1. InfoTerm – ISO Terminology TC 37 Secretariat - http://www.infoterm.info/standardization/basic_principles.php 2. Terminology Summer School 2006 Slides - ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/TSS2006%20Objects%20and%20Concepts.doc

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Issue 9942 is resolved by the resolution of Issue 10790.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3, + 11.2

  • Key: SBVR-92
  • Legacy Issue Number: 9941
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    ISSUE: Rationalize 'Representation' and Support 'Cocnept'/'Object' Distinction 1. Remove duplication and unnecessary Complexity between Clause 8.3 and 11.2, especially the relationship between Namespace and Speech Community & Symbol Context 2. Add the distinction from ISO of verbal (linguistic) and non-verbal (but still text) representations. 3. Align subcategories of 'representation' with ISO terminology community SEE: a. Terminology Summer School 2006 slides - ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/TSS2006%20Verbal%20and%20Non-Verbal%20Representations.doc b. ISO 12620 Annex A.5 (Normative) Concept Related Description 4. Create a table show which types of representation go with which major categories of 'thing' (see related Issue).

  • Reported: SBVR 1.0b1 — Mon, 24 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    NOTE: The ISO 639-6 Language Codes standard currently being developed is creating a registry for language dialects right down to the work group level within an organization. This registry will be able to be used as a registry for each speech community (and its dialect).

    The resolution to Issue 9952 covers the verbal distinction point of this issue (number 2) because it has 'term' and 'name' as verbal designations, and then adds nonverbal designation following ISO-1087-1's lead.
    1. Remove 'symbol' and replace all references to it with 'designation'.
    2. Remove or change the fact types 'symbol' participates in.
    3. Add 'subject field' as an adopted concept from ISO 1087-1.
    4. Relate 'symbol context' and 'subject field' to representations and vocabulary namespaces.
    5. Add 'nonverbal designation' and have 'icon' specialize it.
    6. Correct the discussion of "Qualifier" in Annex C to discuss "subject field" (in place of "subject context").
    7. Relate a subject field to a vocabulary (as is implied by ISO 1087-1's definition of vocabulary).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Logical Formulation Kinds of Quantifications

  • Key: SBVR-91
  • Legacy Issue Number: 9940
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Logical Formulation Kinds of Quantifications

    In 9.1.1.7, page 57, under “existential quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an existential quantification is the concept ‘at-least-n quantification’.

    In 9.1.1.7, page 59, under “at-most-one quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an at-most-one quantification is the concept ‘at-most-n quantification’.

    In 9.1.1.7, page 59, under “exactly-one quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an exactly-one quantification is the concept ‘exactly-n quantification’.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove the Concept Type paragraphs as stated above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

‘vocabulary has URI’

  • Key: SBVR-90
  • Legacy Issue Number: 9939
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In 11.1.1.3, page 113, the reference scheme for ‘vocabulary’ is “a URI of the vocabulary”, but there is no fact type ‘vocabulary has URI’ to support the reference scheme.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add the fact type 'vocabulary has URI'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - 'role has role binding'

  • Key: SBVR-89
  • Legacy Issue Number: 9938
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    role has role binding’

    Figure 9.4 shows a fact type ‘role has role binding’, but the normative text has ‘role binding is of role’. By the rules of SBVR Structured English (and normal English), ‘role has role binding’ implies that we can use ‘role binding is of role’, but not the other way around. All of the current usage within the document appears to use “is of”, not “has”.

    Either change Figure 9.4 to show ‘role binding is of role’ (not ‘role has role binding’) or else change the entry ‘role binding is of role’ in the normative text to ‘role has role binding’.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Bug in Namespaces Diagram

  • Key: SBVR-88
  • Legacy Issue Number: 9935
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Bug in Namespaces Diagram

    In Figure 8.5, page 27, to properly match the normative text, the box marked “URI” should say “text” and the “also: uniform resource identifier” should be moved out of the box and added to the “URI” association end.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Fix Figure 8.5 to match the normative text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Concept Expression versus Meaning Expression

  • Key: SBVR-87
  • Legacy Issue Number: 9934
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Concept Expression versus Meaning Expression

    The following fact types in 11.2.2.2 and 11.2.2.3 relate to concepts:

    concept is portrayed by description

    concept is illustrated by descriptive example

    concept is commented on in note

    concept is supported by reference

    All of these relationships should be generalized to relate to ‘meaning’ rather than to ‘concept’. As it is, SBVR does not support having a description, descriptive example, note or reference for a business rule because a business rule is another kind of meaning (a proposition rather than a concept).

    Recommendation: replace the fact types above with these:

    meaning is portrayed by description

    meaning is illustrated by descriptive example

    meaning is commented on in note

    meaning is supported by reference

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Is a representation an actuality?

  • Key: SBVR-86
  • Legacy Issue Number: 9932
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Is a representation an actuality?

    Remarks often made by people involved in SBVR have indicated that a representation is an actuality – an objectification of the portrayal of a meaning by an expression. This same generalization applies to all of the specializations of ‘representation’ such as ‘designation’, ‘definition’ and ‘symbol’. But SBVR does not define ‘representation’ this way.

    Recommendation: Change the definition of ‘representation’ from “portrayal of a meaning by an expression” to “actuality that an expression portrays a meaning”. Alternatively, add a General Concept paragraph under ‘representation’ that identifies ‘actuality’ as a more general concept.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add a new fact type: "expression represents meaning". Make 'representation' an objectification of it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - 'meaning has representation'

  • Key: SBVR-85
  • Legacy Issue Number: 9931
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    ‘meaning has representation’

    There places in the document such as in the definition of ‘symbol’ in 11.2.1.1 that assume there is a form of expression ‘meaning has representation’ given as a synonymous form of ‘representation represents meaning’. But that synonymous form is not given.

    Recommendation: Add the synonymous form ‘meaning has representation’ and show it in Figure 8.3. In the definitions of ‘designation’, ‘definition’, ‘statement’, ‘form of expression’ and ‘placeholder’, put the “of a” after the word “representation” in styled text as is done in the definition of ‘symbol’.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1 - modeling based on MOF does not have all of the capabilities

  • Key: SBVR-84
  • Legacy Issue Number: 9930
  • Status: closed  
  • Source: EDS ( Fred A Cummins)
  • Summary:

    The SBVR specification defines a metamodel that is not a MOF metamodel and then defines a transformation from the SBVR metamodel to a MOF metamodel for rules defined in the SBVR metamodel. This means that modeling based on MOF does not have all of the capabilities (e.g., reflective definition of vocabulary) of the SBVR model, and that MOF technologies (e.g. QVT) cannot be applied to the SBVR metamodel. Furthermore, this means that aspects of the SBVR metamodel cannot be integrated into other metamodel specifications so that, for example, business vocabularies (multiple) and business rules mught be specified for an organization structure model or a business process model.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Noun concepts are represented, in MOF terms, as classes, unary fact types as Boolean attributes, binary fact types as associations, and ternary fact types as classes. To be completely straightforward, this direct correspondence from SBVR meanings to MOF model elements requires two semantic modeling capabilities that are not in MOF 2, but which could soon be supported through a new initiative, Semantic MOF (SMOF). The two capabilities are support for multiclassification and for the open world assumption. Workarounds make the direct correspondence workable in the absence of SMOF as follows:
    1. Multiclassification: When a thing is categorized in multiple ways such that it instantiates two or more MOF classes, neither class specializing the other, the thing is represented in MOF by multiple MOF objects which are linked together using an association to indicate that the multiple MOF objects represent a single thing (this approach to multiclassification is allegedly also being used in for ADM).
    2. Open World Assumption: The open world assumption is that representation of facts in a model does not imply that those are the only facts of a particular type nor that they are the only facts of a particular type about a subject thing - there are no implications to be taken from what is unstated. MOF supports this open world assumption about instantiation of classifiers (classes and associations), but MOF's attributes support only representation of an entire extension of an attribute with respect to a given subject. In order to enable a clear distinction in a MOF context between individual facts and complete extensions, association links are used to represent individual facts of a fact type while attributes are used when identifying a complete extension of a fact type with respect to a particular subject. This means that a fact can in one model be represented using a link, and in another as a value of an attribute of an object.
    The two workarounds, however clumsy, are used because they enable a direct use of MOF. It is anticipated that an acceptable SMOF will directly support multiclassification and the open world assumption, both of which are supported by RDF and OWL, and that SMOF will remove the need for the workarounds in the future.
    Changes to the SBVR specification are summarized as follows:
    1. Clause 5 explains that the MOF interpretation of the figures is explained in clause 13 (SBVR Metamodel).
    2. The caption under each figure in the normative clauses 7 through 12 which says the figures are nonnormative is changed.
    3. Clause 13 is entirely replaced by an explanation of the MOF interpretation of the vocabulary entries and figures, and of the direct semantic correlation of the SBVR vocabularies with the MOF-based SBVR Metamodel.
    4. Annexes K and L are removed (they are no longer relevant).
    5. Some fact type forms are added for existing fact types as needed where MOF attributes are required in order to indicate a complete extension of a binary fact type for a particular subject, especially where required by reference schemes.
    6. Three signifiers that use characters (">", "<", "&") that do not work in an xmi:id are removed or replaced.
    7. The use of xmi:id values in SBVR Metamodel documents is explained in clause 15 such that it supports URIs that refer to SBVR designations and fact type forms.
    8. The use of square brackets around placeholders in UML figures is replaced by underlining so that the brackets are not thought to be part of an association's name.
    The specific changes below assume that clause 2 will be corrected separately by the resolution to Issue 9957.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Note and Example for “text is for placeholder”

  • Key: SBVR-83
  • Legacy Issue Number: 9929
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In 13.1.1, page 148, under “text is for placeholder”, there is the following:

    Example: The placeholder ‘Note that a text is normalized to have no leading
    or trailing spaces and no other white space than single spaces.

    An editing error seems to have deleted whatever was supposed to be most of the example and has pulled in what is clearly a Note.

    Recommendation:

    Complete the example and show the note as a Note paragraph.

    add 2nd example using subscripts and explain that they are not part of the form.

  • Reported: SBVR 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define ‘true’ and ‘false’

  • Key: SBVR-82
  • Legacy Issue Number: 9882
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    SBVR talks a great deal about propositions and particular types of propositions, such as facts and rules, but never defines what it means for a proposition to be true or false. Understanding these characteristics of propositions is essential to understanding semantic formulations and other parts of SBVR.

    Recommendation:

    In section 8.1.2, page 19, add the following entries after the entry for ‘proposition’.

    proposition is true

    Definition: the proposition corresponds to an actuality

    proposition is false

    Definition: the proposition does not correspond to an actuality

  • Reported: SBVR 1.0b1 — Tue, 4 Jul 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex E - editorial issues

  • Key: SBVR-81
  • Legacy Issue Number: 9874
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    E.1.4 example 2 and also the 2nd rule in E.2.2.2.7 use " rental has duration"

    The correct fact type at E.2.2.1.5 is "rental has rental duration". Probably E.2.2.1.5 should be changed, plus the reference in E.2.2.2.3.

    E.1.4 example 3 and numerous other places use "rental has driver".

    The fact type "rental has driver" seems to be missing entirely, though cited at E.1.4 and elsewhere. Suggest adding it to E.2.2.1.11.

    This also affects rules (e.g. in E.2.2.4) that depend upon "rental has primary driver" and "rental has additional driver".

    And it affects E2.2.2.10 rule 4 that depends upon "rental has additional driver".

    E.1.4 example 4 and several other places use "branch has drop-off location"

    E.2.2.1.9 has "rental uses drop-off location". Maybe it should be marked as an "is-part-of fact type" or given a synonym "branch has drop-off location"

    E.1.4 example 5 and several other places use "rental has rental charge"

    "rental charge" is given in E.2.2.1.7 but not "rental has rental charge"

    E.1.4 example 6 and E.2.2.2.3 rule 1 use "rental has estimated rental charge"

    "estimated rental charge" is given in E.2.2.1.7 but not "rental has estimated rental charge"

    Also, these two rules elide "of a rental" from "... an estimated rental charge [of a rental] is provisionally charged ...." Maybe that's ok since there is no
    other kind of estimated rental charge, but if so the spec should say that somewhere.

    E.1.4 example 6 and several other places use "rental has renter"

    "rental has renter" presumably belongs in E.2.2.1.11
    E.1.4 example 7 uses "branch is included in local area"

    Question: "branch is included in local area" is a partitive fact type. Is that what makes "local area of branch" a legitimate usage?

    E.1.4 example 7 uses "rental has rented car"

    "rental has rented car" is missing from the list of Supporting Fact types, but see below about it.

    E.1.4 examples 7 & 8 and various other places use "rental has rented car"

    "rental has rented car" presumably belongs in E.2.2.1.5, but according to figure E-7 it is the renter, not the rental, that has the rented card

    E.2.2.2.2 rule 2 uses "rental has rental period"

    "rental has rental period" presumably belongs in E.2.2.1.5, maybe as a synonymous form of "rental includes rental period "

    E.2.2.2.3 rule 4 and elsewhere use "cash rental has lowest rental price"

    "cash rental has lowest rental price" presumably belongs in E.2.2.1.7, maybe as a synonymous form of "cash rental honors lowest rental price"

    Also, this fact type is not listed in "Supported Fact Types".

    E.2.2.2.3 rule 6 uses "rental has car group"

    the correct fact type is "rental has requested car group"

    E,2.2.2.5 rule 1 uses "rented car" in the rule but "local area owns rental car" in the Supporting Fact Types.

    E.2.2.2.8 rule 1 uses "rental car has scheduled service"
    ... which probably belongs in E.2.2.1.10

    E.2.2.2.14 rule 1 uses "rental has base rental price"
    ... which probably belongs in E.2.2.1.7

    E.2.2.2.15 rule 1 uses "operating company has insurer"

    "insurer" appears in Figure E.5 but is not defined anywhere, much less "operating company has insurer". Both belong in E.2.2.1.3.

  • Reported: SBVR 1.0b1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    E.1.4 example 2 and also the 2nd rule in E.2.2.2.7 use " rental has duration"
    The correct fact type at E.2.2.1.5 is "rental has rental duration". Probably E.2.2.1.5 should be changed, plus the reference in E.2.2.2.3.
    corrected in Issues 9449 and 9450
    E.1.4 example 3 and numerous other places use "rental has driver".
    The fact type "rental has driver" seems to be missing entirely, though cited at E.1.4 and elsewhere. Suggest adding it to E.2.2.1.11.
    This also affects rules (e.g. in E.2.2.4) that depend upon "rental has primary driver" and "rental has additional driver".
    And it affects E2.2.2.10 rule 4 that depends upon "rental has additional driver".
    corrected in Issues 9449 and 9450
    E.1.4 example 4 and several other places use "branch has drop-off location"
    E.2.2.1.9 has "rental uses drop-off location". Maybe it should be marked as an "is-part-of fact type" or given a synonym "branch has drop-off location"
    corrected in Issue 9449
    E.1.4 example 5 and several other places use "rental has rental charge"
    "rental charge" is given in E.2.2.1.7 but not "rental has rental charge"
    corrected in Issue 9449
    E.1.4 example 6 and E.2.2.2.3 rule 1 use "rental has estimated rental charge"
    "estimated rental charge" is given in E.2.2.1.7 but not "rental has estimated rental charge"
    Because 'estimated rental charge' is a kind of 'rental charge' it is valid to use the verb from the fact type that reflects the more general concept.
    Also, these two rules elide "of a rental" from "... an estimated rental charge [of a rental] is provisionally charged ...." Maybe that's ok since there is no
    other kind of estimated rental charge, but if so the spec should say that somewhere.
    The fact type 'estimated rental charge is provisionally charged to credit card' is part of the vocabulary.
    E.1.4 example 6 and several other places use "rental has renter"
    "rental has renter" presumably belongs in E.2.2.1.11
    corrected in Issue 9449
    E.1.4 example 7 uses "branch is included in local area"
    Question: "branch is included in local area" is a partitive fact type. Is that what makes "local area of branch" a legitimate usage?
    corrected in Issue 9449
    E.1.4 example 7 uses "rental has rented car"
    "rental has rented car" is missing from the list of Supporting Fact types, but see below about it.
    E.1.4 examples 7 & 8 and various other places use "rental has rented car"
    "rental has rented car" presumably belongs in E.2.2.1.5, but according to figure E-7 it is the renter, not the rental, that has the rented card
    corrected in Issue 9449
    E.2.2.2.2 rule 2 uses "rental has rental period"
    "rental has rental period" presumably belongs in E.2.2.1.5, maybe as a synonymous form of "rental includes rental period "
    corrected in Issue 9449
    E.2.2.2.3 rule 4 and elsewhere use "cash rental has lowest rental price"
    "cash rental has lowest rental price" presumably belongs in E.2.2.1.7, maybe as a synonymous form of "cash rental honors lowest rental price"
    Also, this fact type is not listed in "Supported Fact Types".
    No change (beyond the scope of a simple fix, due to nature of the extended discussion in E.2.2.2.3 that this is part of). Defer to resolution in Issue 10628.
    E.2.2.2.3 rule 6 uses "rental has car group"
    the correct fact type is "rental has requested car group"
    corrected in Issue 9449
    E.2.2.2.5 rule 1 uses "rented car" in the rule but "local area owns rental car" in the Supporting Fact Types.
    Not a problem. ('rented car' is a role of 'rental car' in the situation of a rental. The ownership fact type is correctly shown using 'rental car'.)
    E.2.2.2.8 rule 1 uses "rental car has scheduled service"
    ... which probably belongs in E.2.2.1.10
    See below.
    E.2.2.2.14 rule 1 uses "rental has base rental price"
    ... which probably belongs in E.2.2.1.7
    See below.
    E.2.2.2.15 [actually, E.2.2.2.11.4] rule 1 uses "operating company has insurer"
    "insurer" appears in Figure E.5 but is not defined anywhere, much less "operating company has insurer". Both belong in E.2.2.1.3.
    See below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue: What is concept1?

  • Key: SBVR-80
  • Legacy Issue Number: 9835
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In SBVR clause 8.1.1, the fact type 'concept1' specializes 'concept2' is defined. What are 'concept1' and 'concept2'?

    They seem to be roles. But the necessity in the definition of 'role' in the same section – a role is in at most one fact-type – would then disallow the use of 'concept1' in any other fact-type, and the very next fact type glossary entry is 'concept1' is coextensive with 'concept2'. So they aren't roles, by the principles of definition. What are they?

  • Reported: SBVR 1.0b1 — Thu, 22 Jun 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution of Issue 9257

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Thing’ Defined Tentatively

  • Key: SBVR-79
  • Legacy Issue Number: 9832
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In SBVR 10.3.4 on page 107, there is a comment on ‘thing’ talking about its “current definition” as if the definition is about to change.

    Recommendation: Remove the word “current” from the comment.

  • Reported: SBVR 1.0b1 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove the word "current" from the comment

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong proposition in 8.1.2 and modal formulation

  • Key: SBVR-78
  • Legacy Issue Number: 9753
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 8.1.2 and 9.1.1, modal formulation
    Pages: 101
    Nature: Editorial
    Severity: minor

    Description:

    In 8.1.2, 'obligation' is defined as follows:
    "Definition: proposition that is required to be true, that is obligatory, that is not permitted to be false"

    And 'permission', 'necessity' and 'possibility' are similar.

    The problem is that an obligation is not a proposition that is required to be true. It is rather a proposition that requires another proposition be true.

    Example:
    "It is an obligation that every rental car has a scheduled service."
    The proposition
    'Every rental car has a scheduled service'
    is what the obligation requires to be true. But that proposition itself is not an obligation. It is just a statement, like "all roads lead to Rome".

    The 'obligation' is:
    "It is an obligation that every rental car has a scheduled service."
    or equivalently:
    "Every rental car is required to have a scheduled service."
    which is a different proposition.

    The obligation itself is a proposition that (per the definition of 'proposition') can be true or false – that 'obligation' may or may not actually be a rule at UDriveIt.

    The Note under the glossary entry for 'modal formulation' has this same error. It says:
    "The meaning of a modal formulation is the proposition that the proposition meant by the embedded logical formulation is an instance of the modality claimed by the modal formulation."

    I read this to say that the meaning of
    "It is an obligation that every rental car has a scheduled service."
    is the proposition:
    "(The proposition) 'every rental car has a scheduled service' is
    an (instance of) obligation."
    This is incorrect. As above, the embedded proposition 'every rental car has a scheduled service' is not an obligation. The obligation is the meaning of the modal formulation itself.

    That is, the meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation.

    Recommendation:

    In 8.1.2,

    a. change the definition of 'necessity' to
    "proposition that another proposition is necessarily true, always true"

    b. In the definition of 'possibility', after "proposition that" insert "another proposition"

    c. In the definition of 'obligation', after "proposition that" insert "another proposition"

    d. In the definition of 'permissiblity', after "proposition that" insert "another proposition"

    In 9.1.1,

    a. Replace the text of the Note under 'modal formulation' with:
    "The meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation."

    b. Under the entry for 'modal formulation claims modality', add a note:
    Note: The meaning of 'modal formulation claims modality' is that the proposition meant by the modal formulation is an instance of the concept that corresponds to the modality.

  • Reported: SBVR 1.0b1 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    DUPLICATE OF ISSUE 9721

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct specification of question and answer nominalization

  • Key: SBVR-77
  • Legacy Issue Number: 9734
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.10
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.10, there are several problems with the specification of 'question nominalization'

    "Definition: projecting formulation of a referent question being formulated by a particular projection"

    No modeled property of a question nominalization refers to a question. Change to:
    "noun concept that refers to all questions whose structure of meaning is formulated by a given projection"

    'question nominalization' is not a logical formulation kind; it is a projecting formulation kind, if that has any significance.

    The reference scheme cannot be the bindable target, unless a question nominalization is unique to its occurrence instead of its content. In general, the reference scheme for a question nominalization should be that of the projection, plus any attached bindings.

    Replace the Note text with:
    For a closed projection, the projection formulates exactly one question.
    Otherwise, the projection formulates one question for each possible substitution of a referent for each free variable in the projection. The question normalization may include a set of bindings for the free variables that constrain the possible substitutions.

    Replace the Example text with:
    In the statement, “An agent must ask each new customer what kind of car the customer wants”,
    an atomic formulation based on a fact type ‘agent:person asks customer:person question’ binds to three
    variables, one for each role. The variable bound from the ‘question’ role binds to the question nominalization for a projection formulating “'kind of car' such that 'customer' wants 'kind of car'". Because the variable for ‘customer’ is free within the projection, the question nominalization would refer to one such question for each possible 'customer'. So the question nominalization must include a binding that binds 'customer' in the projection to 'customer' in the atomic formulation that includes the question.

    A question nominalization should have zero or more bindings instead of one bindable target. It can have one binding for each free variable in the projection.

    In 9.1.1.10, 'answer nominalization' has many of the same problems.

    It is difficult from the definition to determine the intent. The example suggests that the intent is:
    Definition: noun concept that refers to all noun concepts whose structure of meaning is formulated by a given projection (i.e. whose structure of meaning is a noun concept formulation)

    It is not a logical formulation kind; it is a projecting formulation kind, if that has any significance.

    The reference scheme should be that of the projection, together with any bindings.

    Like question nominalization (above), add bindings and modify the Note and Example similarly.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Complete support for question nominalization

  • Key: SBVR-76
  • Legacy Issue Number: 9733
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.10
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    There are several kinds of questions:

    • those that ask for confirmation/denial of a proposition (whether),
    • those that ask for the identification of an individual or set of things (who, what, where, when),
    • those that ask for a reason or a proof (why).

    In 9.1.1.10, 'question nominalization', SBVR only addresses the second. It should also address the first, and there is no reason why it could not also address the third.

    Confirmation/denial (whether) questions look like proposition nominalizations, except that their meaning is a question.

    Rationalization (why) questions look like proposition nominalizations, but they assert the proposition and have the meaning of asking for the rationalization for that state of affairs.

    So both of these could be accomplished by subtypes of proposition nominalization that have the same structure but different meaning. And the assertion nominalization is the current kind of proposition nominalization.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct glossary entry for proposition nominalization

  • Key: SBVR-75
  • Legacy Issue Number: 9732
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.10
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.10, there are several problems with 'proposition nominalization'

    Definition: logical formulation that a referent proposition is formulated by a particular logical formulation

    What can refer to a proposition? A proposition nominalization is a noun concept, one that refers to a structure of meaning (a logical formulation) as a thing separate from its meaning. The concept is not itself a logical formulation.
    Change the definition to:
    "noun concept referring to all propositions for which a given 'logical formulation' is the structure of meaning"

    Add Note:
    When the formulation contains free variables, the noun concept corresponds to a collection of such structures of meaning, one for each possible substitution for the free variables. That collection may not be a finite set. For each possible binding of those variables to constants, the result is a particular closed formulation that corresponds to a proposition.

    In Example (1), 2nd sentence: "The variable bound from the ‘proposition’ role is also the
    bindable target of a proposition nominalization that considers a logical formulation
    formulating “EU-Rent accepts no checks”."
    replace "is also the bindable target of a proposition normalization" with
    "is bound in the atomic formulation to a constant proposition normalization"

    Replace the text of Example(2) with:
    In the statement, “An agent must tell each new customer that the customer cannot use a check”,
    an atomic formulation based on a fact type ‘agent:person tells customer:person proposition’ binds to three
    variables, one for each role. The variable bound from the ‘customer’ role is also the
    bindable target of a proposition nominalization that considers a logical formulation
    formulating “customer:person cannot use a check”.
    Because the variable for ‘customer’ is free within the proposition nominalization, the proposition nominalization corresponds to a set of propositions, one for each possible referent of 'customer', and the variable in the atomic formulation that is bound to 'proposition' ranges over that set. But in each fact that satisfies the atomic formulation, the referent for 'customer' in "agent tells customer proposition" and the referent for 'customer' in the referent for 'proposition' have to be the same.

    In the entry for 'proposition nominalization considers logical formulation'
    Definition: the proposition nominalization is based on the logical formulation
    should be:
    Definition: the proposition nominalization represents all propositions for which the 'logical formulation' is the structure of meaning.

    In the entry for 'proposition nominalization binds to bindable target'
    Definition: the bindable target indicates the referent proposition identified by the proposition
    nominalization
    No. The proposition nominalization may have associated variable bindings. The variables must be free in the logical formulation considered by the proposition nominalization, but may be bound in a reference to the proposition nominalization (to constrain the set), and must all be bound in order to select an individual proposition.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of fact-type formulation and fact type projection

  • Key: SBVR-74
  • Legacy Issue Number: 9731
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.9
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.9, 'fact type formulation' is defined as:
    "projecting formulation of a referent fact type whose intension is formulated in a particular projection"

    I don't know what this means. There is no referent fact type. If the formulation is closed, then it defines a fact-type. And there is no reference to the bindable target.

    Is this intended to mean:
    "definition of a fact type by a projection that formulates its intension"?
    If that is the intent, the fact type formulation should have a referent (text?) constant, which is its name. And it introduces a set of variables corresponding to the roles of the fact type. And the intension is represented by a logical formulation in which each of those variables is free, and no other variable is free. Note that this description does not involve a projection, because there is no "set" involved. The definiens has the same syntactic structure as a projection (except that the bound variables are associated with the roles of the fact type and not with the projection per se), but the definiens means the logical formulation (the intension), while the projection means the "set" (of things that satisfies it – the extension).

    If this is the intent, I would also say a fact-type formulation is not a 'logical formulation' in the usual sense – it is a definition, and cannot be substituted for 'logical formulation' in other uses.

    Note also that the 'referent fact type' must be a constant, not a variable, and therefore not a 'bindable_target'. (If one allows the definition of variable fact types, it creates problems with the Henken semantics model in clause 10 – the fact types of a given SBVR model might not be enumerable.)

    Now the above is all guesswork, because I don't understand the definition, and the example doesn't identify any part of it as the fact type formulation.

    In the Example, the interpretation of "drinking and driving violates the rental agreement" is:
    For any person such that p is-renter, IF p drinks AND p drives, THEN p violates-rental-agreement.
    I don't see where any projection fits in here, except possibly for p is-renter.

    In 9.1.1.10 'projection' (whose definition appears to be "some operation that results in a set"), the concept of formulating a fact type appears in the Note:
    "A projection’s result can be taken in multiple ways. Which way depends on how the
    projection is used. When used in an aggregating formulation or as defining a concept other
    than a fact type, the result elements are simply the referents of the variable in the projection.
    When used to define a fact type, each result element is taken as an actuality that involves the
    referents of the variables in the projection."

    This supports the idea above that 'projection' has more than one semantic interpretation, and the interpretations are only loosely consistent. And that means it fails as a "structure of meaning". It is a structure, but the meaning is imposed by something else.

    Now, to define a fact type, the referents of the variables in the projection would have to be assigned to "roles", so the presumption must be that the different variables represent different roles. A "result element" must then be a tuple of referents, one for each variable, in which each 'position' corresponds to a role. Since no verb is associated with the tuple, such a tuple can be "taken as an actuality" only in the sense that the collection of referents in the tuple is related by satisfying the logical formulation that constrains the projection. But relating a variable that ranges over actualities (states of affairs) to such a tuple would be very difficult. You can only get the tuple by having a fact-type to interpret the actuality. (As Antoine says, a fact is an actuality interpreted by a fact-type.)

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    'Fact type formulation' appears to fill a theoretical hole in structuring meanings of natural language statements, but no good example of its use has been produced. Therefore, the resolution is to remove 'fact type formulation'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

bindable target should be 'constant' not 'text'

  • Key: SBVR-73
  • Legacy Issue Number: 9730
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In clause 9.1.1, a 'bindable target', the thing to which a variable can be bound, is said to be either a variable (i.e. to its current referent) or to 'text'. 'text' is defined in 8.1.1 to have its conventional dictionary interpretation, which is inappropriate here. For a bindable target, the alternative to a variable is a 'constant' – a reference to a specific fixed individual concept (a 'name'). 'text' may be the physical expression of the reference.

    And the first Example under the glossary item 'variable' appears to be a constant that has been transmogrified into some unnecessary doubletalk.

    Recommendation:

    1. In clause 9.1.1, after 'variable', add a glossary item for 'constant':

    'constant'
    Definition: a reference to a specific fixed individual concept (a 'name').

    Necessity: the referent of a constant is exactly 1 individual concept.

    Note: By definition, every constant is unitary.

    Example:
    Given the individual concept ‘London-Heathrow Branch’ defined as “the EU-Rent branch
    located at London-Heathrow Airport”, the constant expressed as the name 'London-Heathrow Branch' refers to that EU-Rent branch in all occurrences.

    2. In the definition of 'bindable target', replace all occurrences of 'text' with 'constant'.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    A bindable target can be a variable, an expression (including a text) or an individual concept. The meaning of an individual constant is an individual concept. The resolutions to issues 9586 and 10570 clarify the distinction between binding to an expression and to an individual concept. The meaning of binding to an individual concept is explained - the binding references the one instance of the individual concept. In addition to the changes made in the resolutions to issues 9586 and 10570, an additional clarification is made in a note.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

True/False meaning of logical formulations must be specified

  • Key: SBVR-72
  • Legacy Issue Number: 9729
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1, 'logical formulation' is defined as:
    "semantic formulation that is an abstract interpretation of a well-formed logical formula"

    One may ask why it isn't just the expression as a wff. A Note to the effect that this is some kind of computational "abstract syntax" for a wff would help in putting this clause in perspective.

    A 'closed logical formulation' has the property:
    The meaning formulated by each closed logical formulation is a proposition.

    It should be Noted that every kind of logical formulation can be closed by binding all of its free variables to constants. Consequently, it is important that every kind of 'logical formulation' specifies, for the case, in which it is closed, the circumstances under which the corresponding proposition is 'satisfied' or 'true', and those under which it is 'false'.

    9.1.1.2 atomic formulation does not specify this.
    9.1.1.3 instantiation formulation does not specify this.
    9.1.1.4 modal formulation is a convenience concept, only its subtypes have meaning, and they do not specify it.
    9.1.1.6 logical operation is a convenience concept, only its subtypes have meaning, and they do not specify it.
    9.1.1.7 quantification is a convenience concept, only its subtypes have meaning, and they do not specify it.
    9.1.1.8 objectification does not specify this.
    9.1.1.9 projective formulation is a convenience concept, only its subtypes have meaning
    aggregation formulation does specify this, but in a Note.
    noun concept formulation does specify this, but in a Note.
    fact type formulation does specify this, but in a Note.
    proposition nominalization does specify this, but in a Note.
    question nominalization does specify this, but in a Note.
    answer nominalization does specify this, but in a Note.

    Recommendation:

    Add a Note to the glossary entry for 'closed logical formulation' that every kind of logical formulation can be closed by binding all of its free variables to constants, and thus formulates a proposition that is either true or false.

    For each kind of logical formulation, specify the true/false/satisfaction behavior of the closed form in the normative/definitive text, e.g., the Definition, and not in a Note.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of noun concept formulation

  • Key: SBVR-71
  • Legacy Issue Number: 9728
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.9
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In clause 9.1.1.9, 'noun concept formulation', the definition is
    "projecting formulation of a referent noun concept whose intension is formulated in a particular projection"

    a. It is not clear in this definition what 'referent noun concept' is being referred to.
    b. 'projecting formulation' as a GeneralConcept has no semantics. Use 'logical formulation'?
    c. This apparently means that the noun concept is defined to be the set that is the projection, which is the extension, not the intension. (I suppose the intension is "is a member of that set".) The problem here is that while a projection has the form of an intensional definition, it has the semantics of an extensional definition. Perhaps the problem is that this use of the projection syntax does not have the same semantics as other uses.
    d. This definition provides no indication as to the role of the bindable target (from 'projecting formulation'). The thing being defined is a noun concept – not a variable, although perhaps a constant – so the bindable target must enter into the definition, but the note says there is some "understood reference".
    e. This definition is only a 'logical formulation' if the noun concept is treated as a classifying predicate, like an instantiation formulation. And in that case, the bindable target would be the thing whose referent is to be tested for membership in the projection set.
    f. In the closed form, one possible interpretation of this construct is that it is a test for whether the bindable target is a member of the projection set. If that is the case, it would certainly be helpful to the reader to say exactly that, at least in a Note.
    g. One possible 'open form' would apparently define a function of the bindable target whose result is the closed projection that corresponds to the substitution of the bindable target for the (sole?) free variable in the projection, but that is not a logical formulation in that its meaning is not a proposition.
    h. Of itself, the open form does not define a noun concept. There must be a further requirement that all free variables in the projection are bound in the context in which the would-be noun concept is 'defined'. And what this means is that a noun concept formulation is only well-defined when it is closed by substitution. All of this should be part of the definition and not of some attached Note.
    i. Another possible interpretation is that this really was intended to represent the definition of a term to refer to a noun concept defined by an intensional formulation. In that case, the 'bindable target' should be a constant (text?) whose referent is being defined, the noun concept formulation should introduce a single variable, and the intensional definiens should be a logical formulation with exactly one free variable, and that variable corresponds to the variable introduced. No projection ("set") is involved.

    "Note: A noun concept formulation is satisfied for each referent that is a noun concept defined by the projection."
    Whatever this was supposed to mean, it is wrong. A noun concept formulation is satisfied if the referent of the bindable target is actually in the set defined by the projection.

    The Examples are strangely phrased. E.g. in the 2nd example, the noun concept formulation is: 'the distance that is the reading of the rental car's odometer', and anything that satisfies that formulation IS a distance, because 'distance' is the concept over which odometer-reading(?car) projects.
    The 'distance concept' is in the formulation, but the referents are individual distances.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is an aggregation formulation?

  • Key: SBVR-70
  • Legacy Issue Number: 9727
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.9
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    Recommendation:

    In 9.1.1.9, the definition of 'aggregation formulation' is difficult to interpret. It seems to say it is an assertion of equality between two sets (or multisets), one of which is the value of a variable (bindable target?) and the other is the result of the projection. If that is what is intended, at least a Note should say this.

    And in the Example about averages of ages, it is difficult to tell exactly what is supposed to be the 'aggregation formulation'. The model is:
    AVERAGE( project car.age from car such that car is-owned-by b such that b is local-branch )
    that is, a function of a projection that is based on a selection that is based on a selection. Which of these four operations is the aggregation formulation? But the logical formulation that is the rule has the form:
    number is-less-than number
    where the first number is the result of the 'average' function (which has no SBVR model I can find).

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Provide a better definition of 'aggregation formulation'. Remove the note. Improve the example and give its full formulation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is a projecting formulation?

  • Key: SBVR-69
  • Legacy Issue Number: 9726
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.9
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.9, the definition of 'projecting formulation' is obscure. How is 'a thing considered with respect to a projection' true or false. It might mean 'x occurs in the set resulting from projection y', but that wouldn't have 3 or 4 confusing subtypes. Or it might mean the set produced by a 'projection' (considered as some kind of function). It seems to be a supertype with no direct usage, e.g. 'semantic formulations that involve projections', and it models several relationships at a uselessly abstract level.

    It is said to be a 'logical formulations', but with the possible exception of 'aggregation formulation', the subordinate concepts are not 'logical formulations'.

    Recommendation:

    Delete the concept 'projecting formulation'.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add a note to the entry for 'projecting formulation'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of objectification is unclear

  • Key: SBVR-68
  • Legacy Issue Number: 9725
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.8
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.8, Objectification: The intent here is completely obscure.

    The example refers to a use that isn't at all clear. It appears to be two fact-types that are synonymous forms: 'car is assigned to rental' and 'car assignment of car to rental'.

    If the intent is to construct a noun concept from a fact-type, the definition should say that, and the example should illustrate that. Alternatively, it is possible that an objectification is just a 'proposition nominalization' for an 'atomic formulation'.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

quantifications based on cardinality

  • Key: SBVR-67
  • Legacy Issue Number: 9724
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.7
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    General problems in clause 9.1.1.7:

    a. Logical quantifications are intensive; they do not require the materialization of the set of satisfying instances. Cardinality quantifications are extensive; they require materialization of the set. It is not clear that the extensions of all SBVR concepts are sets, and it is clear that many of them cannot be materialized. In general, cardinality-based quantifications can only apply to projections.

    Note: The intensive version of the "at most 1" quantification for a predicate P is a "uniqueness rule" (a Necessity): IF P AND P THEN x = y. So it is possible to specify "at most 1" and "exactly 1" quantification without using cardinalities.

    b. Cardinality requires a notion of "equality" defined on the instances from which the set is drawn. Otherwise cardinality cannot be measured. SBVR appears to introduce this concept via Reference Schemes, but it does not do so explicitly in discussing cardinality.

    c. The current definitions of the cardinality-based 'quantifications' (at least n, at most n, etc.) refer to undefined operations.

    Other problems:

    In what fact-type is Cardinality a role?
    Cardinality is a property of a set, that is, a fact-type about a set, viz. 'set' has cardinality 'non-negative integer'.

    The definitions of maximum and minimum cardinality are meaningless. These terms are roles in some unspecified fact types that make use of 'integer' is less than 'integer'.

    Recommendation:

    Before Cardinality, insert new section heading.

    Change the definition of 'cardinality' to read:
    non-negative integer designating the number of distinguished things in a collection

    Specify the fact-types in which maximum and minimum cardinality are 'roles'. Or don't bother and specify cardinality quantifications as fact-types. E.g. at-most-n quantification:
    X has at most n Ys
    is interpreted:
    for any given X, the cardinality of the projection = 'set of all Y such that X has Y' is-less-or-equal n
    Note that such a construct IS a logical formulation, but it is NOT a "logical quantification".

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add the fact type 'set has cardinality'. Explain the relevance of distinguishability for quantifications other than universal and existential quantification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Quantification definitions

  • Key: SBVR-66
  • Legacy Issue Number: 9723
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1.7
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.1.1.7, the model of quantification shows it to be a kind of logical formulation that MAY (0..1) scope over a logical formulation. A quantification has to "scope over" something. And it binds a variable in that something. The definition does not reflect this requirement.
    Further, iIf a quantification doesn't 'scope over' a logical formulation, it isn't itself a logical formulation. A logical formulation represents a proposition that is true or false.

    If necessary, define logical quantification with the well-defined properties and define some other kind of quantification for whatever else a quantification may "scope over".

    Recommendation:

    In the entry for 'quantification'
    a. Modify the definition of quantification to read:
    logical formulation that applies a logical quantification operator to a free variable in the logical formulation that the quantification scopes over.

    b. Add a Note
    Note: the variable must be free in the logical formulation scoped over. The quantification binds that variable in the resulting logical formulation.

    c. Modify Necessity (3) to read:
    Necessity: Each quantification scopes over exactly one logical formulation.
    (Not "at most one".)

    In the entry 'logical formulation restricts quantification', At the end of the Note, add:
    The logical formulation represented by the quantification is logically equivalent to scoping over the conjunction of the logical formulation that restricts the logical quantification with the logical formulation it scopes over."

    In the entry 'universal quantification', replace the text of Definition with:
    quantification that is true if the logical formulation it scopes over is true for all admissible referents of the variable, and false in any other case.

    In the entry 'existential quantification', replace the text of Definition with:
    quantification that is true if the logical formulation it scopes over is true for any admissible referent(s) of the variable, and false only if it is true for no admissible referent.

    Add Note: An existential quantification is equivalent to an at least n quantification where n=1.

  • Reported: SBVR 1.0b1 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Make the definitions of the different kinds of quantification more precise. Add notes for clarity.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - wrong proposition in 8.1.2 and modal formulation

  • Key: SBVR-65
  • Legacy Issue Number: 9721
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.1.2, 'obligation' is defined as follows:
    "Definition: proposition that is required to be true, that is obligatory, that is not permitted to be false"

    And 'permission', 'necessity' and 'possibility' are similar.

    The problem is that an obligation is not a proposition that is required to be true. It is rather a proposition that requires another proposition be true.

    Example:
    "It is an obligation that every rental car has a scheduled service."
    The proposition
    'Every rental car has a scheduled service'
    is what the obligation requires to be true. But that proposition itself is not an obligation. It is just a statement, like "all roads lead to Rome".

    The 'obligation' is:
    "It is an obligation that every rental car has a scheduled service."
    or equivalently:
    "Every rental car is required to have a scheduled service."
    which is a different proposition.

    The obligation itself is a proposition that (per the definition of 'proposition') can be true or false – that 'obligation' may or may not actually be a rule at UDriveIt.

    The Note under the glossary entry for 'modal formulation' has this same error. It says:
    "The meaning of a modal formulation is the proposition that the proposition meant by the embedded logical formulation is an instance of the modality claimed by the modal formulation."

    I read this to say that the meaning of
    "It is an obligation that every rental car has a scheduled service."
    is the proposition:
    "(The proposition) 'every rental car has a scheduled service' is
    an (instance of) obligation."
    This is incorrect. As above, the embedded proposition 'every rental car has a scheduled service' is not an obligation. The obligation is the meaning of the modal formulation itself.

    That is, the meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation.

    Recommendation:

    In 8.1.2,

    a. change the definition of 'necessity' to
    "proposition that another proposition is necessarily true, always true"

    b. In the definition of 'possibility', after "proposition that" insert "another proposition"

    c. In the definition of 'obligation', after "proposition that" insert "another proposition"

    d. In the definition of 'permissiblity', after "proposition that" insert "another proposition"

    In 9.1.1,

    a. Replace the text of the Note under 'modal formulation' with:
    "The meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation."

    b. Under the entry for 'modal formulation claims modality', add a note:
    Note: The meaning of 'modal formulation claims modality' is that the proposition meant by the modal formulation is an instance of the concept that corresponds to the modality.

  • Reported: SBVR 1.0b1 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove 'modality' from chapter 8 - modal concepts are covered in chapter 10.
    Replace the terms 'necessity', 'possibility', 'obligation' and 'permissibility' with characteristics that apply to propositions, and define them formally in such a way that the definitions invoke the appropriate modal formulations.
    Change the definitions of 'modal formulation' and the concepts that specialize it to be stated in terms of possible or acceptable worlds. Change the designations of those concepts that end with the word "claim" to end with the word "formulation".
    Add 'possible world', 'acceptable world' and 'Universe of Discourse' to the Formal Logic & Mathematics Vocabulary.
    Some of the vocabulary items being replaced are used in examples. Change the examples to use other items.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of 'proposition'

  • Key: SBVR-64
  • Legacy Issue Number: 9715
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 8.1.2
    Pages: 18
    Nature: Editorial
    Severity: minor

    Description:

    In 8.1.2, the definition of 'proposition' says:
    "meaning that is asserted when a sentence is uttered or inscribed and which is true or false"

    If the meaning is asserted when the sentence is uttered, the proposition is taken by the speaker to be true. Whether the meaning corresponds to the actual 'state of affairs' determines whether it is true or false, and even then not when the sentence is in the future tense. I think the intent here is: "meaning that is asserted by a sentence", full stop. Whether it is true, false, unknown, possible, etc., is irrelevant to the definition. And the time of the utterance ("WHEN it is uttered") is not intended to be important to the meaning of an arbitrary proposition.

    The definition of 'question' in 8.1.3 uses the undefined term 'interrogatory', but is probably intended to be distinct from 'proposition'. This means that a proposition is not the meaning of an interrogative sentence, and therefore not of an arbitrary sentence, but only of a declarative sentence.

    Recommendation:

    In 8.1.2, replace the definition of 'proposition' with:
    "meaning that is asserted by a declarative sentence"

    For consistency, in 8.1.3 replace "interrogatory" with "interrogative sentence".

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    A proposition is a meaning; a sentence is an expression of a meaning. The same sentence, however, can express more than one meaning, e.g., when stated by different persons at different times, or in different contexts of reference. So it is important to separate the proposition from its expression, and not to define 'proposition' in terms of sentences.

    In terms of kinds of meaning, a proposition is distinguished from a concept by having a characteristic that is a "truth value" - true or false. The referent of a proposition is a conceptual/potential state of affairs that may or may not be an actual state of affairs.

    Issue 10621 deals with questions and their relationships to other kinds of meaning, including propositions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of 'modality' in 8.1.2

  • Key: SBVR-63
  • Legacy Issue Number: 9714
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 8.1.2
    Pages: 19
    Nature: Correction
    Severity: minor

    Description:

    8.1.2 defines 'modality' (a pure mathematical logic concept) so that it can be the ConceptType for 'necessity', 'possibility', 'obligation' and 'permissibility'.

    But in fact, 'necessity' is said to be a kind of 'fact', and the others are said to be 'propositions'. That is, the corresponding GeneralConcepts are not 'modality'. And they are not individual concepts, so they shouldn't have a ConceptType.

    Recommendation:

    a. Move the glossary entry for 'modality' to 9.1.1, or delete it if it is used nowhere else.

    b. For 'necessity', replace "ConceptType: modality", with
    "GeneralConcept: fact"

    c. For 'possibility', 'obligation' and 'permissibility', replace
    "ConceptType: modality",
    with
    "GeneralConcept: proposition"

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Was a problem in interpreting SBVR Structured English. Not a problem with the specification. Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Projection position and reference scheme for variables

  • Key: SBVR-62
  • Legacy Issue Number: 9713
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1
    Pages: 101
    Nature: correction
    Severity: minor

    Description:

    In the definition of 'variable' in 9.1.1, there are two Reference Schemes given for variables. The one for projection variables indicates that the scheme is a pair (projection, variable range concept).

    In 9.1.2, the definition of 'projection position' says that it "distinguishes a variable", but it is not mentioned in the reference scheme in 9.1.1.

    But 9.1.2 defines the 'projection position' to be the reference scheme for 'auxiliary variable'. Since an auxiliary variable could have the same range concept as the primary range variable for the projection, the reference scheme in 9.1.1 cannot be correct. The scheme given in 9.1.1 should be the same as that for auxiliary variable, and then it need not be restated for auxiliary variable.

    Further, the reference scheme given for logical variables in 9.1.1 is:
    "a quantification that introduces the variable and the set of each concept that is ranged over by the variable and whether the variable is unitary".

    This is mostly unnecessary. The reference scheme is the quantification that introduces the variable, full stop. The scope of the quantification is the scope in which the variable refers to that one.

    Now, since variables do not appear to be distinguished by type: logical variable vs. projection variable, it is difficult to manage incompatible reference schemes, when both kinds can appear in the logical formulation that is the selection criterion for a projection! So variables have to have either a common reference scheme or have distinguished subtypes with distinguished reference schemes.

    Recommendation:

    a. Define two subtypes of variable, 'logic variable' or 'quantified variable' in 9.1.1 and 'projection variable' (in lieu of 'auxiliary variable') in 9.1.2.

    b. For the logic variable, the reference scheme should be: the quantification that introduces the variable.

    c. For the projection variable, the reference scheme should be as given for 'auxiliary variable' in 9.1.2.

    (I'm not sure this really solves the problem for parsing logical formulations that appear in projections.)

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Clarify the use of reference schemes for semantic formulations in the introduction to Clause 9.
    Fix the references schemes for 'variable' and 'auxiliary variable' so that they involve the complete structure (as is done for all parts of semantic formulations).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definitions of 'projection'

  • Key: SBVR-61
  • Legacy Issue Number: 9712
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Name: Definitions of 'projection'
    Doc: dtc/06-03-02
    Date: March 2006
    Version: Interim Convenience Document
    Chapter: 9.1.1
    Pages: 101
    Nature: Revision/correction
    Severity: Significant

    Description:

    9.1 defines 'semantic formulation' as: conceptual structure of meaning.

    9.1.2 defines 'projection' as: semantic formulation that operates over one or more variables and results in a set or multiset.

    How does a 'conceptual structure' 'operate' or 'result'? Structure is a static notion. A 'projection' must rather be a semantic formulation whose meaning is the SET – the conceptual structure – that results from applying a function to some collection of things.

    The term 'multiset' is undefined, and does not have a NODE definition (it's IT jargon). In a formal model, a 'multiset' is either a set of pairs (thing, occurrence), each of which has a reference scheme, or a set of pairs (thing, count), for which thing has a reference scheme and count is a nonnegative integer. Whichever definition is chosen, if any, the conceptual structure of the projection is a SET. The only question is what it is a set of.

    The example of a 'bag projection' indicates that the result is actually a set of pairs (balance, customer) and then says: "Only balances are in the result, but there can be duplicates where multiple customers have the same balance." This is true in SQL, but it has nothing to do with reality or logic. It can only be true in business if the result somehow carries the customer notion with the balance – a different line, a different position, a different memory cell – so that occurrences can be distinguished. In SQL, the result is a LIST of balances with distinguished positions, a SET of pairs (position, balance).

    The projection (set) doesn't result from applying a function to 'variables', it results from applying the function to the things the variables range over.
    So the concept 'variable ranges over concept' from 9.1.1 is critical to the meaning of a projection! (Note that much of the discussion of 'variables' in 9.1.1 is about projections and not about 'variables' in logical predicates.)

    The projection is not 'on a variable'. A projection INTRODUCES a variable to denote the individual concepts in the range from which the result set will be extracted. The logical formulation that constrains the projection is called the 'selection criterion'. It involves the projection variable as a 'free variable'. Each individual concept for which the selection criterion holds appears in the result set.

    In addition to projections, there are mathematical functions whose operands are sets and whose results are simple values, like 'average'. These should not be confused with projections. In the example "the average of ages of rental cars owned by each local area", the conceptual structure is a TABLE of cars with ages, created by the "projection"
    TableOfAges =

    { c: OwnedCars, a: Age | (CarHasAge c a) }

    over the projection
    OwnedCars =

    { c: Car | (Exists b: branch)(owns b c) }

    but the result of interest is the function
    AverageOfColumn(TableOfAges, Age)
    which is not a projection or anything the like.

    If database Select and Project operations and arbitrary mathematical functions whose operands can be structures are all part of "semantic formulations", let us call a spade a spade. The relational database formulation of "semantics" is well understood, and we can use that. The current text for projections does not have any hope of capturing meaning.

    Recommendation:

    The real fix:
    a. Define the 'relation' concept, and the cross product, select and project operations a la relational algebra. It is a perfectly usable form of "semantic formulation": "relational formulation"
    b. Provide a concept for mathematical function that applies to arbitrary operands.

    The minimal fix:
    a. Correct the definition of projection, and decide on the model of projection (result) to be used.
    b. Repair or delete the concepts bag projection and set projection according to the model chosen.
    c. Correct the definitions of the relationships among the projection, the range variable(s), and the selection condition.
    d. Eliminate 'auxiliary variable'. It is either a logical variable in the selection condition (logical formulation) or a (parallel) range variable depending on the model of projection results.
    e. Remove the example about the average of ages of rental cars, and other such examples, whose formal representation is well out of the scope of SBVR.

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Replace the definition of 'projection'. Split the fact type 'closed projection defines concept' into two fact types, one for noun concepts and the other for fact types, and explain them separately with examples.
    Explain 'projection' with respect to its different uses. Move Necessity statements under 'closed projection' to be under fact types for the different uses. As a way of aiding the clarity of its uses, change the signifier of 'noun concept formalization' to 'noun concept nominalization' and reinstate 'fact type formulation' as 'fact type nominalization'.
    Projections are related to meanings through the following fact types:
    1. closed projection defines noun concept
    2. closed projection defines fact type
    3. close projection means question
    The first two are fully explained and exemplified in this resolution. The third is already fully explained with an example.
    Also, projections are used in the five types of projecting formulations. Each of those is already fully explained with examples except for 'fact type nominalization' which is explained with examples in this resolution. Note also, three of those five are correlated with the three relations to meaning listed above. The three are, respectively:
    1. noun concept nominalization
    2. fact type nominalization
    3. question nominalization

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of Body of Shared Guidance

  • Key: SBVR-60
  • Legacy Issue Number: 9711
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    SBVR’s definition of ‘body of shared guidance’ uses the word ‘guidance’ styled as a term. But no term ‘guidance’ is in the SBVR vocabularies. The word should either be unstyled or else replaced with the defined term ‘elements of guidance’.

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Use the defined term 'element of guidance'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR Issue - Circular definition of logical operator and logical operand

  • Key: SBVR-59
  • Legacy Issue Number: 9709
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The definitions of 'logical operator' and 'logical operand' are circular.
    From 9.1.1
    logical operator - logical formulation that operates on a logical operand
    logical operand - logical formulation upon which a logical operation operates

    Recommendation:

    Redefine 'logical operator', e.g., to:
    logical formulation whose meaning is derived from the meanings of one or more other logical formulations by a particular semantic relationship.

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Replace the definition of 'logical operation'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

business jurisdiction

  • Key: SBVR-58
  • Legacy Issue Number: 9708
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Section 12.1.2 defines "business rule" as a "rule that is under business jurisdiction". This is a key definition, yet it is not clear what "under business jurisdiction" really means. Presumably a law of physics is not "under business jurisdiction", hence is not a rule. How about a national or state law? How about a regulation? A standard or best practice?

    Something like "All transactions must be archived for three years" seems like a rule. Say it starts as a rule created by a particular company for itself, hence is clearly a "business rule." Over time, it evolves to an industry standard and maybe a regulatory requirement. Has it morphed from a "business rule" to something else because it is no longer "under business jurisdiction?" What kind of rule is it once no longer "under business jurisdiction?"

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Explanation in blue, indented
    Section 12.1.2 defines "business rule" as a "rule that is under business jurisdiction". This is a key definition, yet it is not clear what "under business jurisdiction" really means.
    It means that the semantic community, typically a business, governed by the rule can opt to change or discard the rule. See section A.2.3.
    Presumably a law of physics is not "under business jurisdiction", hence is not a rule.
    It's not a business rule.
    How about a national or state law? How about a regulation? A standard or best practice?
    These things are not business rules for businesses that have them imposed from outside. Such businesses will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.
    Similarly, businesses will decide how to adopt standards or best practices, and will create business rules to ensure that they are implemented as intended.
    Something like "All transactions must be archived for three years" seems like a rule. Say it starts as a rule created by a particular company for itself, hence is clearly a "business rule." Over time, it evolves to an industry standard and maybe a regulatory requirement. Has it morphed from a "business rule" to something else because it is no longer "under business jurisdiction?" What kind of rule is it once no longer "under business jurisdiction?"
    If the company that created the business rule gives up its ownership, and no longer has authority to change it, then the artifact is no longer a business rule for that company. It's an externally owned regulation that is imposed on the company or an industry standard that can be adopted by the company.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the "business vocabulary" in 10.3

  • Key: SBVR-57
  • Legacy Issue Number: 9707
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 10.3 says it is a mapping from "the selected subset of (important) SBVR business terms" to the formal logic terms in 10.1.2. It is not clear how these terms were selected. They are all drawn from clause 8 and 9, but they don't correspond to any defined vocabulary, and they are not complete with respect to clause 8 or 9. Those terms that are defined in Clause 9 should apparently be mapped in 10.2. Those coming from clause 8 should represent an organized set of concepts.

    All of 8.1 is covered except for 'concept' and 'question'.
    8.2 is not covered.
    8.3 is not covered at all, except for 'statement'.
    8.4 is covered, but the mapping is nonsense. Reference schemes have no counterpart in mathematical logic.
    8.5 is covered.
    8.6 is covered.
    8.7 is covered.

    9.1[only] is covered but the mapping is nonsense. A "semantic formulation" doesn't necessarily correspond to a logical proposition or predicate; it may be defined by the mathematics of sets or arithmetics or functions.
    9.1.1 is covered, except for question nominalization and answer nominalization.
    9.1.2 is covered in theory, but the mapping is nonsense. A projection is an operation on sets that has no logical result, although it may involve a logical formulation.

    Many terms that are said to be adequately mapped by their supertypes in 10.3.3 are not, in that the subtype creates an importantly different mathematical logic interpretation.

    And most of the subtypes of quantification defined in clause 9 have no image in mathematical logic. (Clause 10 would have to introduce set theory and model cardinality and basic arithmetic to support these.)

    Recommendation:

    a. Move and correct the mappings of terms defined in clause 9.1.1 from 10.3 into 10.2. (This may depend on other issues related to clause 9.1.1.)

    b. Define the 'sub-vocabulary' of Clause 8 for which what remains in 10.3 defines a mapping, complete and correct the mapping of that vocabulary.

    c. Delete the mappings for the terms from 9.1[only] or 9.1.2.

  • Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution to Issue 9959.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping SBVR logical formulation terms to formal logic terms

  • Key: SBVR-56
  • Legacy Issue Number: 9623
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 10.2 promises a formal mapping from the "logical formulation vocabulary" in clause 9.1.1 to the mathematical logic vocabulary presented in 10.1.2. But the content of clause 10.2 is empty. No such mapping is provided.

    Note that several logical concepts defined in 9.1.1 (e.g. negation, conjunction, disjunction, equivalence) have no direct cognates in the vocabulary presented in 10.2. For these concepts, either 10.1.2 must be expanded to include the definitions, or the mapping table must specify the equivalent logical formula (wff) as a composition of implications.

    Note further that Clause 10.2 defines many of its terms as elements of a grammar for a surface syntax (expression) for the logical concepts defined here and there in clause 10.1. Clause 9.1.1 appears to define an abstract syntax for the same purpose. There is no reason why these two grammars should not describe the same expressions.

    Recommendation:

    Provide the mapping, revising clause 9.1.1 and/or 10.1.2 as needed to align the grammars.

  • Reported: SBVR 1.0b1 — Wed, 10 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution of Issue 9959.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex E/EU-Rent vocabulary's 'characteristic' entries

  • Key: SBVR-55
  • Legacy Issue Number: 9621
  • Status: closed  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

    There are some inconsistencies between Annex C (which explains proper SBVR
    Structured English) and Annex E (which illustrates proper usage of SBVR
    Structured English), as follows:

    point-1) The unary fact type definitions are not written as fact type
    definitions – i.e., beginning with a definite article ("the") plus the
    placeholder term, and then saying something propositional. Instead, they
    are written in the style appropriate to a noun concept – i.e., leading with
    a term, followed by restrictive clauses.

    point-2) The form of expression of the entry concept uses a participle –
    e.g., 'having' or 'being') rather than an active verb. I was told that, in
    SBVR Structured English, using the participle implies meaning in addition to
    the naked fact type. That additional meaning is generally handled within a
    semantic formulation that uses the fact type.

    point-3) There is some ambiguity about the use of quantifiers (etc.) in the
    form of expression. (ref. SBVR p. 201, final sentence of C.3.1), which
    says, "It is recommended that quantifiers (including articles) and logical
    operators not be embedded within designations and forms of expression."
    Often we see a 'characteristic' (unary fact type) that uses an article
    or quantifier. Is that incorrect? Or does 'unary fact type' have a
    different set of guidelines for its form of expression?

  • Reported: SBVR 1.0b1 — Wed, 10 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    point-1) Unary fact type definition expressions, when presented using the SBVR Structured English Definition caption, should be written in the standard way for fact type definitions, i.e., beginning with a definite article ("the") plus the placeholder term, and then saying something propositional. Any Annex C definitions that are written in a style appropriate to a noun concept – i.e., leading with a term, followed by restrictive clauses – should be corrected during the general pass to correct Annex E (if retained as Definition-captioned text).
    point-2) The present participle form is an alternative for the fact type form of an entry concept. The Annex C explanation needed a small change to make this clear. (See below.)
    point-3) It was confirmed that the C.3.1 statement (cited in the Issue statement) applies to all designations and fact type forms. However, it is a guideline, which does not make any such cases in Annex E necessarily wrong.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

dictionary basis

  • Key: SBVR-54
  • Legacy Issue Number: 9614
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Much of the recent discussion of "rule" and "actionable" have swirled around the use of "dictionary basis". I decided to have a look at what "dictionary basis" actually means in SBVR.

    It's not defined in the normative part of the standard. It appears in Annex C (C.3.4), where the following description is given:

    This caption labels a definition from a common dictionary that supports the use of the primary representation. The entry source reference (written in the ‘Source’ style described above) is supplied at the end of the quoted definition. A dictionary basis should not be interpreted as an adopted definition.

    Have I missed a seeing a definition somewhere else? If not, perhaps we should include this term in the normative part of the standard so it can be given a tighter definition? Most other captioned items have SBVR definitions. It's obviously a source of some confusion.

    The above definition clearly indicates "not interpreted as an adopted definition." I had always thought dictionary basis "informs" a definition ... provides background, source ideas and insight ... but does not in and of inside need to be complete. Wouldn't it be the case that several definitions need to be aggregated to form a complete picture (basis)?

    Anyway, it had never occurred to me this might be a problem until the recent discussions. Does it need to be raised as an issue?

  • Reported: SBVR 1.0b1 — Fri, 21 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    closed , no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapters 8,9,11,12

  • Key: SBVR-53
  • Legacy Issue Number: 9613
  • Status: closed  
  • Source: Rule ML Initiative ( Donald Chapin)
  • Summary:

    "Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' – (the way many of the SBVR concepts are defined). 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning.

  • Reported: SBVR 1.0b1 — Wed, 10 May 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    This Issue is too big to resolve in one piece. It has been broken into manageable pieces as, and replaced by, Issues 10571, 10572,, 10573, 10574, 10575, 10576

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A fact is not a logical formulation

  • Key: SBVR-52
  • Legacy Issue Number: 9609
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Page 103 of SBVR says ‘fact’ is “logical formulation that is taken as true…”, but a fact is a proposition and a logical formulation is not a proposition

  • Reported: SBVR 1.0b1 — Tue, 25 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Change the entry for "fact" in the table on page 103

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification Remnants

  • Key: SBVR-51
  • Legacy Issue Number: 9608
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Pg. 209, C.5 uses “Clarification Statement”, which is an out-of-date signifier left over from an earlier SBVR submission.

    C.5, page 209, change “<Rule Statement or Clarification Statement>” to “<Guidance Statement>”.

    C.5.1, page 209, change the section title from “Rule Statement or Clarification Statement” to “Guidance Statement”. And then change the beginning of the paragraph from “rule statement or clarification statement” to “guidance statement”.

    C.5.2, page 209, change “rule or clarification.” to “element of guidance”.

  • Reported: SBVR 1.0b1 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Body of Shared Meanings

  • Key: SBVR-50
  • Legacy Issue Number: 9607
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The dictionary basis of ‘body of shared meanings’ is the dictionary definition of ‘universal set’, which is way off track and can only produce confusion. No body of shared meanings is the universal set.

    Since ‘body of shared meanings’ is defined with respect to “a given semantic community”, why isn’t it a ‘role’. A set of concepts and guidance that is a body of shared meanings of one community is not necessarily a body of shared meanings for another community, but it is still a set of concepts and guidance.

    Either the second necessity listed under ‘semantic community understands body of shared meanings’ is incorrect or there needs to be a definition of that fact type that gives a particular meaning of “understands” that is different from normal usage. The contradiction is seen in a simple example. Assume a semantic community EU-Rent has a subcommunity EU-Rent Mechanics. EU-Rent Mechanics’ body of shared meanings includes everything in EU-Rent’s and more. Both EU-Rent and EU-Rent Mechanics understand the body of shared meanings that is understood by EU-Rent, which contradicts the necessity that “Each body of shared meaning [sic] is understood by exactly one semantic community”.

    I suspect that the necessity is what is intended and that making ‘body of shared meanings’ a role and simply using the verb “has” rather than “understands” will clear things up.

  • Reported: SBVR 1.0b1 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove the Dictionary Basis under 'body of shared meanings'.
    Replace 'semantic community understands body of shared meanings' with 'body of shared meanings unites semantic community' and add a note.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding to Individual Concepts

  • Key: SBVR-49
  • Legacy Issue Number: 9586
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In semantic formulations, only variables and text are bindable targets. Because a role binding cannot bind to an individual concept, the formulation of rules involving individual concepts are overly large and complicated. For example, a formulation of something a simple as “1 + 2 = 3” must involve three quantifications and three variables, but it should be accomplished with a single atomic formulation. Or a formulation of “EU-Rent uses FedEx” must have quantifiers and variables for EU-Rent and for FedEx.

    An early submission of SBVR had individual concepts as bindable targets. This was removed because individual concepts do not necessarily have the same extension across all time and in all possible worlds. Binding directly to individual concepts might not work when formalizing statements like “The President was once not the President” or “In 1776 there was no Statue of Liberty”. Explicit quantification would guarantee a precise formulation in all cases.

    However, there is a way to allow binding to individual concepts while preserving precision. The way is to rigorously explain what is meant by a binding to an individual concept, and to explain it in terms of quantification. If that is done, then all bindings to individual concepts have a precise meaning. Special cases can continue to be handled using quantification.

  • Reported: SBVR 1.0b1 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add 'individual concept' into the extensional definition of 'bindable target'. Explain precisely the meaning of a binding to an individual concept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 296

  • Key: SBVR-48
  • Legacy Issue Number: 9580
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Problem Description Under the list of Operative Rule Keywords in the first paragraph of the page, the following is listed: << only ... often as in 'only if' ... rule keyword >> The actual full rule keyword is "may ... only". "Only" may not be used without "may". "Only" produces a restricted permissive form of a rule; "may" must be present to indicate that permission is being restricted. (Note: the corresponding structural rule keyword is "can ... only", which is given correctly in the list for the next paragraph on that same page.) Proposed Solution: 1. Change << only ... often as in 'only if' ... rule keyword >> to: << may ... only ... often as in 'only if' ... rule keyword >> 2. In the third paragraph of text, item 1, which reads: ‘Should’ may be used in place of ‘must’ in expressing a business rule only if one of the following is true: • The business rule does not have an enforcement level. • The business rule has an enforcement level, and that enforcement level is consistent with the English sense of ‘should’. ... change the very first "may" (second word in the extracted text) to styled text for rule keyword.

  • Reported: SBVR 1.0b1 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Logic Rule" issue

  • Key: SBVR-47
  • Legacy Issue Number: 9579
  • Status: closed  
  • Source: Neumont University ( Tony Morgan)
  • Summary:

    The root of many problems is the flawed definition of "rule" in SBVR,
    which differs from the sense that was intended in the formal logic
    appendix. The SBVR definition is also at odds with the dictionary
    definition of "rule" and includes some riders that seem a little
    bizarre.

    The intended meaning of "rule" in the formal logic appendix was the
    dictionary meaning of the term. The definitive source (the ODE - Oxford
    Dictionary of English) has the following:

    Rule (core meaning)
    "One of a set of explicit or understood regulations or principles
    governing conduct or procedure within a particular area of activity."

    Rule (main subsidiary meaning)
    "A law or principle that operates within a particular sphere of
    knowledge, describing or prescribing what is possible or allowable."

    You will recall that when we tried to make such a definition explicit in
    the revision of the formal logic appendix there was vehement opposition
    from some members of the FTF, and we were obliged to indulge in the
    unhappy compromise of using the term "logic rule" to mean the above
    (although it is indeed the correct definition of "rule").

    By the way, the ODE defines "logical" as:
    "Of or according to the rules of logic."
    (and, yes, it does dare to say "rules"!)

    In contrast, here are the relevant SBVR definitions:

    ======================================================

    rule
    Definition: element of guidance that introduces an obligation or a
    necessity Dictionary Basis: standard by which something is judged or
    valued; criterion [MWUD (2B) 'rule'] Dictionary Basis: principle or
    standard by which something may be judged or decided [determined] [NODE
    'criterion'] Dictionary Basis: standard on which a judgment or decision
    may be based [MWCD (2) 'criterion']

    element of guidance
    Definition: directive that is actionable, whose purpose is to advise or
    inform with a goal of resolving a problem or difficulty, especially as
    given by someone in authority
    Necessity: No business policy is an element of guidance.

    directive
    Definition: means that defines or constrains some aspect of an
    enterprise General Concept: proposition
    Note: This sense of 'means' (as in 'ends and means', rather than 'is
    meant as') arises from the Business Motivation Model.
    Note: Intended to assert business structure or to control or influence
    the behavior of the enterprise.
    Note: Its formulation is under the enterprise's control by a party
    authorized to manage, control or regulate an enterprise, by selection
    from alternatives in response to a combination of assessments.
    Dictionary Basis: an official or authoritative instruction [NODE]

    directive is actionable
    Concept Type: characteristic
    Note: 'Actionable' means that a person who knows about the directive
    could observe a relevant situation (including his or her own behavior)
    and decide directly whether or not the business was complying with the
    directive. Dictionary Basis: subject to or affording ground for an
    action or suit at law [MWUD 'actionable'] Dictionary Basis: a thing done
    : DEED [MWUD (5a) 'action']
    Note: The sense intended is: "It's actually something you can put to use
    or apply."

    ====================================================

    As you can see, SBVR effectively treats "rule" as a synonym of
    "criterion". I fear that this is fundamentally incorrect. The ODE says
    that a criterion is: "A principle or standard by which something may be
    judged or decided." The ODE does not equate "criterion" with "rule", as
    the SBVR definition implies.

    For example, a bank may decide that one criterion for determining that a
    customer should be treated as a Gold Customer is the length of time they
    have held an account. Another criterion might be balance held in the
    account, averaged over some period. The bank might then define a "Gold
    Customer" rule that uses these (and probably other) criteria. In simple
    cases, a rule may boil down to not much more than a single criterion,
    but that does not change the fact that "rule" and "criterion" are
    different concepts, and are clearly identified as such in the ODE. It's
    hard to see what SBVR gains by attempting to muddle the two together.
    Why not let "rule" simply mean "rule"?

    A second problem is the use of "actionable" in the SBVR definitions. The
    intent of SBVR was to provide business level descriptions, not
    prescriptions for processing. It may well be that a rule necessitates
    some actions at a machine level, but that should be outside the SBVR
    scope. It's hard to see how alethic constraints fit with the SBVR idea
    of "actionable". For example, how does one "action" something like "a
    person is born in exactly one country"? A strict interpretation of the
    current SBVR definitions would appear to disallow alethic constraints of
    this kind.

    The dictionary justification quoted for "actionable" (and, by
    inheritance, "rule" too) is also rather weird – I doubt that many
    business rules are framed with legal action in mind.

    A further problem is the demotion of a rule to just being a piece of
    advice or information, rather than defining what must or must not be the
    case. A rule may advise or inform, but that's not necessarily its
    primary purpose, as claimed in the SBVR definitions.

    In summary, the SBVR definition of "rule" could be paraphrased as "an
    advisory criterion used to invoke a deed for which one could be sued",
    which is very different from the ODE definition (and the common English
    usage) of "rule". This SBVR meaning is NOT the meaning intended in the
    formal logic section. Simply replacing "logic rule" by "rule" without
    changing the SBVR definition of "rule" would therefore change the
    meaning of the formal logic section.

    A common-sense solution would be to change the term in SBVR from "rule"
    to something like "SBVR rule", so that the term "rule" could be used
    where necessary in its normal English language sense. In this case,
    "logic rule" in the formal logic section could revert to just being
    "rule" and no definition would be necessary since we would be using it
    in its everyday sense. Where we can use ordinary English words in their
    ordinary English sense it's hard to think of any reason why we should
    not do so.

  • Reported: SBVR 1.0b1 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The current notion of "actionable" falls short in several regards

  • Key: SBVR-46
  • Legacy Issue Number: 9477
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The current notion of "actionable" falls short in several regards:

    • It does not take into account structural (definitional) rules.
    • Its wording is based on "complying", which is only appropriate for operative (behavioral) rules.
    • It fails to address the issue of lexical indexicals – conversational references to person, place and time.

    The attached document (SBVR-Actionable-pp138+178.doc) reflects the detail of
    the proposed revision.

  • Reported: SBVR 1.0b1 — Mon, 27 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interchange issue

  • Key: SBVR-45
  • Legacy Issue Number: 9476
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The Interchange discussion in chapters 13 and Annexes K and L appear to discuss exchange of meaning between tools. But what about representations and expressions? Presumably users would want to preserve their forms of expression when moving rules between tools. Is that a goal of the Interchange design? If the answer is yes, then tool implementors will need more detail about how to accomplish that.

    Consider the first example in chapter 9, "A rental must have at most three additional drivers". I can think of several ways to associate the expression with the semantic formulation described in this chapter.

    1. Use the fact type "statement is formalized by closed logical formulation" to associate the complete rule statement with the top-level semantic formulation.
    2. Use the fact types "representation has expression", "representation represents meaning" and "closed semantic formulation formulates meaning" to associate the complete rule statement (as an expression) to a representation that then gets associated to a meaning that then gets associated with the semantic formulation. This seems like one too many levels of indirection: why isn't a semantic formulation a type of meaning?
    3 . Decompose the statement into sub-statements such as "rental has at most three additional drivers" and "rental has additional drivers" and associate these individually with the corresponsing logical formulations that compose the complete formulation. That is, exchange the expression corresponding to each logical formulation.

    Absent further guidance, tool vendors will choose different answers to such questions. That will defeat the goal of interoperability between tools and repositories.

  • Reported: SBVR 1.0b1 — Mon, 27 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution to Issue 9950.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing definitions

  • Key: SBVR-44
  • Legacy Issue Number: 9475
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2.

    Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation).

    Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant.

    Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned.

    Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1.

    Section 10.1.2 defines prohibition but not impossibility.

    Suggestions:

    1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 – but that seems undesirable since the unrestricted forms do appear in the real world.
    2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality.
    3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications.
    4. Adopt a consistent approach to the negative forms (prohibition, impossibility):
    a) Adopt one designation for nonpermission/forbidden/prohibition.
    b) Define impossibility in section 10.1.2.
    c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities.

  • Reported: SBVR 1.0b1 — Mon, 27 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR vocabularies

  • Key: SBVR-43
  • Legacy Issue Number: 9474
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR vocabularies are represented (e.g. in SBVR.xsd) as "Instantiation" types, when sections 13.1.1 and 13.3.3 say they should be mapped to packages

  • Reported: SBVR 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    A metamodel generated from each SBVR vocabulary (e.g. The Meaning and Representation Vocabulary described in Clause 8) is created based on the mapping rules in clause 13, and that metamodel is, in UML terms, a package. A designation for such a vocabulary (e.g. 'Meaning and Representation Vocabulary' defined in Clause 7) is mapped, liked every other designation for a noun concept, to a subclass of the Instantiation Class. This double appearance of "Meaning and Representation Vocabulary" results because SBVR is in terms of itself and is not a problem. Add a note into clause 13 to clarify how a vocabulary namespace might appear to be mapped more than once.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI has some internal inconsistencies

  • Key: SBVR-42
  • Legacy Issue Number: 9473
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The XMI has some internal inconsistencies. For example, it references type "proposition" but does not define that type.

  • Reported: SBVR 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    The documents referenced in this Issue were removed from the SBVR Specification by the resolution of Issue 9930. The much smaller number of supporting documents for the new version of SBVR Use of MOF are being supplied. There are no known inconsistencies in the new documents.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI in bei/05-08-02 and representing many vocabulary and rules aspects

  • Key: SBVR-41
  • Legacy Issue Number: 9472
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The XMI in bei/05-08-02 provides no means of representing many vocabulary and rules aspects shown in the specification and the EU-Rent example:

    • Concept Type, Guidance Type
    • Synonym, Synonymous Form
    • Note, Example
    • Necessity, Possibility
  • Reported: SBVR 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution to Issue 9930.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

supporting documents

  • Key: SBVR-40
  • Legacy Issue Number: 9471
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Chapter 15 promises various supporting documents. The latest I can find (in bei/05-08-02) are out-of-date with respect to the current draft. Others don't exist at all.

  • Reported: SBVR 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    The documents called for in this Issue were removed from the SBVR Specification by the resolution of Issue 9930. The much smaller number of supporting documents for the new version of SBVR Use of MOF are being supplied.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

specification does not address the mapping of rules to MOF and XMI

  • Key: SBVR-39
  • Legacy Issue Number: 9470
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The specification does not address the mapping of rules to MOF and XMI. The following sections address in detail the mapping of vocabulary to MOF and XMI. It seems to me that – absent equivalent detail about mapping of rules – the goal of effectively interchanging rules may not be achieved.

    • Section 13.3, "Vocabulary-to-MOF/XMI Mapping Rule Set" gives rules for mapping vocabulary to MOF and XMI, but ignores the question of mapping rules to MOF and XML.
    • Annex K, "Design Rationale Details for the Use of MOF and XMI", contains lots of discussion about the representation of vocabularies in MOF and XMI but mentions rules only in passing.
    • Annex L, "Examples of SBVR's Use of MOF" shows how a subset of the EU-Rent vocabulary should be represented in MOF and XMI but again overlooks rules.
  • Reported: SBVR 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Resolved by the resolution to Issue 9930.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Schema and Namespace URIs

  • Key: SBVR-38
  • Legacy Issue Number: 9468
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    SBVR uses URIs in a reference scheme for namespaces. The URIs are particularly important for standardized namespaces so that standard designations can be identified. But SBVR does not give the namespace URIs needed for its own vocabularies or for source vocabularies. These URIs are needed in order to facilitate interchange.

    Also, XMI documents based on an SBVR vocabulary need to identify an xmlns URI for the particular metamodel being used and for Essential SBVR. Xmlns URIs are needed for each of these:

    · Essential SBVR

    · SBVR

    · Meaning and Representation

    · Logical Formulation of Semantics

    · Vocabulary for Describing Business Vocabularies

    · Vocabulary for Describing Business Rules

    · Vocabulary-to-MOF/XMI Vocabulary

    I have seen examples of such xmlns URIs for OMG specifications, but the pattern is not completely consistent.

    · http://schema.omg.org/spec/XMI/2.1

    · http://schema.omg.org/spec/MOF/2.0/cmof.xml

    · http://org.omg//UML/2.0/UML2L1.xml

    We need to determine a pattern to use for SBVR. Then for each corresponding vocabulary namespace, either use the same URI or some variation. Here is one possible set of xmlns URIs.

    · http://schema.omg.org/spec/SBVR/1.0/SBVR

    · http://schema.omg.org/spec/SBVR/1.0/Meaning-and-Representation

    · http://schema.omg.org/spec/SBVR/1.0/Logical-Formulation-of-Semantics

    · http://schema.omg.org/spec/SBVR/1.0/Vocabulary-for-Describing-Business-Vocabularies

    · http://schema.omg.org/spec/SBVR/1.0/Vocabulary-for-Descibing-Business-Rules

    · http://schema.omg.org/spec/SBVR/1.0/Vocabulary-to-MOF/XMI-Vocabulary

    · http://schema.omg.org/spec/SBVR/1.0/Essential-SBVR

    One possible variation for the namespace URIs would be to replace “schema” with “namespace”. E.g. http://namespace.omg.org/spec/SBVR/1.0/Meaning-and-Representation

    This needs to be coordinated with OMG so that it fits a planned general structure.

    Recommendation:

    Note that this recommendation is incomplete. It needs an agreement in the FTF and with OMG on the OMG-based URIs to be assigned.

    7.1.1 and 7.1.2 (pg. 11-12), add a “Namespace URI:” line under the “General Concept:” line or “Definition:” line of each entry in the sections. Give the appropriate URI.

    7.1.3 (pg. 12), add a “Namespace URI:” line under the “Definition:” line of each name.

    C.3 (pg. 201), add ‘Namespace URI:” to the end of the list of captions under “<primary representation>”.

    Add “C.3.16 Namespace URI” at the end of section C.3 (pg. 208) as follows:

    C.3.16 Namespace URI

    If the primary entry is for a namespace, the ‘Namespace URI” caption is used to indicate a URI of the namespace. If the primary entry is for a vocabulary, the ‘Namespace URI” caption is used to indicate a URI of a vocabulary namespace for the vocabulary. Here is an example:

    Meaning and Representation Vocabulary

    General Concept: vocabulary

    Namespace URI: <INSERT OFFICIAL URI HERE – same as what is used in 7.1.1>

    In section 15, (starting on pg. 169), give the xmlns URIs for the XML schema documents.

  • Reported: SBVR 1.0b1 — Wed, 22 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Add a new captioned paragraph style, "Namespace URI" to the SBVR Structured English, and then use it to give URIs to the various vocabulary namespaces.
    Assign URIs following OMG's pattern, which identifies SBVR and its version:
    http://schema.omg.org/specs/SBVR/1.0/<specific-name>
    Also, add SBVR Vocabulary as a combination of Meaning and Representation Vocabulary, Logical Formulation of Semantics Vocabulary, Vocabulary for Describing Business Vocabularies and Vocabulary for Describing Business Rules so that a namespace URI can be conveniently used in XML documents that convey combinations of vocabulary, rules and semantic formulations.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implicit Passive Forms

  • Key: SBVR-37
  • Legacy Issue Number: 9467
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    It is a matter of grammar that verbs have passive forms. The standard passive formation uses the past participle of a verb preceded by “is” and followed by “by”. For example, I can say a cat eats a mouse or I can say a mouse is eaten by a cat. The vocabularies defined in SBVR explicitly include passive forms. But this is not necessary any more than it is necessary to include infinitive, subjunctive and plural forms. The forms are produced by rules of grammar. Synynomous forms should be given where a different verb is being used, but not for simply showing the same verb in different grammatical configurations.

    In general, passive forms have been left out of diagrams. But they are explicitly listed in the vocabulary entries. It would be benefitial to simply explain in the appendix on SBVR Structured English that passive forms are implicitly usable and then omit passive forms from the vocabulary entries. This simplifies and shortens the specification without losing any meaning and without changing the meaning of any definition or statement. It makes the SBVR MOF metamodels and XMI schemas smaller without losing any semantic content. It also sets a better example for future users of SBVR.

  • Reported: SBVR 1.0b1 — Wed, 22 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use Plural Rather than “Set of Each”

  • Key: SBVR-36
  • Legacy Issue Number: 9462
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    When a reference scheme extensionally uses a role of a fact type, the SBVR Structure English takes the form “the set of each <singular noun> that <singular verb> …”. This is a very awkward wording. Plurals should be used: “the set of <plural noun> that <plural verb> …”. Examples of how this improves understandability are readily seen in the recommended changes below.

    Recommendation:

    Make the following changes, in each case removing the word “each” and pluralizing the noun, and verb if given. Keep the fonts as they are.

    Pg. 25, “the set of each placeholder” becomes “the set of placeholders”.

    Pg. 29, “the set of each role that is” becomes “the set of roles that are”, twice.

    Pg. 43, “the set of each concept that is” becomes “the set of concepts that are”, twice.

    Pg. 45, “the set of each role binding” becomes “the set of role bindings”.

    Pg. 57, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”.

    Pg. 58, “the set of each logical formulation that is” becomes “the set of logical formulations that are”, thrice.

    Pg. 58, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”, thrice.

    Pg. 59, “the set of each logical formulation that is” becomes “the set of logical formulations that are”, thrice.

    Pg. 59, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”, thrice.

    Pg. 60, “the set of each logical formulation that is” becomes “the set of logical formulations that are”.

    Pg. 60, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”.

    Pg. 68, “the set of each variable that is” becomes “the set of variables that are”.

    Pg. 68, “the set of each logical formulation that constrains” becomes “the set of logical formulations that constrain”.

    Pg. 129, “the set of each symbol context that qualifies” becomes “the set of symbol contexts that qualify”.

    Pg. 206, “the set of each role that is” becomes “the set of roles that are”, twice.

    Pg. 206, in the second paragraph of C.3.9, change “the set of each” to “the set of”.

  • Reported: SBVR 1.0b1 — Fri, 17 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Change uses of "the set of each" to "the set of" and uses plurals accordingly.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Synonymous Statement

  • Key: SBVR-35
  • Legacy Issue Number: 9459
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The caption “Synonymous Form” should not be used for synonymous statements in the SBVR Structured English because the term has a different meaning which is related to forms of expression. See C.5.6 (pg. 210).

    Recommendation:

    Change the caption “Synonymous Form” to “Synonymous Statement” in the following places:

    C.5 (pg. 209) in the list under <Rules Statement or Clarification Statement>.

    C.5.6 (pg. 210) in the section heading and in the paragraph.

    E.2.2.2.4 (pg. 278 near top).

    E.2.2.2.5 (pg. 280 near bottom).

    E.2.2.2.7 (pg. 282 top of section).

    E.2.2.2.9 (pg. 284 near top).

    F.3.3 (pg. 303 above middle).

    F.3.8 (pg. 307 near middle).

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bad Example of Extensional Definition

  • Key: SBVR-34
  • Legacy Issue Number: 9458
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The following example given in C.3.2.1 (pg. 202) is no longer correct.

    semantic formulation

    Definition: logical formulation or projection

    Recommendation:

    Replace that example with ‘bindable target’ as follows:

    bindable target

    Definition: variable or text

    Replace the sentence above the example that says “For example, a semantic formulation is anything that is a logical formulation or a projection” with this: “For example, a bindable target is anything that is a variable or a text”.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Replace the example with 'bindable target'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI Names for ESBVR

  • Key: SBVR-33
  • Legacy Issue Number: 9457
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The following “Necessity” statements in 13.2 (pages 153-154) are not needed and should be removed.

    ‘fact’ is the XMI name of the Fact Class.

    ‘instantiation’ is the XMI name of the Instantiation Class.

    ‘integer’ is the XMI name of the Integer Class.

    ‘text’ is the XMI name of the Text Class.

    ‘extension’ is the XMI name of the Extension Class.

    Recommendation:

    Remove the lines containing the statements listed above from the specification.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove the unnecessary statements

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Symbolization Diagram Error

  • Key: SBVR-32
  • Legacy Issue Number: 9456
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Figure 11.6 on page 126 has the following errors:

    “signifier” within the rectangle should be “expression”.

    “is sensory manifestation of” should be “[signifier] is sensory manifestation of”

    “regulates its usage of” should be “regulates its usage of [signifier]

    Recommendation:

    Fix the diagram as noted.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fact Type Templating Diagram Error

  • Key: SBVR-31
  • Legacy Issue Number: 9455
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Figure 11.5 on page 123 shows associations for two fact types that do not exist. If they did exist, an ambiguity would be created. The associations are for:

    categorization fact type has more general concept

    categorization fact type has category

    Recommendation:

    Remove the two associations from Figure 11.5.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tie Category and More General Concept to a Fact Type

  • Key: SBVR-30
  • Legacy Issue Number: 9454
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The fact type that connects “category” and “more general concept” is shown in Figure 11.2, but is missing from section 11.1.2. That fact type is defined in the Meaning and Representation Vocabulary, but the role designations “category” and “more general concept” are introduced in 11.1.2.3. The forms of expressions that use these designations are missing. The form of expression “concept has category” must be put in the vocabulary in order to make the 50 or so uses of the phrase “category of …” formally understandable.

    Recommendation:

    11.1.2.3 (pg. 116)

    Add the following after the entry for “more general concept”. The numerals are all in the subscript style. The words “has” and “specializes” are in the verb style. The other words are in the term style.

    concept1 has more general concept2

    see: concept1 specializes concept2

    synonymous form: concept2 has category1

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary Grammatical Structure

  • Key: SBVR-29
  • Legacy Issue Number: 9453
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The specializations of ‘noun form’, namely ‘nominal restrictive form’, ‘mathematical form’ and ‘gerund form’, delve into grammatical structure, which SBVR generally avoids. It is sufficient to distinguish forms of expression into being propositional versus being nounish. The examples given for the different kinds of noun forms are helpful, but they can be given without introducing the added grammatical complexity into the formal metamodel. Also, these specializations are not complete with respect to noun forms and it is beyond the scope of SBVR to make the specializations complete.

    Recommendation:

    The following edits preserve and combine explanatory material and examples from the unwanted specializations and then delete the specializations. Brackets are used to show words that should be underlined (not the term style). The numerals attached to “number” should all be subscripts.

    8.3.4 (pg. 25-26)

    Add the following note to the entry for ‘noun form’ just below its definition.

    Note: A noun form can have a placeholder for each role of a fact type, in which case the noun form result comes from the of role the first placeholder is for. A noun form can also have one less placeholder than there are roles, in which case the noun form result comes from the role that no placeholder is for.

    Replace the examples in the entry for ‘noun form’ with these:

    Example: ‘[transferred car] of [car transfer]’ for the fact type ‘[car transfer] has transferred car]’. This form yields a transferred car.

    Example: ‘| [number] |’ for the fact type ‘[number] has [absolute value]’. The form yields the absolute value of the number.

    Example: ‘[number1] + [number2]’ for the fact type ‘[number1] + [number2] = [number3]’. This form yields the third number – the sum of adding the first two numbers.

    Example: ‘transferring [rental car]’ for the fact type ‘[car transfer] has [transferred car]’. This form yields the car transfer, which is an action. Gerunds are used in noun forms like this for actions, events and states. They are used in sentences like this: “A rental car must be cleaned before transferring the rental car.”

    Remove the entire entries for ‘mathematical form’, ‘nominal restrictive form’ and ‘gerund form’.

    I can provide an updated Figure 8.4 on page 24.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reference Scheme’s Reference Scheme is Incomplete

  • Key: SBVR-28
  • Legacy Issue Number: 9452
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    The reference scheme for ‘reference scheme’ needs to consider characteristics used by the reference scheme, but it does not. This is necessary because a reference scheme that considers a characteristic is always different from one that does not.

    Recommendation:

    8.4 (pg. 29, bottom)

    Add the following to the end of the “Reference Scheme:” paragraph for the ‘reference scheme’ entry:

    and the set of each characteristic that is used by the reference scheme

    The term style should be used for “characteristic” and “reference scheme”, the verb style for “is used by” and the keyword style for the rest.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Individual Concept Not Necessarily a Noun Concept

  • Key: SBVR-27
  • Legacy Issue Number: 9451
  • Status: closed  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Based on ISO’s ‘individual concept’ a fact type could be an individual concept. But the specification gives ‘noun concept’ as the more general concept of ‘individual concept’. Also, as it stands, ‘individual concept’ is inconsistent with ‘general concept’.

    Recommendation:

    8.1.1 (pg. 17)

    Remove line in the entry for “individual concept” that says, “General Concept: noun concept”.

    I can provide an updated Figure 8.1 on page 15.

  • Reported: SBVR 1.0b1 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Remove from the specification that 'individual concept' specializes 'noun concept'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

10 Examples - applying a standard pattern in the "10 Examples"

  • Key: SBVR-26
  • Legacy Issue Number: 9450
  • Status: closed  
  • Source: ( Keri Healy)
  • Summary:

    Description:
    The "10 Example Rules" material makes use of some 'convenience concepts'**
    in several of the rules. A consistent approach needs to be applied for
    making vocabulary entries for these in SBVR-SE, and a discussion of that
    pattern should be added to Annex D.

    Actions needed:

    1) Using the "10 Examples" material, change as needed to apply a consistent
    approach to specifying this kind of vocabulary entry(s), which appear as
    cited vocabulary entries in the 'Supporting fact types' material of the "10
    Examples" (and from there into the EU-Rent Vocabulary (Annex E)).

    2) Add a section to the "Patterns" annex, describing this.

    3) Decide if an SBVR term is needed for what this issue terms a 'convenience
    concept'. If yes, agree to the term. If no, agree to a consistent, short
    characterization.

    **'convenience concept' is an interim term, selected to avoid
    conflict/confusion with overloaded terms in other discussions. Such a
    concept/term establishes an equivalency to other defined concepts to allow
    rules (and definitions) to be expressed in a less verbose manner. From the
    "10 Examples" this includes: business currency, drop-off branch, pick-up
    branch, rented car, requested car group, return branch, and some concepts
    from the EU-Rent common vocabulary for time periods and durations (e.g.,
    actual pick-up date-time).

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    1) Using the "10 Examples" material, change as needed to apply a consistent approach to specifying this kind of vocabulary entry(s), which appear as cited vocabulary entries in the 'Supporting fact types' material of the "10 Examples" (and from there into the EU-Rent Vocabulary (Annex E)).
    2) Add a section to the "Patterns" annex, describing this.
    Note: At the June 2006 meeting it was decided that the new material would appear in a new (D.3) section of Annex D entitled "Defining a Fact Type for Convenience".
    3) Decide if an SBVR term is needed for what this issue terms a 'convenience concept'. If yes, agree to the term. If no, agree to a consistent, short characterization.
    **Note: This Issue originally used the interim term 'convenience concepts'; at the June 2006 meeting it was decided that the term 'short form expression' would be used in place of that initial terminology.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SBVR-FTF Issue: 10 Example Rules material

  • Key: SBVR-25
  • Legacy Issue Number: 9449
  • Status: closed  
  • Source: ( Keri Healy)
  • Summary:

    The "10 Example Rules" material is a useful reference in training and other
    explanatory applications. However, its current presentation makes that
    difficult – it is: redundantly presented (leading to some inconsistencies,
    and extra work as updates are made), is incomplete (does not reflect the ORM
    expression style), and needs other minor updates.

    Actions needed:

    1) Move and consolidate the presentation of the "10 Example Rules" from
    Annexes E and F into a new Annex.

    2) Correct inconsistencies, as needed.

    3) Add the expression of each of the 10 rules in ORM notation.

    4) Correct the supporting (based on) fact types to match the entries in the
    EU-Rent vocabulary (Annex E).

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    1) It was decided that, rather than consolidate into a single Annex, the material would be kept in individual Annexes (the current EU-Rent Annex E and the RuleSpeak Annex F) and that the 10 Examples in ORM would be added into Annex I.
    2) Corrections to the 10 Examples are given below.
    3) The ORM version of the 10 Examples replaces the current section "I.3 Some EU-Rent Rule Examples", as provided below.
    4) Corrections to the EU-Rent vocabulary for the 'supporting fact types' and 'related facts' used in the 10 Examples are given below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add (and explain) styling for 90 days where it appears in formal statement

  • Key: SBVR-24
  • Legacy Issue Number: 9448
  • Status: closed  
  • Source: ( Keri Healy)
  • Summary:

    Add (and explain) styling for "90 days" where it appears in a formal
    statement

    In the 10 Example Rules (several places throughout the Annexes), "90 days"
    appears unstyled in a rule statement.

    Actions needed:

    1) Add styling to "90 days" [pages: 223, 282, 293 (2 places), 306 (2
    places)] where it appears in a formally-styled rule statement (i..e., this
    does not apply to its use in Notes, etc.)

    2) Add an explanatory section to Annex C, using this as an example,
    describing in general how an individual that involves the representation of
    some 'quantity' is represented in a formal (fully-styled) SBVR expression.
    Make reference to other standards/words, as appropriate.
    [ref. earlier discussion thread on SBVR-FTF]

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    1. Correct rule statement Example 2 to read "... is at most 90 rental days." – i.e., to use the name 'rental days' which is defined in the EU-Rent vocabulary as one of the valid instances of RTU. Style "90 rental days" to apply Name style.
    2. Correct this Example's Supporting fact type to cite "rental has rental duration".
    3. Add "Supporting fact types" as a way of explanation. Note: There is no generalized treatment for quantities and measurement that has been agreed. There are no changes needed in the Annex for SBVR Structured English, which does not try to address the grammatical patterns used for quantities and measurement.
    4. Add a Note to the entry for the rule in the EU-Rent ruleset, explaining that this illustrates one possible way to do this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept

  • Key: SBVR-23
  • Legacy Issue Number: 9447
  • Status: closed  
  • Source: ( Keri Healy)
  • Summary:

    Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept

    p. 32, entry for 'conceptual model':
    add caption: Synonym: fact model ==>[with 'fact model' styled term]

    p. 32, add entry for 'fact model':
    fact model ==> [styled as appropriate for an entry]
    See: conceptual model ==>[styled appropriately]

    p. 72, final paragraph: after "is a fact model, not a process model." to
    read:
    "is a fact model (in SBVR, termed 'conceptual model'), not a process model."

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add 'Synonym: aspect' caption

  • Key: SBVR-22
  • Legacy Issue Number: 9446
  • Status: closed  
  • Source: ( Keri Healy)
  • Summary:

    Add 'Synonym: aspect' caption that is currently missing under the entry for
    'facet'

    There is an entry for 'aspect', which is a secondary term for the concept
    termed 'facet'. However, the entry for 'facet' is missing the corresponding
    'Synonym:' caption referring to 'aspect'.

    Action: Add the following caption under the entry for 'facet':
    Synonym: aspect
    (using the paragraph style for 'synonym' with 'term' character styling
    applied to the word 'aspect').

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Correct the inconsistency.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 12 page 139: Add Synonyms

  • Key: SBVR-21
  • Legacy Issue Number: 9444
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Add Synonyms for the following 3 entries:

    CURRENT ENTRY SYNONYM (to be added)
    ============== ================
    structural rule definitional rule
    structural business rule definitional business rule
    operative business rule behavioral business rule

  • Reported: SBVR 1.0b1 — Wed, 15 Mar 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Improve linkage to Rule/Business Rule in 10.1.1 Narrative

  • Key: SBVR-20
  • Legacy Issue Number: 9368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Problem Description:

    The narrative in 10.1.1 created artificial terminology ('logical rule',
    'logic rule') as an interim step, but this left the material unconnected
    with the SBVR senses of 'rule'. The connection between the sense of 'rule'
    – as used in 10.1.1 and in the normative vocabularies of SBVR – needs to
    be made.

    • Proposed solution:

    Mark-up provided that:

    (1) cites the SBVR definitions of the terms 'rule' and 'business rule'

    (2) removes the interim language of 'logical rule' and 'logic rule',
    replacing these terms with 'rule' or 'business rule' (incl. 'statements of
    ...'), as appropriate.

  • Reported: SBVR 1.0b1 — Wed, 22 Feb 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of the type theory of SBVR needs to be included in 10.1.1

  • Key: SBVR-19
  • Legacy Issue Number: 9366
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    This sentence appears near the end of 10.1.1: "We do not adopt a type theory such as Russell’s type theory, where each set may belong only to a set of a higher type." This is about all that is said in section 10 about the theory of types in SBVR. When I asked about the failure to include a description of SBVR's type theory, Tony said that the reason there was no description of SBVR's type theory was that there is no type theory in SBVR, or something to that effect. While it may be true that SBVR does not allow a hierarchy of degrees of types like that of Russel, and does not admit statements about whether or not sets can be members of themselves, it is not true that SBVR has no theory of concepts, which correspond to types. SBVR contains several asserted or implied general conditions on relationships among concepts. Should these be pointed out and tied to formal logic in section 10? The interpretation of a conceptual model that is described in terms of SBVR's vocabularies is crucially dependent on how SBVR formally regards the notions of consistency and unification of the concepts in the conceptual model, as a set of types.

    Here are some questions that such a logical grounding of SBVR concepts might be expected to answer: How is the logical consistency of concepts to be determined? What is the most general concept? Under what conditions can new concepts be admitted into a conceptual schema or into a possible world? How are these rules affected by open/closed world assumptions? How is it determined if a set of concepts is well formed?

    Some entries whose definitions, notes, and necessities bear on these questions are 'thing', 'concept', 'concept type', 'concept generalizes concept', 'intensional definition', 'delimiting characteristic', 'concept is closed in conceptual schema', 'fact type is internally closed in conceptual schema', and others.

  • Reported: SBVR 1.0b1 — Thu, 16 Feb 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

define 'is less than' on 'quantity'

  • Key: SBVR-18
  • Legacy Issue Number: 9344
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Problem Description:

    Clause 8.7 defines 'integer' as "a number with no fractional part". But the concept 'number' to which this definition appeals is not defined, and the entry does not cite a source for the definition. 'number' should be defined as well.

    SBVR clause 8.7 defines the fact-type 'integer is-less-than integer'.
    This is a narrow definition of the 'less-than' concept, which applies, with the same semantics, to 'numbers' and to arbitrary quantities. 'Quantity' is the general concept on which comparison for less and greater is defined for business purposes. It is the concept for which is-less-than should be defined in 8.7.

    In Annex D, 'is less than' is used as a fact-type for prices and durations in several places, but it is never defined. This usage requires a wider definition of the is-less-than fact-type that is defined in 8.7, namely a definition on 'quantity'. D.2.3.3 defines 'duration' as "a quantity of time", but the term 'quantity' is not a vocabulary entry in either 8.7 or Annex D. And D.2.3.3 defines the fact-type 'duration is-at-most duration', but it has the same semantics as quantity is-less-than (or equal to) quantity. It is clear that this example is a model for the definition of "measurement" vocabularies, and 8.7 should provide the base term 'quantity' to support that.

    • Proposed solution:

    (1) define the term 'quantity' in SBVR, e.g.,
    Definition: a determinate or estimated amount [of a thing]
    Definition: the aspect in which a thing is measurable in terms of greater, less or equal
    Source: MW
    Note: The concept quantity can be elaborated into mathematical systems, such as integer and real numbers, and into systems of measures. This specification elaborates only the concepts for integer, because they are commonly used in structural rules (See x.x). For measurement systems and units of measure there are accepted vocabularies and perhaps standard ontologies, but the specification of such a vocabulary is beyond the scope of this specification.

    (2) replace the the fact-type 'integer is-less-than integer' with the fact-type 'quantity is-less-than quantity'.

    (3) add the concept 'number'
    Definition: a [quantity] belonging to an abstract mathematical system and subject to laws of succession, addition and multiplication
    Source: MW

    (4) make integer a subtype of number, and number a subtype of quantity.

    (5) correct the "term" style for 'number' in the definition of integer in 8.7, and for 'quantity' in the definition of duration in D.2.3.3.

    (6) In D.2.3.3, add to the definition of duration is at most duration:
    Synonymous form: duration is less than or equal to duration

  • Reported: SBVR 1.0b1 — Tue, 31 Jan 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Logical formulations are fact-types

  • Key: SBVR-17
  • Legacy Issue Number: 9258
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In SBVR clause 9.1.1.6 (or 9.2.6 in later editions?), a "logical operator" is defined to be a (subtype of) logical formulation. The definition of logical-formulation says it is the interpretation of a logical formula. So logical formulation has to assign a semantic fact-type to a formula. But what is modeled in 9.2.6 is the logical formula, not the interpretation. What is modeled is "operator has operands", which is a grammatical notion, or perhaps a computational notion (Boolean expression). But the logical formulation is the interpretation of the operator and its operands as a fact-type.

    Example 1: The logical formulation that underlies the terms "equivalence", "condition_1" and "condition_2", which appear in 9.1.1.5, and the formula fact-types "equivalence has condition_1" and "equivalence has condition_2", which appear in 9.1.1.6, is the fact-type
    "logical-formulation is-equivalent-to logical-formulation"
    This fact-type expresses the interpretation of a formula involving an equivalence operation and two 'condition' operands. The corresponding fact-type template might be
    "condition_1 is-equivalent-to condition_2",
    where condition_1 and _2 are roles fulfilled by logical formulations.

    Example 2: The logical formulation that underlies the terms "conjunction", conjunct_1 and conjunct_2, and the formula fact-types "conjunction has conjunct_1" and "conjunction has conjunct_2" is the fact-type
    "Both logical-formulation (#1) and logical-formulation (#2) hold."
    This fact-type expresses the interpretation of the formula involving a conjunction symbol and two 'conjunct' operands (conjugends). The term "conjunction" is a 'name' for this fact-type.

    The failure to define the logical formulations properly in 9.1.1.6 causes the roles in those fact-types to become 'terms with subscripts' in clause 9.1.1.5 (or 9.2.5 in later editions?). As indicated in the 'Fact types and templates' issue, the SBVR notation for a fact-type role is a 'local name' for a parameter to the fact-type template. In clause 9.1.1.5, this notational convention has been elevated to a concept term! In most (but not all) cases, this error is recognizable by the fact that the "concept term" is subscripted. In what speech community would 'condition_1' be a term?

    Roles, in this sense, are only meaningful with respect to a given fact-type – they are NOT self-standing terms that go in the glossary. Every logical operand "term" in clause 9.1.1.5 is just a role in a logical fact type that should be, but isn't, actually defined as a fact-type in 9.1.1.6.

    If the logical operators are recast as fact-types, condition#1 would be the name of a template parameter, and the definitions would resemble those in Clause 8. The only difference between the logical formulations in Clause 9 and the fact-types in clause 8 is that, in clause 9, the roles are named something different from the participating concept (term).

    Note, however, that some of these "role names" really are terms in mathematical logic. In particular, the roles "antecedent" and "consequent" are important to the discussion of "implication", because the roles are importantly different. These terms should be introduced as 'glossary terms'.

    Conversely, the 'conjunct' roles in a conjunction and the 'condition' roles in an equivalence are not actually distinct – all conjugends have the same behavior in a conjunction. And this is true of all subscripted role names in 9.1.1.5. These terms convey nothing more interesting than 'operand', but they can be defined, if desired, as 'terms' in 9.1.1.5. If they are defined, they should be defined without the subscripts, because the subscripts are nothing more than elements of the templates – they don't distinguish behavior.

    • Proposed solution:

    9.1.1.6 needs to be restructured as logical fact types, and ALL the roles in 9.1.1.5 should be defined in those fact-type definitions. In most cases, the logical operator can become the 'Name:' of the fact-type. The relationship between these fact-types and their template definitions is the subject of another Issue.

    Some or all of the role names with distinct behaviors (no subscripts) that are currently in 9.1.1.5 should be defined as 'terms' in 9.1.1.6. It does not seem appropriate to move them to a different section from the one that defines their semantics as roles in the logical formulations of the operations.

  • Reported: SBVR 1.0b1 — Mon, 23 Jan 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fact-types and templates (and subscripts)

  • Key: SBVR-16
  • Legacy Issue Number: 9257
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In SBVR clause 8, subscripts occur in fact-type term entries. In clause 14, those subscripts are omitted from the fact-type term entries. This is inconsistent, apparently because the entries in clause 8 are doing double duty: as fact-type definitions and as SBVR Structured English templates.

    Subscripts occurring in fact-type definitions (Glossary Fact Type entries) are not part of the entry for the fact-type. They are an accidental part of definition of the template for the corresponding form-of-expression.
    A fact type is an abstract concept, and the glossary item apparently defines both the fact-type and a form-of-expression for the fact-type. That form of expression belongs to "SBVR Structured English", and there may well be other forms of expression for the selfsame fact-type in other languages. So the specification has to make this distinction very clear.
    But the subscripts are not in fact a part of that form of expression, either. They are not keywords in the template itself. They are rather a lexical mechanism used to distinguish two roles in the template (and in the fact type) that happen to require the same underlying concept type. That is, in "concept#1 specializes concept#2"
    SBVR defines the fact-type
    "concept specializes concept",
    and at the same time, defines the fact-type template:
    "concept#1 specializes concept#2"
    where "concept#1" designates a "concept" and "concept#2" designates a "concept". That is, "concept#1" is just a template parameter that lexically represents one role in the fact-type "concept specializes concept". For the template, "concept#1" could just as well have been called "parameter#1" or "x". "concept#1" is neither a "term" nor a "keyword"; it is a template parameter – a lexical stand-in that is to be uniformly replaced by one actual "term" or "name" in all uses of the template and in all occurrences in the corresponding definition. The current notation makes this confusing.
    Note that this situation is not really different from "concept incorporates characteristic". The fact-type is "concept incorporates characteristic" and the template is "concept#1 incorporates characteristic#2", but we didn't happen to need the parameter-subscripts to distinguish the roles in this case, only because the concepts playing the roles are distinct.
    Given the role of this standard, this notation is confusing, and marking the subscripts as keywords is technically wrong. SBVR can continue to use this notation only if it is very clear about the distinction between the fact-type
    "concept specializes concept"
    and the template
    parameter#1 (concept) specializes (concept) parameter#2

    • Proposed solution:

    Clarification is needed. How to do it is not clear.

  • Reported: SBVR 1.0b1 — Mon, 23 Jan 2006 05:00 GMT
  • Disposition: Resolved — SBVR 1.0b2
  • Disposition Summary:

    Clarify the meaning of subscripts used with placeholders. Expand the reference scheme for placeholders to support textual placeholders whose expressions use delimiting characters, subscripts and/or other marks. Make the use of a designation by a placeholder optional.
    Clarify how fact type forms are distinguishable within a namespace.

  • Updated: Fri, 6 Mar 2015 20:58 GMT