Semantics Of Business Vocabulary And Business Rules Avatar
  1. OMG Specification

Semantics Of Business Vocabulary And Business Rules — All Issues

  • Acronym: SBVR
  • Issues Count: 453
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SBVR15-20 ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-18 'reality' and 'in-practice' models SBVR 1.0 SBVR 1.5 Closed; No Change closed
SBVR15-14 SBVR SE does not support the DateTime usage of subscripts SBVR 1.1 SBVR 1.5 Closed; No Change closed
SBVR15-8 The use of UML described in the Annex does not represent any known UML tool nor the UML specification SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-38 SBVR should use the latest MOF rather than sticking with MOF 2.0. SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-35 Issue: 'sentential form' is ambiguous SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-30 SBVR should cover the concept of IRI as well as/instead of URI. SBVR 1.1 SBVR 1.5 Closed; No Change closed
SBVR15-48 SBVR should re-consider the use of smart quotes SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-44 Error message from XML Schema validator when trying a SVBR XSD SBVR 1.0 SBVR 1.5 Closed; No Change closed
SBVR15-71 The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular SBVR 1.1 SBVR 1.5 Duplicate or Merged closed
SBVR15-143 Inappropriate Use of “Fact Model” SBVR 1.4 SBVR 1.5 Resolved closed
SBVR15-89 Problems with denotation SBVR 1.2 SBVR 1.5 Closed; No Change closed
SBVR15-12 Add Omitted Word 'if' SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-11 ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-10 SBVR Issue: Problematic necessity in 8.5.2 SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-5 Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles SBVR 1.1 SBVR 1.5 Closed; No Change closed
SBVR15-37 Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”. SBVR 1.1 SBVR 1.5 Closed; No Change closed
SBVR15-29 Section C.10 states that the default assumed multiplicity for an unannotated association end is * SBVR 1.1 SBVR 1.5 Duplicate or Merged closed
SBVR15-26 ANNEX G COLOR-CODED CONCEPT NOT DECLARED SBVR 1.2 SBVR 1.5 Closed; No Change closed
SBVR15-55 typo in clause 10.1 SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-54 C.5.2, including the diagram, should use single guillemet characters not >> and << SBVR 1.1 SBVR 1.5 Duplicate or Merged closed
SBVR15-52 No relationship defined between clause 8 concepts and clause 11 concepts SBVR 1.0 SBVR 1.5 Closed; No Change closed
SBVR15-51 Clause 8 does not include the concepts needed to represent itself SBVR 1.0 SBVR 1.5 Closed; No Change closed
SBVR15-46 Missing " Concept Type" in 'at least n quantification' SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-72 SBVR typo - duplicated entry in Index (p. 225) SBVR 1.1 SBVR 1.5 Closed; No Change closed
SBVR15-69 SBVR Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-96 SBVR Issue - Stand-Alone 'Must' in a Necessity SBVR 1.2 SBVR 1.5 Closed; No Change closed
SBVR15-98 Correct the styling errors in Definition text SBVR 1.4 SBVR 1.5 Resolved closed
SBVR15-86 Note for Advice of Permission SBVR 1.4 SBVR 1.5 Resolved closed
SBVR15-120 wrong styling for entry 'operating country' SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-84 Add Example for Definitional Rule SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-85 Add 2 Statement Examples SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-23 Distinguishing the senses of infinitive and present tense SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-22 Updating Annex F "The RuleSpeak Business Rule Notation SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-21 Define that Clause 10 ‘Fact Models’ are by Default Closed World Models SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-19 the scope/namespace of a placeholder SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-17 Revise Modeling of Fact Model and Conceptual Schema SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-16 "thing has property". SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-15 qualifiers whose subject is a property of the referent SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-13 'closed semantic formulation' is not properly defined SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-9 'another' unnecessarily restricts the concept 'other' SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-7 How can an attributive role be declared? SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-6 The notion of “well-formedness” in compliance point 1 should be defined SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-4 styling of signifiers SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-28 Definition of "categorization scheme contains category" SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-3 SBVR issue: Can there be multiple instances of a thing? SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-2 Misleading text in A.4.2.3 SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-1 Noun form designates two different concepts SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-45 Move 'rulebook' to Clause 12 SBVR 1.0 SBVR 1.5 Closed; No Change closed
SBVR15-66 SBVR Issue: Use of 'Partitioning' in the Definition of Categorization Scheme SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-63 SBVR 1.2 - Error in Annex E figure (p. 6) SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-61 Definition of "representation uses vocabulary" (Clause 11 SBVR 1.1 SBVR 1.5 Resolved closed
SBVR15-83 Definition of Practicable re Concepts SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-24 Correct the scope of placeholder terms SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-43 SBVR Issue: representations of propositions by name SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-42 SBVR ISSUE - definite description SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-41 Annex F is in the wrong specification SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-40 Use of morphological variants of terms is inadequately addressed SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-39 Inadequate, Overlapping and Disorganized Specs for Sets and Collections of Concepts, Meanings, and Representations SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-36 Precedence of operators SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-34 Fix the objectification example SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-33 Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-32 SBVR Issue: Mis-use of Date-Time Concepts SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-31 extending an adopted concept SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-27 Issue "fact type role is in fact type" SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-25 'categorization scheme' and 'categorization type' are related SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-59 No way to adopt a concept or a glossary item SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-58 SBVR Vocabularies Relationship to SBVR Subclause 10.1.1 SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-57 Concept System SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-56 Existential and Elementary SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-53 Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1 SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-49 Annex H recommends faulty UML constructs SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-47 Notation for the Logical Representation of Meaning SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-50 The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-74 Additional Improvements to Clause 10 SBVR 1.0b2 SBVR 1.5 Deferred closed
SBVR15-73 no glossary entry for intensional roles SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-70 Redefinition of "Body of Shared Concepts" (Clause 11) SBVR 1.1 SBVR 1.5 Deferred closed
SBVR15-68 Distinguishing between Representation Expressions With and Without Embedded Markup SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-67 Clean up and Complete Vocabulary for Clause 10.1.1 SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-65 SBVR issue - Need verb concept to support "local closure" SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-64 Inconsistent use of terminology when relating facts to fact types SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-62 Keyword "another" SBVR 1.0 SBVR 1.5 Deferred closed
SBVR15-60 Formalize the 'quantity' entry SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-93 SBVR Issue: 'denotes' is too narrowly defined SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-80 SBVR Issue - What is a 'terminological entry' SBVR 1.3 SBVR 1.5 Deferred closed
SBVR15-79 Multiple interpretations of the General Concept caption SBVR 1.3 SBVR 1.5 Deferred closed
SBVR15-78 SBVR Issue - Annex A is a mistitled grab bag SBVR 1.3 SBVR 1.5 Deferred closed
SBVR15-77 SBVR Metamodel Fixes Related to a Formal Logics Interpretation SBVR 1.0b1 SBVR 1.5 Deferred closed
SBVR15-76 The Notion of “Involvement” has not been Adequately Specified with in SBVR SBVR 1.0b2 SBVR 1.5 Deferred closed
SBVR15-75 Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre SBVR 1.0b2 SBVR 1.5 Deferred closed
SBVR15-92 SBVR Issue: Definitions should be tagged by language SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-90 SBVR Issue: 'partitive verb concept' is ill-defined SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-95 Not all closed logical formulations formulate propositions SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-81 Rulebook is for governed community SBVR 1.3 SBVR 1.5 Deferred closed
SBVR15-94 Use of SBVR markup in specifications SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-91 SBVR Issue: Erroneous normative requirements for SBVR XML SBVR 1.2 SBVR 1.5 Deferred closed
SBVR15-88 SBVR issue - "behavioral business rule" vs. "behavioral SBVR 1.2 SBVR 1.5 Deferred closed
SBVR14-99 Definition of Rulebook SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-104 Behavioral Rule Is Violated SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-97 SBVR-Issue: 'no' as an SBVR key word (styled) SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-98 Stand-Alone 'Must' in a Necessity SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-102 Rule Set SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-15 Swap Preferred Signifiers for (Business) Rules and Advices SBVR 1.1 SBVR 1.4b2 Resolved closed
SBVR14-103 Definition of Business Rule – Being Practicable SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-100 Note for Rule SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-101 'necessity' and 'obligation' are missing SBVR concepts SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-96 new SBVR issue: Add key words to A.2.1.3 Modal Operations SBVR 1.2 SBVR 1.4b2 Resolved closed
SBVR14-4 styling of signifiers SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-1 Noun form designates two different concepts SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-3 SBVR issue: Can there be multiple instances of a thing? SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-9 'another' unnecessarily restricts the concept 'other' SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-11 ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-2 Misleading text in A.4.2.3 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-13 omission of the word 'if' SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-5 Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-6 The notion of “well-formedness” in compliance point 1 should be defined SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-7 How can an attributive role be declared? SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-19 Revise Modeling of Fact Model and Conceptual Schema SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-20 'reality' and 'in-practice' models SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-10 SBVR Issue: Problematic necessity in 8.5.2 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-18 "thing has property". SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-14 'closed semantic formulation' is not properly defined SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-17 qualifiers whose subject is a property of the referent SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-16 SBVR SE does not support the DateTime usage of subscripts SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-22 ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-21 the scope/namespace of a placeholder SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-8 The use of UML described in the Annex does not represent any known UML tool nor the UML specification SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-25 Distinguishing the senses of infinitive and present tense SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-23 Define that Clause 10 ‘Fact Models’ are by Default Closed World Models SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-24 Updating Annex F "The RuleSpeak Business Rule Notation SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-31 Section C.10 states that the default assumed multiplicity for an unannotated association end is * SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-33 extending an adopted concept SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-26 Correct the scope of placeholder terms SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-27 'categorization scheme' and 'categorization type' are related SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-28 ANNEX G COLOR-CODED CONCEPT NOT DECLARED SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-32 SBVR should cover the concept of IRI as well as/instead of URI. SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-30 Definition of "categorization scheme contains category" SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-29 Issue "fact type role is in fact type" SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-41 Inadequate, Overlapping and Disorganized Specs for Sets and Collections of Concepts, Meanings, and Representations SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-35 Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-42 Use of morphological variants of terms is inadequately addressed SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-38 Precedence of operators SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-36 Fix the objectification example SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-43 Annex F is in the wrong specification SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-44 SBVR ISSUE - definite description SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-45 SBVR Issue: representations of propositions by name SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-39 Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”. SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-34 SBVR Issue: Mis-use of Date-Time Concepts SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-37 Issue: 'sentential form' is ambiguous SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-49 Notation for the Logical Representation of Meaning SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-50 SBVR should re-consider the use of smart quotes SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-40 SBVR should use the latest MOF rather than sticking with MOF 2.0. SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-54 No relationship defined between clause 8 concepts and clause 11 concepts SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-58 Existential and Elementary SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-52 The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-51 Annex H recommends faulty UML constructs SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-57 typo in clause 10.1 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-46 Error message from XML Schema validator when trying a SVBR XSD SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-55 Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-60 SBVR Vocabularies Relationship to SBVR Subclause 10.1.1 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-47 Move 'rulebook' to Clause 12 SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-56 C.5.2, including the diagram, should use single guillemet characters not >> and << SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-48 Missing " Concept Type" in 'at least n quantification' SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-65 SBVR 1.2 - Error in Annex E figure (p. 6) SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-59 Concept System SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-53 Clause 8 does not include the concepts needed to represent itself SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-69 Clean up and Complete Vocabulary for Clause 10.1.1 SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-66 Inconsistent use of terminology when relating facts to fact types SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-67 SBVR issue - Need verb concept to support "local closure" SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-63 Definition of "representation uses vocabulary" (Clause 11 SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-64 Keyword "another" SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-73 The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-62 Formalize the 'quantity' entry SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-61 No way to adopt a concept or a glossary item SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-75 no glossary entry for intensional roles SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-74 SBVR typo - duplicated entry in Index (p. 225) SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-68 SBVR Issue: Use of 'Partitioning' in the Definition of Categorization Scheme SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-80 Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-89 The Notion of “Involvement” has not been Adequately Specified with in SBVR SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-79 Additional Improvements to Clause 10 SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-91 SBVR Metamodel Fixes Related to a Formal Logics Interpretation SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR14-94 SBVR Issue - What is a 'terminological entry' SBVR 1.3 SBVR 1.4b2 Deferred closed
SBVR14-93 Multiple interpretations of the General Concept caption SBVR 1.3 SBVR 1.4b2 Deferred closed
SBVR14-92 SBVR Issue - Annex A is a mistitled grab bag SBVR 1.3 SBVR 1.4b2 Deferred closed
SBVR14-72 Redefinition of "Body of Shared Concepts" (Clause 11) SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-70 Distinguishing between Representation Expressions With and Without Embedded Markup SBVR 1.0 SBVR 1.4b2 Deferred closed
SBVR14-71 SBVR Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept SBVR 1.1 SBVR 1.4b2 Deferred closed
SBVR14-84 Gap that Needs to be Filled by Concept Role Playing of Thing in Occurrence SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-83 Entry for "categorization scheme", p. 147, Definition. and Example SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-87 owned definition and adopted definition are roles SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-77 Definition of 'question' SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-86 'Thing' Is Incorrectly Equated with ISO 1087 'Object' SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-88 Relationships Between Definition Concepts and Semantic Formulation Concepts Seem to be Wrong or Missing SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-90 Vocabulary Adoption vs. Inclusion SBVR 1.0b2 SBVR 1.4b2 Deferred closed
SBVR14-81 "SBVR 'Thing' <-> 'Expression' Architecture" Needs Fixing SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR14-82 Bring the Specification of SBVR Which is in Terms of Itself to the Full SBVR Metamodel Standard SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR14-76 Section: 8.3 SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR14-78 Section: 8.7 SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR14-85 SBVR Issue - Context for understanding representations SBVR 1.0b1 SBVR 1.4b2 Deferred closed
SBVR12-105 Regroup Concepts into Diagrams and Update Narrative Text based on the Resequenced SBVR Table of Contents SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-104 SBVR issue: Styling of SBVR terms/wordings in vocabulary clauses SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-98 SBVR issue: Misc. styling & caption fixes SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-103 SBVR issue: Consolidate 2 entries for 'verb concept wording' SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-102 SBVR issue: Add entry for "element" Source SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-101 Consolidating 2 verb concept entries that mean concept incorporating characteristics SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-100 SBVR issue: Misc. typo fixes SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-99 SBVR issue: Consolidating 2 verb concept entries that mean SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-97 SBVR issue: Correct the wording of text in Semiotic/Semantic Triangle diagram callout SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-96 Re-Sequencing SBVR SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-95 Simplification of SBVR by Integrating Clauses 8 & 11 SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-94 New SBVR issue - Re-sequencing Clause 8 SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-93 SBVR issue - Re-sequencing Clause 11 SBVR 1.1 SBVR 1.2 Resolved closed
SBVR11-141 Definition of Vocabulary SBVR 1.0 SBVR 1.1 Resolved closed
SBVR_-60 'state of affairs' is an individual concept, not a thing 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_-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_-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_-46 SBVR Issue - Restrictions on Variables 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_-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_-37 ‘expression’ as a bindable target 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_-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_-27 Exceptions 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_-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_-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_-22 SBVR Issue - Annex C.1.1.3 "only if" 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
SBVR12-90 SBVR 1.2] 'level of enforcement' editorial correction SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-89 SBVR 1.1 typos - p. 100 (logics modality table) SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-88 New issue: Individual Verb Concept SBVR 1.1 SBVR 1.2 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-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-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-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-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-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-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-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-108 Making Annex A Normative 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
SBVR11-137 Definition of proposition SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-136 "Quantification" Needs to Be Renamed SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-140 Simplification of presentation of Annex E SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-139 Actuality demonstrates Proposition SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-138 'Variable' should be renamed as 'formulaic variable' or its meaning clarified SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-132 "Objectification" Needs to Be Renamed SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-131 SBVR Issue - Relationships between States of Affairs SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-135 "Projection" Needs to Be Renamed SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-134 "Aggregation Formulation" Needs to Be Adjusted SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-133 "Nominalization" Needs to Be Renamed SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-109 Placeholder concepts model SBVR Structured English syntax SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-108 "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-107 [SBVR] fact type role designation SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-106 Set requires distinguished things SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-105 'quantity' and 'number' are not formal logic concepts SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-104 No normative reference to ISO 6093 SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-103 SBVR - change to Definition of 'fact type' SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-102 New SBVR Issue: "Template" & "Templating SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-111 SBVR editorial issue SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-110 SBVR recognizes the notion of "property" in Clause 11.1.5 in "is-property-of", but never defines the concept directly SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-112 Error in Example for "noun concept nominalization" SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-118 inappropriate definitions of burinsss rule, rule statement SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-117 assortment fact types SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-115 Inconsistency in is-role-of and is-category-of fact types SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-114 SBVR Editorial Issue - closed projection defines noun concept SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-113 SBVR - Error in MeaningAndRepresentation-Model.xml SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-116 is-property-of fact types SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-86 SBVR Issue: What is a fact type form SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-85 Definitions in subsection 11.1.5 SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-84 Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-83 SBVR Issue: can a role range over multiple object types SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-82 Note for individual concept does not follow from the Definition SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-81 fact type 'fact type form incorporates fact symbol' needs additional captio SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-80 SBVR typos SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-77 terminological dictionary SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-76 editorial issue -- example is missing a line SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-79 "characteristic type" should be a "category type" SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-78 A rulebook should have a URI SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-75 URGENT SBVR.xsd issue SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-74 mismatch between diagram SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-101 new SBVR issue - relationship of 'vocabulary' and 'rulebook' SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-100 Use of "denotes" in note for "state of affairs" SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-90 Note for Is-Facet-of Fact (Type) SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-89 Use of the Signifier "Fact Model" SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-88 SBVR Issue: Model expression structure SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-87 SBVR Issue: Definition of signifier SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-99 Instances of Clause 8 fact type should be states of affairs SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-96 Coexistence approach to SBVR SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-95 SBVR Fig 12-1 tweak SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-94 SBVR Issue : Inconsistent use/definition of keyword 'or' SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-98 Move the Definitions in Subclause 8.5 to Clause 13 SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-97 Concepts-centric Model and Fact Model are different SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-92 The segmentation 'Thing in Context' is inconsistent with the definitions of 'role' and 'facet' SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-91 SBVR did not pick up the ISO synonym "Part-Whole Relation SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-93 Definition of Is-Property-Of Fact Type SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-124 Explicitness of Representation SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-123 Governed Community & Adoption of Business Rules SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-122 Individual Concept and Change SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-121 Example of quantity vs. quantification SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-130 Adoption of Concepts SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-129 Clarify Objectification SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-128 A statement may express no proposition SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-127 Clarify difference between EXISTS and OCCURS SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-126 SBVR typo - p. 26 SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-125 Conflation of the signifier “rulebook” with the concept/definition for Speech Community Representations SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-120 example elementary fact SBVR 1.0 SBVR 1.1 Resolved closed
SBVR11-119 example definitions (of "Australian") SBVR 1.0 SBVR 1.1 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-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-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-50 Body of Shared Meanings 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-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-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-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-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-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-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-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-87 SBVR Issue - Concept Expression versus Meaning Expression 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-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-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-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-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-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-107 Association Names in UML Diagrams 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-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-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-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-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-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-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-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-64 Definition of 'proposition' 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-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-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-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-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-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-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
SBVR12-77 Clarify Purpose and Scope of SBVR, the Authority for SBVR Vocabulary Content, and SBVR Vocabularies SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-76 "Three Editing Instructions Overlooked in Issue 17017 Resolution SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-75 SBVR makes use of ElementImports to give additional aliases to some elements in the same package SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-74 Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-83 Scope of an SBVR Body of Shared Concepts SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-82 Clause 10.1.2 Vocabulary Clarifications SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-81 Align Definitions of Modal Entries in Clauses 8, 9 & 10 SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-80 Eliminate Ambiguity from Two Interpretations for the Definition of Proposition SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-79 Correct ambiguities in signifiers and definitions of noun concepts SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-78 Individual Verb Concept SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-86 Clarifications and Fixes for State of Affairs Related Entries SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-85 Add Generic Occurrence to SBVR to Support Other Specifications for Occurrence in Time, Space or Other Dimensions SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-84 individual verb concept’ in SBVR SBVR 1.1 SBVR 1.2 Resolved closed
SBVR12-87 The SBVR document is far larger than optimal. It needs to be reduced in size SBVR 1.1 SBVR 1.2 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-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-16 Fact-types and templates (and subscripts) SBVR 1.0b1 SBVR 1.0b2 Resolved closed
SBVR-22 Add 'Synonym: aspect' caption SBVR 1.0b1 SBVR 1.0b2 Resolved closed

Issues Descriptions

ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS

  • Key: SBVR15-20
  • Legacy Issue Number: 19518
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Annex B, references to diagramming conventions

    Annex B has a number of references to diagramming conventions that are too colloquial. The implication is that the reader is already familiar with the UML or CDG diagramming conventions, but this is not appropriate, since the whole point of the Annex is to be explanatory at this level. For example:

    B.3.5. “UML’s arrow style for ‘instantiation’” What is this arrow style? Where is it explained?

    B.3.5. The notation has been adapted from standard UML notation to make it more ‘business friendly’. For example, in UML, in instance (‘object’) would be labeled as, Canada: country.

    This information does not belong here, but in Annex C.

    B.3.5. “the box in box style”. Where is this explained? Is it UML or CDG?

    Suggested solution: when referencing UML or CDG diagramming conventions, do not attempt to be descriptive of symbols or drawing conventions, but use ‘base’ references instead: all the diagramming information should be in one place, ie., in Annex C or I respectively, but not in Annex B. Make sure the same format is used for all references to Annexes C and I, and that the difference between the two diagramming techniques is signposted adequately. An even better, more practical solution would be in each case to depict the symbol(s) involved and to refer to the appropriate paragraph in Annex C or I for any textual explanation. This would cause duplication of symbols between the Annexes but it would make Annex B much more helpful.

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Make the suggested improvements by removing the instructions for how to do the graphic styles from Annex B and by standardizing the Annex B referrals to the appropriate material in Annexes C and I.

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

'reality' and 'in-practice' models

  • Key: SBVR15-18
  • Legacy Issue Number: 15953
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

    In recognizing that an organization is not necessarily interested in recording all information about the real world, the SBVR proposes that there be two models of the world: a ‘reality model’ (of the real world) and an ‘in-practice model’ (of the organization’s view of the real world), which leads to some bizarre rule statements, listed below. Surely there is only 1 model in which both real-world objects and representations of them exist. The relevant quote from the SBVR is “Suppose the following two fact types are of interest: Employee was born on Date; Employee has Phone Number. In the real world, each employee is born, and may have more than one phone number. Hence the reality model includes the constraint ‘Each Employee was born on at least one Date’ (sic) and allows that ‘It is possible that the same Employee has more than one Phone Number.’ [If] the business decides to make it optional whether it knows an employee’s date of birth, [and] is interested in knowing at most one phone number for any given employee, … the in-practice model excludes the reality constraint ‘Each Employee was born on at least one Date’, but it includes the following constraint that does not apply in the reality model: ‘Each Employee has at most one Phone Number’. ”
    I believe there should be one model (not two), in which for each fact type there may be multiple rules reflecting specific requirements. Considering just dates of birth, the assertion “Each Employee was born on at least one Date” (which might be better worded as “Each Employee was born on exactly one Date”, “Each person has exactly one date of birth” or perhaps “Each person has a date of birth”) is a statement about the real world.
    Consider an insurance business that decides that it must collect the date of birth of each customer purchasing personal life insurance but does not need it for those purchasing only home insurance. Following the logic expressed in the SBVR (as quoted above) the ‘in-practice model(s)’ contain a new constraint: “Each person purchasing personal life insurance has a date of birth” (or “Each person purchasing personal life insurance must have a date of birth”) and an advice: “Each person purchasing only home insurance may not have a date of birth”.
    In fact the original assertion (“Each person has a date of birth”) still applies in the world view of the business, even to persons purchasing only home insurance. What is required is an additional constraint, which may be worded in one of the following forms “Each person who purchases personal life insurance must supply the date of birth of that person.” or “Each application for personal life insurance must specify the date of birth of the applicant.” and an advice “A person who purchases home insurance need not supply the date of birth of that person.”

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Wording is part of Formal Theory for SBVR and not part of the "SBVR Vocabulary"

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR SE does not support the DateTime usage of subscripts

  • Key: SBVR15-14
  • Legacy Issue Number: 18825
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The Date Time Vocabulary specification contains several Definitions and Necessities that use subscripted terms, e.g.,

    Necessity: For each time interval(2) and each time interval(3) that finishes time interval(2), the duration of the time interval(1) that starts time interval(2) complementing time interval(3) is equal to the duration of time interval(2) minus the duration of time interval(3).

    time point1 to time point2 specifies time period

    Definition: time point(1) is the first time point of a time point sequence and time point(2) is the

    last time point of the time point sequence and there is a time point(3) that is just before time point(2) in

    the time point sequence and time point(1) through time point(3) specifies the time period

    Each case introduces a subscripted term that is used to denote the same ‘referent’ ‘thing’ elsewhere in the definition/necessity. In the Necessity, all the subscripts are introduced terms. In the Definition, time point(1) and time point(2) refer to placeholders in the verb concept wording being defined, but time point(3) is an introduced term. These introduced terms were patterned on a usage of subscripts in SBVR clause 8.5.2 that introduces similar “local names”. SBVR Annex C does not describe such usages. Without them, it is not possible to formulate these definitions and necessities in SBVR Structured English.

    Is it the intent of SBVR SE to support such usages? If yes, then SBVR Annex C needs wording to support them. If no, then DTV needs to convert these formulations to plain text.

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Subscripting is now in Annex A

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

The use of UML described in the Annex does not represent any known UML tool nor the UML specification

  • Key: SBVR15-8
  • Legacy Issue Number: 19680
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The use of UML described in the Annex does not represent any known UML tool nor the UML specification. The examples are UML-like diagrams presumably created with a drawing tool.

    • In Figure C.1 the right hand class is shown with 2 names and an italicized label “also:” – this is not supported.
    • Section C.3 and Figure C.2: in UML, Instance diagrams only the class and not the instance name is ever underlined
    • Figure 6.3 is not a valid UML diagram if the lower shapes are InstanceSpecifications: they should have a colon after the names which should not be underlined. The use of Dependencies is not valid for class membership.
    • Figure 6.4 is not valid – an association may have only one name optionally accompanied by one direction indicator.
    • Figure C.7, C.12: In general UML does not include the notion of underline/font within a name: it’s modeled only as a text string.
    • Figure C.9 is not valid – one cannot have an association with only one end.
    • C.7.1, Figure 14: these 2 renderings are semantically identical in UML and serialized the same in XMI. UML has the ability to render the distinction using a GeneralizationSet with isDisjoint – so why not use that?
    • C.15: powertypes should not have a name before the colon in UML, though the property of type “branch type” may
    • C.9, Figure C.17: the dashed lien to association diamond is not valid in UML
  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Clarify that the Diagrams in Clauses 7-21 do not depict UML conventions or semantics

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR should use the latest MOF rather than sticking with MOF 2.0.


Issue: 'sentential form' is ambiguous

  • Key: SBVR15-35
  • Legacy Issue Number: 19514
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Formal Specification

    Problem: In Annex B.2.3 the term ‘sentential form’ is used with a different meaning than defined for this term in Clause 8.4.4.

    · In Annex B, it means the standardised form or ‘handle’ by which a verb concept is known in a presentation format such as a glossary. Going by this meaning, ‘customer rents car’ is the sentential form (Annex B uses ‘primary reading’ as a synonym) for the verb concept in question, and “car is rented by customer” is not a sentential form of the verb concept.

    · In Clause 8.4.4, it means any verb concept wording that is available for a given verb concept, except noun forms. Going by this meaning, as the examples provided make clear, “car is rented by customer” and “customer rents car” are alternative sentential forms.

    Suggested solution: Keep 8.4.4 as it is. Remove occurrences of ‘sentential form’ from Annex B, keeping only ‘primary reading’ in that context.

    Discussion:

    The dictionary basis for selecting the adjective ‘sentential’ in Annex B seems to be the meaning of ‘aphoristic’, as in ‘sentential saying’ or ‘sentential book’.

    The dictionary basis for selecting the adjective ‘sentential’ in 8.4.4. seems to be the meaning ‘of a sentence, concerning a sentence’, i.e., the association with ‘sentence’ as a linguistic term.

    The former use of ‘sentential’ in English seems to be the more common. This would explain why the issue has occurred. It also suggests that ‘sentential form’ in Clause 8 is not ideal.

    ‘Verb form’ as a complementary concept of ‘noun form’ would not have this problem but I agree that, because of cases where the wording contains no verb form at all, ‘verb form’ cannot be used. It could be said that ‘verb concept wording’ has the same problem, but I think it is more acceptable to say that a word like ‘of’ or ‘in’ is a “verb concept wording” than to say that it is a “verb form”.

  • Reported: SBVR 1.1 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    All references to "sentential forn" removed

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR should cover the concept of IRI as well as/instead of URI.


SBVR should re-consider the use of smart quotes


Error message from XML Schema validator when trying a SVBR XSD

  • Key: SBVR15-44
  • Legacy Issue Number: 18651
  • Status: closed  
  • Source: Ericsson ( Torbjorn Lindqvist)
  • Summary:

    We're currently building a Corporate Vocabulary and our idea is to use the SVBR provided XML Schema for all source documents.

    However, when trying the XSD-file available at the SVBR specification page in an XML Schema validator a got the error message:

    Src-import.3.1: The Namespace Attribute, 'http://schema.omg.org/spec/XMI/2.1', Of An <import> Element Information Item Must Be Identical To The TargetNamespace Attribute, 'http://www.omg.org/spec/XMI/20071213', Of The Imported Document.

    The XML Schema validator is available at the URL:
    http://www.freeformatter.com/xml-validator-xsd.html

    I have a sceen dump as well that I can send via email.

    I downloaded the XSD-file and changed the namespace to match the namespace in the import element.
    But it only resultet in a new fault.

    Any ideas?

  • Reported: SBVR 1.0 — Thu, 11 Apr 2013 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Fixed in SBVR v1.4

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular

  • Key: SBVR15-71
  • Legacy Issue Number: 19681
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular

    Again, no UML tool will be able to add/remove “has” in diagrams.

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — SBVR 1.5
  • Disposition Summary:

    Merged into SBVR 15-08

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Inappropriate Use of “Fact Model”

  • Key: SBVR15-143
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Page 8 currently includes the following Note.

    Note: As indicated in 2.4.1, an SBVR producer may produce instances of concepts not defined in SBVR as well. In such a case, the SBVR fact model would be only a part of the exchange document.

    SBVR proper does not use the term “fact model”. The second sentence of the Note should probably read as follows:

    “In such a case, the instances of concepts specified in the SBVR XMI Metamodel XML Schema (Clause 25.3) would be only a part of the exchange document.”

  • Reported: SBVR 1.4 — Tue, 16 Apr 2019 17:49 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Replaced "fact model" wording with appropriate wording to clarify sentence

    see attached Word document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Problems with denotation

  • Key: SBVR15-89
  • Legacy Issue Number: 19837
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    From SBVR v1.3, clause 8.7:

    term denotes thing

    Definition: the thing is an instance of the concept that is represented by the term

    thing has name

    Definition: the thing is the instance of the individual noun concept that is represented by the name

    Synonymous Form: name references thing

    Note: A use of an individual noun concept by its name denotes the thing that is in the extension of the individual noun concept.

    statement denotes state of affairs

    Definition: the statement indicates the state of affairs that is posited by the proposition that is expressed by the statement

    SBVR does not define ‘name’ at all. But, the UML diagram 8.12 shows ‘name’ as a category of ‘designation’, and the definition of ‘thing has name’ says that a ‘name’ represents a concept, which would make it a designation, and how it might differ from a term in that regard is not clear. In fact, the whole idea of a ‘name’ is that it denotes a thing, usually without regard to any concept, whereas a term designates a concept and indirectly denotes things.

    But most of the vocabulary in 8.7 contradicts the notations on the semiotic triangle figure in 8.1.1. In the semiotic triangle, an ‘expression’ denotes a ‘thing’, but a ‘term’ is not an ‘expression’ in SBVR, and a ‘statement’ is not an expression in SBVR. All of that proceeds from the dual use of ‘designation’ in ISO 1087 to mean both “the state of designating” and “the thing that designates”. This needs to be fixed. A term must be an expression in order to denote a thing, and a statement must be an expression in order to denote a state of affairs.

  • Reported: SBVR 1.2 — Thu, 24 Sep 2015 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    SBVR has been changed since Issue was submitted to deal with all points.

    see attached Wrod document

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Add Omitted Word 'if'

  • Key: SBVR15-12
  • Legacy Issue Number: 19671
  • Status: closed  
  • Source: AFAS Software B.V. ( Casper Lange)
  • Summary:

    In SBVR 1.4 (pg. 34), in the first Note for the entry 'proposition is true', change "A proposition is true if and only the" to "A proposition is true if and only if the".

  • Reported: SBVR 1.2 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Add a missing 'if'

    Add the missing 'if'.

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES

  • Key: SBVR15-11
  • Legacy Issue Number: 19519
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, 'role': 'ranges over' vs. 'specializes'.

    Clause 8, entry for ‘role’. Should the addition at the end of the second Example text: "(which generalizes the role)" read: "(which the role ranges over)"? As I understand it, you mean to say that the role shipment ranges over the general concept shipment. The reverse reading of "ranges over" is not "generalizes" (there is a specific Note at the lemma "role ranges over general concept" that warns against this confusion).

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Fix wording in the referenced example

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR Issue: Problematic necessity in 8.5.2

  • Key: SBVR15-10
  • Legacy Issue Number: 18824
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.5.2, the following Necessity appears:

    Necessity: If a concept[sub]1 is coextensive with a concept[sub]2 then the extension of the concept[sub]1 is the extension of the concept[sub]2.

    (where [sub] is used to show subscripts).

    There are three problems with this Necessity:

    1. This Necessity just restates the definition of ‘concept is coextensive with concept’ in 8.1.1.1. It adds nothing.

    2. It is the only occurrence in SBVR v1.1 of the use of a subscript outside of a placeholder term, and that use is not defined in Annex C.

    3. The meaning of the article ‘a’ before concept (1) and concept (2) is universal in this case, not existential, which contradicts Annex C.

    Delete it!

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Delete the Necessity that duplicates the definition, adding nothing to it

    (see attached Issue disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles

  • Key: SBVR15-5
  • Legacy Issue Number: 19683
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles (a renter, even of a car, may or may not drive it)

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Diagram with the problem was already removed by different Issue

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”.


Section C.10 states that the default assumed multiplicity for an unannotated association end is *

  • Key: SBVR15-29
  • Legacy Issue Number: 19685
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section C.10 states that the default assumed multiplicity for an unannotated association end is *. That’s a terrible idea since the UML default is 1 (i.e. 1..1).

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — SBVR 1.5
  • Disposition Summary:

    Merged into SBVR 15-08

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

ANNEX G COLOR-CODED CONCEPT NOT DECLARED

  • Key: SBVR15-26
  • Legacy Issue Number: 19520
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Annex G, G 6.2.8, lemma ‘rental is open’

    There is a color-coded occurrence of ‘end date/time is in the future’ but there is no such declared concept.

    Discussion: The way this Annex has been set up suggests that each colour-coding is meant to imply that the colour-coded concept is either explicitly listed or specifically adopted from a different vocabulary.

    The only like concept is in G.8.5, ‘period is future’. SBVR 1.1 Annex E used to have a concept ‘date/time is in the future’.

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Current version of Annex G no longer contains problem entry

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

typo in clause 10.1

  • Key: SBVR15-55
  • Legacy Issue Number: 17144
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    "vocabularies" is miss-spelled "vocabulaires" in the sixth paragraph of clause 10.1.1 in convenience document 8.

  • Reported: SBVR 1.1 — Mon, 20 Feb 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Fix Typo in clause 10.1

    Correct the spelling from 'vocabulaires' to 'vocabularies'. (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

C.5.2, including the diagram, should use single guillemet characters not >> and <<


No relationship defined between clause 8 concepts and clause 11 concepts

  • Key: SBVR15-52
  • Legacy Issue Number: 12541
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

    Some issues: 2) No relationship is defined between the clause 8 concepts and the clause
    11 concepts. Is a body of shared concepts based on a conceptual schema?
    How does a fact model relate to a terminological dictionary?

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Close - Already solved in SBVR v1.3

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Clause 8 does not include the concepts needed to represent itself

  • Key: SBVR15-51
  • Legacy Issue Number: 12540
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

    Some issues:

    1) Clause 8 does not include the concepts needed to represent itself, even
    though clause 2 says clause 8 is a standalone compliance point. Clause 8
    claims to be a vocabulary, but the concept "vocabulary" is in clause 11,
    not clause 8. Hence an implementation of clause 8 cannot model clause 8
    itself.

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Close - Already solved in SBVR v1.3

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Missing " Concept Type" in 'at least n quantification'

  • Key: SBVR15-46
  • Legacy Issue Number: 18890
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.x, in the entry for 'at least n quantification', the Definition ends with the term ‘logical fomulation kind’, which makes no sense in the context.

    What was intended is a new paragraph:

    Concept Type: logical formulation kind

  • Reported: SBVR 1.1 — Mon, 9 Sep 2013 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Move text to Concept Type: sub-entry where it belongs

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR typo - duplicated entry in Index (p. 225)


SBVR Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept

  • Key: SBVR15-69
  • Legacy Issue Number: 19568
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept

    • The entry for Noun Form in SBVR is currently silent as to whether or not a noun form can be based on a unary verb concept.
    • If the answer is no, a Note should say as much.
    • If the answer is yes, an example should be given.

    Resolution:
    Indicate explicitly yes or no, and include an example if yes.

  • Reported: SBVR 1.1 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    The answer is "yes' to "Can a Noun Form be Created on the Basis of a Unary Verb Concept?"

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR Issue - Stand-Alone 'Must' in a Necessity

  • Key: SBVR15-96
  • Legacy Issue Number: 19884
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Issue: Stand-Alone 'Must' in a Necessity

    The second Necessity for "adopted definition" on p.137 includes a stand-alone "must". Use of a stand-alone "must", with its inherent sense of obligation, in Necessities is inappropriate. (In reviewing the whole document, this is the only case I find of its use in a Necessity.)

    Resolution

    Change:

    Necessity: Each adopted definition must be of a concept in the body of shared meanings that unites the semantic community that has the speech community.

    to

    Necessity: Each adopted definition is of a concept in the body of shared meanings that unites the semantic community that has the speech community.

  • Reported: SBVR 1.2 — Tue, 14 Jun 2016 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Close - Already solved in SBVR v1.4

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Correct the styling errors in Definition text

  • Key: SBVR15-98
  • Legacy Issue Number: 19901
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Correctly style the text at the end of the Definition text of two entries on p. 36. The styling should not be all in ’keyword’ style.

  • Reported: SBVR 1.4 — Wed, 15 Feb 2017 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Correct the styling errors in Definition text

    Correct the styling errors in the Definition text for the entries "element of guidance necessitates state of affairs" and "element of guidance obligates state of affairs" (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Note for Advice of Permission

  • Key: SBVR15-86
  • Legacy Issue Number: 19899
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Acceptance of the Resolution for 19840 under Ballot 4 in the second half of 2016 resulted in the following text being substituted for a Note in the entry for Advice of Possibility.
    Note: Every definitional rule implies an advice of possibility. Consider the definitional rule expressed as:
    It is necessary that each rental has exactly one car group.
    Alternatively:
    Each rental always has exactly one car group.
    This definitional rule implies an advice of possibility that can be expressed as:
    It is possible that a rental has exactly one car group.
    Alternatively:
    A rental can have exactly one car group.
    There is no practical reason, however, to express the advice of possibility implied by a definitional rule explicitly. In such cases, best practice generally favors keeping the number of elements of guidance to be managed to a minimum.
    The equivalent substitution needs to be done for Advice of Permission. It’s just a clarification of the Note, which is otherwise somewhat hard to decipher

  • Reported: SBVR 1.4 — Tue, 24 Jan 2017 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Clarify Note for Advice of Permission

    Clarify wording and add two examples to Note (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

wrong styling for entry 'operating country'

  • Key: SBVR15-120
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    The line for 'operating country' reflects the styling of a 'Definition:' caption. It should be styled as a vocabulary entry term.

    This can be confirmed by checking this entry in the Word docx source, where this line (paragraph) has the correct style of 'term'.

  • Reported: SBVR 1.2 — Sun, 2 Sep 2018 18:41 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Fix SBVR SE styling in SBVR Annex G: EU-Rent Example terminological entry

    (see attached Issue Disposition document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Add Example for Definitional Rule

  • Key: SBVR15-84
  • Legacy Issue Number: 19895
  • Status: closed  
  • Source: NIST ( Ron S. Ross, Ph.D.)
  • Summary:

    The entry for "Definitional Rule" in SBVR lacks an example. Here is an appropriate one.

    EU-Rent requires that a rental is for one car group (economy, compact, full-size, etc.). This definitional rule can be expressed as:
    It is necessary that each rental has exactly one car group.
    Alternatively:
    Each rental always has exactly one car group.

  • Reported: SBVR 1.2 — Fri, 5 Aug 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Add Example for Definitional Rule

    Add two examples (see attached Word Document) (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Add 2 Statement Examples

  • Key: SBVR15-85
  • Legacy Issue Number: 19893
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    The SBVR entries for the various statement forms present Example(s) that illustrate the particular statement kind. Most of the entries provide two examples, to illustrate both the verbose and the more-compact statement styles. However, two of the entries only provide one example (the verbose style).

    Resolution: Add a 2nd example statement, parallel to each of the current examples, to the entries ’non-necessity statement’ and ’permission statement’, illustrating the use of ’not always’ and ’need not’ (respectively).

  • Reported: SBVR 1.2 — Thu, 4 Aug 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Add 2 Statement Examples

    Add a 2nd example statement, parallel to each of the current examples, to the entries ’non-necessity statement’ and ’permission statement’, illustrating the use of ’not always’ and ’need not’ (respectively). (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Distinguishing the senses of infinitive and present tense

  • Key: SBVR15-23
  • Legacy Issue Number: 17571
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    New SBV issue: Distinguishing the senses of infinitive and present tense
    From Don Baisley

    There are many verbs for which the present tense of a verb conveys a particularly different sense than the infinitive. The difference I refer to is not about "the present time", but about "occurring at least occasionally". For example, the statement that "Pam surfs" (present tense) combines the meaning of "to surf" (the infinitive) and the meaning that “it happens at least occasionally”.

    For such verbs, there is a challenge when using SBVR's typical pattern of defining verb concepts in the present tense. It tends to conflate the infinitive sense of a verb with the different sense meant by the present tense. That conflation causes problems. This is not an issue for ORM or other approaches that do not try to support natural language tense in a generic way. The problem has no apparent impact for many verbs where the present tense sense of "occurring at least occasionally" is inconsequential or inapplicable. The problem is especially troublesome for eventive verbs. Most SBVR verbs are stative, so the problem has tended to go unnoticed in the SBVR vocabulary itself.
    If supporting tense in a generic way, in logical formulations, the other tenses should be built on objectifications that start with the infinitive sense of a verb, not with the present tense. Also, modal operations like obligation build on the infinitive sense.

    For examples below, I define verb concept forms for generic "tense" concepts using the verb "occurs" (where the there is a role that ranges over the concept 'state of affairs'). The choices of signifier and form are arbitrary (not necessary), but seem to convey the sense of the tenses naturally.

    Example:
    'person surfs' (present tense)
    'person surf' (the infinitive sense)

    Where someone puts 'person surfs' in a business glossary, there is an underlying verb concept that has the sense of "to surf", the infinitive. I show it here in examples as 'person surf' (leaving out the infintizing "to"). This underlying verb concept is necessary to correctly formulate other tenses, and even necessary to formulate use of the present tense in some cases, which I will show later.

    Here are several examples of statements and interpretations using generic tense concepts built on the verb "occur". To be terse, I show objectification using brackets.

    Pam surfs.
    [Pam surf] occurs

    Pam is surfing.
    [Pam surf] is occurring

    Pam was surfing.
    [Pam surf] was occurring

    Pam has been surfing.
    [Pam surf] has been occurring

    Pam surfed.
    [Pam surf] occurred

    Pam will be surfing.
    [Pam surf] will be occurring

    Pam will surf.
    [Pam surf] will occur

    Pam will have been surfing.
    [Pam surf] will have been occurring

    The second example above, "Pam is surfing", can serve to illustrate the need to build on the infinitive rather than the present tense sense. To build on the present tense would be to say the thing that “is occurring” is Pam surfing at least occasionally, which is incorrect. The present continuous and other tenses do not include the present tense sense of occurring at least occasionally, so they cannot rightly be built upon a concept that conveys that sense.

    I said above I would show where the infinitive sense is sometimes needed even for the present tense. Here is a case where the infinitive 'person surf' concept is needed to formulate a statement that uses "surf" only in the present tense:

    Pam talks while she surfs.

    Wrong Interpretation I1: [Pam surfs] occurs while [Pam talks] occurs

    I1 misses the key sense of the statement, because [Pam surfs] (present tense) means that surfing is something Pam does at least occasionally and [Pam talks] means that talking is something that Pam does at least occasionally. I1 applies 'state of affairs1 occurs while state of affairs2 occurs' to the wrong states of affairs (the states in which Pam occasionally surfs and Pam occasionally talks).

    Right Interpretation I2: [[Pam surf] occur while [Pam talk] occur] occurs

    I2 correctly factors out the tense and applies it at an outer level (as we often do with modal operations). The conjunction joins objectifications of the underlying sense of "to surf" and "to talk" without the added meaning of the present tense (that the surfing or talking is at least occasional). The sense of present tense (happening at least occasionally) is then added at the outside where it applies to the simultaneous actions.

    SBVR does not prevent verbs concepts from being defined in glossaries in the infinitive , as is typical of dictionary definitions of verbs. That approach has always been available. But that approach is not used in SBVR’s own glossary and examples. In general, the sense of “occurs at least occasionally” is absent from SBVR’s own verb concepts, so the distinction is unimportant. But business rules and facts run into the problem. E.g., a EU-Rent rule about whether a renter smokes vs. a rule about whether he is smoking when in a rental car.

    Recommendation:

    It will be best to resolve this in a way that does not disturb the business-friendly approach of showing verb concept readings in the present tense. It might be possible to define a pattern in SBVR Structured English by which verb concepts with an infinitive sense are implied where present tense versions are explicitly presented in a glossary.

    Examples of formulations need to show the distinction. Existing examples should be examined and fixed as needed. New formulation examples might be helpful to demonstrate using generic tense concepts to build on a root verb concept.
    None of this changes the meaning of 'state of affairs' or 'objectification', but understanding this issue and its solution might help bring clarity to some of the examples that have been discussed.

  • Reported: SBVR 1.1 — Tue, 28 Aug 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Updating Annex F "The RuleSpeak Business Rule Notation

  • Key: SBVR15-22
  • Legacy Issue Number: 18621
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The problem statement: The Annex is out of date with respect to RuleSpeak notation, probably the newly released version of EU-Rent, and perhaps newer aspects of SBVR itself.

  • Reported: SBVR 1.1 — Fri, 5 Apr 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Define that Clause 10 ‘Fact Models’ are by Default Closed World Models

  • Key: SBVR15-21
  • Legacy Issue Number: 16683
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
    The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns:
    1. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption.
    The proposed resolution is:
    1. Define that Clause 10 ‘fact models’ are by default closed world models

  • Reported: SBVR 1.1 — Mon, 14 Nov 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

the scope/namespace of a placeholder

  • Key: SBVR15-19
  • Legacy Issue Number: 19124
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.4.4, there is a necessity in the entry for ‘placeholder’: “Each placeholder is in exactly one verb concept wording”. Now, immediately before section 8.4.4, in the entry for ‘statement expresses proposition’, there is a synonymous form: ‘proposition has statement’. So, ‘statement’ is the text of two placeholders. A.4.12 (Synonymous forms) tries to say that these two different placeholders refer to the same verb concept role, but the statement is garbled: “The ones using the same designation as placeholders of the primary form represent the corresponding verb concept roles…” The ‘designation used by a placeholder’ is the representation of the range concept by a signifier for that concept, per 8.4.4 ‘placeholder uses designation’. What is intended here is: “A placeholder that has the same expression as a placeholder of the primary verb concept wording represents the same verb concept role.”

    Further, in that same example entry, there is a Definition: “the statement represents the proposition”. According to A.4.2.3, the expression ‘statement’ refers to a placeholder in the verb concept wording, but that is ambiguous, since there are two verb concept wordings. That text should say the primary verb concept wording, so as to disambiguate the reference.

    Again, in A.4.12, the following sentence appears: “The order of placeholders for verb concept roles can be different.” What does that mean? By the necessity above, the placeholders are different, so they cannot be reordered. The intent is that the relative positions of the placeholders for the same verb concept role may be different.

    Finally, all of this is an elaborate convention to maintain the given Necessity. It seems that it would be much easier to make the placeholder a representation of the verb concept role throughout the terminological entry, as distinct from having it denote the verb concept role in the primary entry and in the Definition(s), but not in Synonymous forms, Descriptions, Notes, etc. The only function of that Necessity is to make a single ternary fact type: “Verb concept wording has placeholder at starting character position” into two binary fact types that each convey half the concept. A great deal of effort is expended to explain use of a business-friendly syntax that violates the stated model of a purely syntactic concept – the intent is that the placeholder expression represents the same verb concept role throughout the entry. And verb concept wordings are ONLY about expressions. The underlying problem is that the concept ‘terminological entry’ is not part of the clause 8 vocabulary, and is therefore not available to be the scope of a placeholder. But then, the concept ‘primary verb concept wording’ is not in the clause 8 vocabulary, either.

  • Reported: SBVR 1.1 — Mon, 25 Nov 2013 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Revise Modeling of Fact Model and Conceptual Schema

  • Key: SBVR15-17
  • Legacy Issue Number: 13150
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    understand you will be discussing the topic of packaging SBVR tomorrow, and I want to provide a perspective on this topic and make a request.

    In my view, the key packaging concepts “fact model” and “conceptual schema” need to be in the normative SBVR metamodel to support widespread sharing and reuse of SBVR models. We want to promote the development of libraries of SBVR fact models and conceptual schemas and to compose fact models and conceptual schemas from other fact models and conceptual schemas. The ability to package these in a standard way is crucial to this end. A normative approach to globally identifying these models is needed to support their sharing and reuse. Concepts of packaging, identification, and composition of fact models and conceptual schemas are preferably included in Clause 8. As the most basic compliance point, Clause 8 needs to be expressible in terms of itself, and to include concepts for packaging, identification, and composition of fact models and conceptual schemas. I understand a proposal is under consideration to move “fact model” and “conceptual schema” entries to Clause 10. This would be a mistake, as we would then have no normative way of specifying the packaging.

    The definition of “conceptual schema” should be refined to reflect the fact that a conceptual schema is a kind of fact model. The distinction between a conceptual schema and other fact models is that a conceptual schema includes at least one fact that asserts the existence of a concept. Other fact models that are not conceptual schemas contain only ground facts. The text of SBVR makes it clear that a conceptual schema is a fact model, that every SBVR interchange document is a fact model. That “conceptual schema” specializes “fact model” should be reflected in the definition of “conceptual schema.”

    The term “vocabulary” is not used in the SBVR specification consistently with its definition as a “set of designations and fact type forms…” Each of the normative clauses of SBVR, called a “Vocabulary,” is actually an annotated conceptual schema. A conceptual schema comprises a “combination of concepts and facts (with semantic formulations that define them)…” The designations and fact type forms in each SBVR normative “Vocabulary” constitute the vocabulary of that “Vocabulary”. The definitions and necessities in the SBVR entries are statements of schema facts. The notes and examples are annotations of the conceptual schema. Ability to include annotations is crucial to practical development and use of any model, and is universally provided for in other and modeling and programming languages. It should be possible to normatively include annotations in a SBVR conceptual schema or fact model. Accordingly, it is recommended that “description” and related concepts of notes and examples in Clause 11.2.2 be moved to Clause 8 to support annotation of fact models. With respect to the semantic formulations of a conceptual schema, it is preferred that Clause 8 only include statements of the definitions and schema facts, and leave it to Clause 9 to include the semantic formulations of these. Either “vocabulary namespace” and fact types that use the term should be moved to Clause 11, or “vocabulary” should be moved to Clause 8. The concept “vocabulary” is not necessary in Clause 8 but might be conveniently located there. Namespaces adequately serve the purpose of organizing designations and fact type forms. It is suggested the RTF consider providing recommendations for naming conventions for URIs of namespaces and related conceptual schemas that define and constrain the concepts represented by the designations and fact type forms in the namespaces.

    Here are some suggested entries for Clause 8 that show how the concepts described above might be modeled:

    conceptual schema

    Definition: fact model that includes at least one existential fact asserting a concept

    Note: This definition extends the definition of ‘conceptual schema’ in SBVR to formalize that a conceptual schema is a kind of fact model. This is evident in the specification text, but is not included in the current definition.

    Note: The facts of a conceptual schema in addition to the concept existential facts describe what is possible, necessary, permissible, and obligatory in each possible world of the domain being modeled.

    Note: Two levels of formalization of fact models (including conceptual schemas) are possible. 1) A fact model may contain only statements of definitions and other facts and not their semantic formulations. In this case, the fact model can meet the Meaning and Representation compliance point, 2.2.1. 2) A fact model may contain semantic formulations of its definitions and facts, in which case the fact model can meet the Logical Formulation of Semantics compliance point, 2.2.2.

    fact model1 includes fact model2

    Note: This fact type enables recursive composition of fact models and conceptual schemas.

    Necessity: This fact type is reflexive, antisymmetric, and transitive, i.e. related fact models are at least partially ordered.

    fact model includes description

    Note: This fact type enables the annotation of fact models and conceptual schemas.

    thing has URI

    Note: This fact type enables modeled things to be identified globally for future reference.

    I am requesting that these concepts, or some refinement of them, be included in the next release of SBVR.

  • Reported: SBVR 1.0 — Wed, 10 Dec 2008 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

"thing has property".

  • Key: SBVR15-16
  • Legacy Issue Number: 16727
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    (a) Clause 11 should include the verb concept "thing has property". This verb concept should appear in figure 11.5.

    (b) Property needs to be indicated as an abstract concept in Clause 13 (since it is in the universe of discourse, not the model).

  • Reported: SBVR 1.1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Add Verb Concept ‘thing has property’

    Include a Note (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

qualifiers whose subject is a property of the referent

  • Key: SBVR15-15
  • Legacy Issue Number: 19728
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The title of this issue is an example of common problem in SBVR Structured English.

    Impossibility: An SBVR SE statement contains a qualifier whose subject is a property of the referent.

    Given the verb concept 'sequence has member' aka 'thing is member of sequence', how is the following definition to be written in SBVR SE: "sequence each member of which is a time point"?

    The referent of the pronoun 'which' is the sequence, but the subject of the qualifier clause is a quantified property of the referent. But SBVR SE only permits the (anaphor) pronoun to be 'that' or 'who' and apparently requires it to follow the referent noun immediately.

    SBVR SE does not permit: "sequence of which each member is a time point".

    And it does not provide a 'where' or 'such that' construct that would allow the back reference to be represented by 'the sequence', as in: "sequence where each member of the sequence is a time point".

    Even the simpler case of a reference to a unique property of the referent in the qualifier clause --"shipment whose delivery date has passed" – requires a circumlocution ("shipment that has a delivery date that has passed"), because 'whose' is not an SBVR SE keyword. And the cascading 'that's interfere with the expression of compound qualifiers (using 'and that …').

    In our experience, this shortcoming significantly limits the clear expression of definitions and rules in SBVR SE.

  • Reported: SBVR 1.1 — Sat, 21 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

'closed semantic formulation' is not properly defined

  • Key: SBVR15-13
  • Legacy Issue Number: 19713
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR Clause 9.2 defines: ‘semantic formulation’ as ‘a conceptual structure of meaning’.

    And then closed semantic formulation is defined as 'semantic formulation that includes no variable without binding'

    But no SBVR concept associates semantic formulation (in general) with variables. And some other conceptual structure of meaning, e.g., phrased in SBVR structured English or OWL, might not have any notion of ‘variable’ or ‘binding’ at all. So the definition appeals to a delimiting characteristic that may be meaningless for the general concept, and thereby admit semantic formulations that were not intended.

    Every structure of meaning presumably formulates a meaning; otherwise it formulates nonsense. But clause 9.2 has only ‘closed semantic formulation formulates meaning’, which suggests that open semantic formulations (involving free variables) formulate nonsense. That is simply not true of a ‘structure of meaning’ formulated in CLIF. What is really meant is that LRMV ‘closed logical formulations’ formulate propositions, and LRMV ‘closed projections’ formulate concepts. But those are special cases.

    The definition of ‘closed semantic formulation’ should be ‘closed logical formulation or closed projection’, which makes it clearly an LRMV concept, and then those concepts must state their relationship to free variables.

    The general idea for all conceptual structures of meaning is ‘semantic formulation formulates meaning’, which would allow other semantic formulations, e.g., in SBVR SE, OWL, etc., to be related to the meanings they formulate. If an LRMV projection or logical formulation that is not closed does not formulate a meaning, that is a LRMV Necessity for those specific concepts.

    Finally, note that a (clause 8) Definition is always a representation of a conceptual structure of meaning that formulates a concept. The important idea in ‘definition serves as designation’ in clause 11.2.3 is that the representation of a semantic formulation (a conceptual structure of meaning) is used to refer to the concept itself, rather than just the properties contained in the formulation. This idea of semantic formulation as conceptual structure of meaning is fundamental to the notion ‘definition’, and should not be buried in the LRMV.

  • Reported: SBVR 1.1 — Wed, 21 Jan 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

'another' unnecessarily restricts the concept 'other'

  • Key: SBVR15-9
  • Legacy Issue Number: 19727
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause A.2.2, the keyword 'another' is introduced, with the interpretation:

    (used with a term that has been previously used in the same statement) existential quantification plus a condition that the referent thing is not the same thing as the referent of the previous use of the term

    The idea "existential quantification plus" is an unnecessary and undesirable addition. The useful keyword is 'other'. As described, "other X" means "instance of the general concept X that is not the same thing as the referent of the previous occurrence of the term X". But "another" is just a conventional spelling of "an other", and might equally have been spelled "some other". The term 'other' can be usefully quantified by quantifiers other than "an". Each other, at least n other, at most n other, exactly n other, and no other are all valid uses of 'other' with the given interpretation, less the "existential quantification plus".

    Defining only the portmanteau keyword 'another' greatly and unnecessarily limits the expressiveness of SBVR Structured English in this area.

  • Reported: SBVR 1.1 — Sat, 21 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

How can an attributive role be declared?

  • Key: SBVR15-7
  • Legacy Issue Number: 17791
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR v1.1 Clause 8 says:
    Note: in the glossary entries below, the words “Concept Type: role” indicate that a general concept being defined is a role.
    Because it is a general concept, it is necessarily a situational role and is not a verb concept role.

    How does one declare an attributive role that is not a general concept?

    SBVR v1.1 appears to use such declarations to also declare roles that are attributive roles of a given noun concept and thus also in the attributive namespace of the noun concept. For example, clause 8.6 declares 'cardinality', which is an attributive role of integers with respect to 'sets', in a glossary entry with Concept type: role. But 'cardinality' is not a general concept; nothing is a 'cardinality', full stop. An integer can only be a 'cardinality' OF something. it is a purely attributive term. As a term for a general concept, 'cardinality' is thus a term in the Meaning and Representation namespace; it has no 'context'.

    The problem arises in defining attributive roles of general noun concepts, such as 'occurrence has time span' and 'schedule has time span', where the definitions of the two roles are importantly different because they are attributes of different general concepts that are only similar in nature. Neither is a situational role. That is, neither is a general concept. No time interval is a 'time span', full stop. A time interval must be a time span OF something. One 'time span' is in the attributive namespace of 'schedule', and a different 'time span' designation is in the attributive namespace of 'occurrence'. Neither is in the DTV.Situations vocabulary namespace per se. How can this be declared using SBVR conventions? Declaring them both in glossary entries with Concept Type: role apparently makes them conflicting designations for 'situational roles' in the DTV.Situations vocabulary.

    Does simply declaring the verb concept 'occurrence has time span' declare the attributive role? If so, how is the range of the role declared? And where does the definition of the attributive role go?

  • Reported: SBVR 1.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

The notion of “well-formedness” in compliance point 1 should be defined

  • Key: SBVR15-6
  • Legacy Issue Number: 19675
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notion of “well-formedness” in compliance point 1 should be defined

  • Reported: SBVR 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

styling of signifiers

  • Key: SBVR15-4
  • Legacy Issue Number: 18378
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Title: SBVR needs a consistently applied policy for styling or not styling signifiers
    Source:
    John Hall, RuleML Initiative
    john.hall@modelsystems.co.uk
    Summary:
    There is some inconsistency in the SBVR specification regarding which signifiers are styled and which are not.
    A policy needs to be agreed and applied consistently through the SBVR specification.
    Resolution:
    1. Style each use of the signifier of a concept (e.g. ‘thing’, ‘meaning’) where that use has the specific meaning defined in its SBVR entry;
    2. If the signifier of a defined concept has an everyday English meaning that is different from its SBVR definition, don’t style uses of it where the everyday meaning is intended;
    3. Add a paragraph to the introduction explaining the basis for styling/not styling.

  • Reported: SBVR 1.1 — Fri, 18 Jan 2013 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Definition of "categorization scheme contains category"

  • Key: SBVR15-28
  • Legacy Issue Number: 19631
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The current definition of "categorization scheme contains category" is poorly constructed and therefore hard to understand.

    Current Definition: the category is included in the categorization scheme as one of the categories divided into by the scheme

    Perhaps the definition means the following?

    Possible Revision: the category is included in the categorization scheme as one of the categories into which the scheme divides things

    I think a better definition would perhaps include the verb concept " ... classifies ... ".

  • Reported: SBVR 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Current definition of "categorization scheme contains category" is poorly constructed and therefore hard to understand

    Change the definition of "categorization scheme contains category" (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR issue: Can there be multiple instances of a thing?

  • Key: SBVR15-3
  • Legacy Issue Number: 16314
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR defines the concept "thing" in clause 8.7. The
    definition is unclear as to whether the extension of "thing" contains only
    singletons (i.e. individual things) or can contain instances that recur in
    some way.

    Proposed Resolution: Add a Necessity or Possibility or Note that explains
    whether individual things can recur. Add examples.

  • Reported: SBVR 1.0 — Mon, 6 Jun 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Misleading text in A.4.2.3

  • Key: SBVR15-2
  • Legacy Issue Number: 19522
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The first statement in Annex A.4.2.3 is misleading:

    A definition given for a verb concept is an expression that can be substituted for a simple statement expressed using a verb

    concept wording of the verb concept.

    Unlike a noun concept definition, the definition of a verb concept cannot simply be substituted for an occurrence of the verb concept wording. Like the verb concept wording itself, it is a structured pattern with placeholder parameters, and the substitution process is complex. In “substituting the definition expression for a simple statement expressed using the verb concept wording”, it is also necessary to substitute the role phrases that are used in the verb concept wording in that simple statement for the corresponding placeholders in the definition. That is significantly different from what happens in the noun concept case.

    In the same subclause, the sentence:

    “A definition of a verb concept can generally be read using the pattern below ...
    A fact that ... is a fact that ...”

    is not quite general enough. The definition characterizes the same state of affairs, even when it is not a fact. It could be written:

    A state of affairs in which ... is a state of affairs in which ...

  • Reported: SBVR 1.1 — Mon, 14 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Noun form designates two different concepts

  • Key: SBVR15-1
  • Legacy Issue Number: 17532
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 8.3.4, the term 'verb concept wording' is defined as:
    "representation of a verb concept by an expression that has a syntactic structure involving a signifier for the verb concept and signifiers for its verb concept roles"

    In the same clause, the term 'noun form' is defined as:
    "verb concept wording that acts as a noun rather than forming a proposition"

    One would expect therefore, that a noun form of a verb concept would be a gerund, such as 'car transfer' for 'branch1 transfers car to branch2', where the 'noun form' denotes the same actualities as the verb concept.

    But only the last Example (which is hard to understand because of a particularly bad choice of verb) is said to be about gerunds. The other examples clearly are not. The first Example is: "'transferred car of car transfer' for the verb concept 'car transfer has transferred car'. This form yields a transferred car."

    The instances of 'car transfer has transferred car' are actualities of a car being involved in a car transfer. But the cited text says the instances of the 'noun form' 'transferred car of car transfer' are cars, not actualities. Similarly, the interpretation of the other two examples of 'noun forms' correspond to numbers, not actualities.

    So the instances of a noun form of a verb concept need not be instances of the verb concept! The noun form therefore cannot be a 'verb concept wording'. The noun form does not represent the verb concept!

    It appears that there are two different concepts here. Noun form 1 is "verb concept wording that acts as a noun." That is the gerund in the last Example. In the other examples, the noun form represents a derived concept that is what SBVR calls a 'situational role'. The intent of 'noun form 2' is "representation of a situational role by an expression that has a syntactic structure involving a signifier for the verb concept that the role is derived from and signifiers for some of its verb concept roles".

    Finally, use of noun form 2 in declaring a glossary item for a situational role would be preferable to using only the role designation. In particular, the explicit appearance of other role placeholders in the noun form would permit them to be used directly in defining the situational role.

    For example:
    cardinality
    Definition: nonnegative integer that is the number of distinct elements in a given set or collection

    could be declared with the noun form:
    cardinality of set
    Definition: nonnegative integer that is the number of distinct elements in the set

  • Reported: SBVR 1.1 — Fri, 27 Jul 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Move 'rulebook' to Clause 12

  • Key: SBVR15-45
  • Legacy Issue Number: 16062
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Clause 11 includes an entry for 'rulebook' (specifically, in 11.2.2.4). To maintain the separation of vocabulary-related items from rule/governance-related items (which has been the convention for Clauses 11 and 12), this should appear in Clause 12 rather than Clause 11.

    Resolution: Move 'rulebook' to Clause 12.

    [issue requested in the telcon of Mar. 18 2011]

  • Reported: SBVR 1.0 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Closed; No Change — SBVR 1.5
  • Disposition Summary:

    Move 'rulebook' to Clause 12

    This was taken care of in the major restructuring of the SBVR document in v1.3 (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR Issue: Use of 'Partitioning' in the Definition of Categorization Scheme

  • Key: SBVR15-66
  • Legacy Issue Number: 19567
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:
    • "Partitioning" is a defined term in SBVR. It is a synonym of Segmentation.
    • "Segmentation" is a category of Categorization Scheme. Segmentation has a very particular, more restrictive meaning than Categorization Scheme: "categorization scheme whose contained categories are complete (total) and disjoint with respect to the general concept that has the categorization scheme ".
    • Yet the word "partitioning" is used in the definition of Categorization Scheme: "scheme for partitioning things in the extension of a given general concept into the extensions of categories of that general concept ". That could be very confusing (even though not stylized ... and shouldn't be). It potentially suggests constraints that are not meant.

    Resolution:
    Substitute the word "allocating" for "partitioning" in the definition of Categorization Scheme.

  • Reported: SBVR 1.1 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Confusing Use of 'Partitioning' in the Definition of Categorization Scheme

    Substitute the word "allocating" for "partitioning" in the definition of 'categorization scheme'. (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

SBVR 1.2 - Error in Annex E figure (p. 6)

  • Key: SBVR15-63
  • Legacy Issue Number: 19242
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    The figure on p. 6 of Annex E (SBVR 1.2) contains an error (use of 'fact type'). Ref. leftmost box in the screenshot below.

    If you can supply the image source I will make the correction

  • Reported: SBVR 1.1 — Sat, 15 Feb 2014 05:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Use of obselete signifier "fact type" Error in Annex E figure (p. 6)

    Correct the figure to remove the use of 'Fact Types'. (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Definition of "representation uses vocabulary" (Clause 11

  • Key: SBVR15-61
  • Legacy Issue Number: 17441
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Problem: The current definition of "representation uses vocabulary" is "the representation is expressed in terms of the vocabulary". I think the un-styled "term" (in terms of) is a bad choice for the definition. A better choice might be based on.

    Resolution:

    Change the definition of "representation uses vocabulary" to: "the representation is expressed based on the vocabulary".

  • Reported: SBVR 1.1 — Fri, 15 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Definition of ‘representation uses vocabulary’ Confusing

    Change the definition of "representation uses vocabulary" (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Definition of Practicable re Concepts

  • Key: SBVR15-83
  • Legacy Issue Number: 19896
  • Status: closed  
  • Source: NIST ( Ron S. Ross, Ph.D.)
  • Summary:

    Discussion: The current definition of "element of guidance is practicable" is the following:

    the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is understood

    It's not "how something is understood". It's "how some concept is understood".

  • Reported: SBVR 1.2 — Tue, 30 Aug 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.5
  • Disposition Summary:

    Definition of Practicable re Concepts Seems to be Incorrect

    "to what things a concept corresponds" was agreed as a better wording than "how something is understood". (see attached Word Document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Correct the scope of placeholder terms

  • Key: SBVR15-24
  • Legacy Issue Number: 18826
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.3.4, in the entry for ‘placeholder’, it is stated that a placeholder exists in only one verb concept wording, and it refers to some role of the verb concept in that wording. It follows that the two placeholders spelled ‘concept1’ in ‘concept1 specializes concept2’ and in the Synonymous form: ‘concept2 generalizes concept1’ (in 8.1.1.1) refer to two roles of the verb concept being defined. Since these two placeholders spelled ‘concept1’ are different designations, how are they related?

    Annex C.3.1 does not say anything about the relationship between placeholders in the primary verb concept wording and placeholders in synonymous forms. (It just says something about subscripts being used to differentiate placeholders.) The intent is that the placeholder expression represents the SAME verb concept role in ALL primary and synonymous forms. That is, the placeholder is the SAME DESIGNATION in all verb concept wordings for the same verb concept. The text of 8.3.4 contradicts this intent, saying that the placeholder only has meaning within a given verb concept wording. If the text is correct, it is necessary to state some rule about the meaning of the same placeholder expression (the distinct designation) in the different synonymous forms.

    Further, in the Definition of ‘concept1 specifies concept2’, the expression ‘concept1’ appears. Since that expression only refers to a verb concept role within a verb concept wording, it is utterly meaningless in the Definition! There are no placeholders in a Definition, and ‘concept1’ is not a signifier for any concept. And yet, the intent is that ‘concept1’ in the Definition is the placeholder expression and is intended to be interpreted as a reference to the thing that plays that verb concept role in an actuality of ‘concept1 specializes concept2’. Annex C says nothing about the use of placeholder expressions in Definitions, and 8.3.4 makes these usages meaningless, but they appear in every verb concept definition in SBVR.

    It appears that the real intent is that a placeholder expression refers to one and the same verb concept role throughout the terminological entry for the verb concept, including at least all synonymous forms and definitions. Whether it also refers to the verb concept role in embedded Necessities needs to be clarified (it is not clear that SBVR ever assumes that, but DTV apparently does). The only aspect of a placeholder that is specific to a given verb concept wording is the ‘starting character position’, which suggests only that that relationship should be ternary, i.e., placeholder has starting character position in verb concept wording.

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: representations of propositions by name

  • Key: SBVR15-43
  • Legacy Issue Number: 19715
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Many business rules, laws of nature, etc., are given ‘names’ that are representations of those rules/laws as ‘individual concepts’.

    For example, “Murphy’s Law” represents the proposition: Anything that can go wrong will. Similarly, “Newton’s First Law of Motion” represents the proposition: A body at rest will stay at rest unless acted on by an outside force. (Laws like “Sarbanes-Oxley” are not just propositions, they are actually bodies of guidance.)

    What is the SBVR relationship between these signifier expressions and the propositions? The expressions are very like designations, there are different expressions in different languages, and a few such ‘laws’ are known by different names in different subject areas. But it does not appear that they can be contained in Vocabularies or terminological dictionaries.

    These representations cannot be ‘designations’. Propositions cannot be (individual) concepts, unless the dichotomy of ‘meaning’ (= concept xor proposition) is not valid. And they are clearly not ‘statements’.

  • Reported: SBVR 1.1 — Mon, 2 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR ISSUE - definite description

  • Key: SBVR15-42
  • Legacy Issue Number: 16527
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Definite descriptions do not always define individual concepts

    The entry for ‘definite description’ in SBVR 11.1.3 includes this structural rule:

    Necessity: Each definite description is the definition of an individual concept.

    The rule is incorrect. A definite description defining a concept in a schema might well be taken as defining an individual concept, but a definite description within a statement of a fact in a model need not define an individual concept because it need not identify the same individual in all possible worlds. It would identify an individual in the world described by the fact. Similarly, a definite description in the context of a rule statement might identify a single individual in each situation addressed by the rule, but not necessarily the same individual in all possible worlds. E.g., “the previous calendar month” definitely describes one month, but which month it describes depends on the current month, which can vary across possible worlds.

    Also, a note should be added to the entry for “definite description” to point out that the one thing defined by a definite description can be a set (e.g., “the cars owned by EU-Rent”, which, by the way, is not the same set in all possible worlds).

  • Reported: SBVR 1.0 — Tue, 6 Sep 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Annex F is in the wrong specification

  • Key: SBVR15-41
  • Legacy Issue Number: 16871
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Date/Time Annex F is titled: Annex F Simplified Syntax for Logical Formulations.

    First, the title is wrong. The Date/Time standard contains logical formulations in OCL and CLIF. This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9. It should be titled: Simplified Syntax for SBVR Logical Formulations.

    Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification. If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it. If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it.
    Recommendation: Delete Annex F and refer to the OMG (SBVR) specification that actually includes it. Otherwise, use a standardized SBVR notation in Annex E.
    The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification – a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification.

  • Reported: SBVR 1.1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Use of morphological variants of terms is inadequately addressed

  • Key: SBVR15-40
  • Legacy Issue Number: 17269
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR apparently assume that business terms are composed of natural language words, and that those words may have multiple morphemes that are nonetheless the same word and the same term. That is, a vocabulary term like 'purchase contract' may also have the form 'purchase contracts', and a vocabulary term like 'is owned by' may be expressed as 'has been owned by'. But SBVR says nothing about any of this in defining 'designation' or 'signifier'.
    When a signifier for the same concept is in a formal language like OWL or CLIF, this idea of multiple morphemes is not (usually) part of the language syntax. So this should be carefully addressed.

    For the SBVR Structured English language, Annex C.1 explicitly says that these alternate morphemes are "implicitly available for use", which may mean they are treated as equivalent, or just that they are recognized as uses of the same designation.

    In natural language, such morphemes carry additional meaning , e.g., plurality or tense or mood. And a morphological variant of the same designation may or may not carry additional meaning, This is important, because SBVR examples assume that plurals are conventional and irrelevant, but the Date Time Vocabulary says that the use of verb tenses in natural language conveys indexical time intent. That is:
    'John is in London' and 'John was in London' have different meanings in English. Do they have different meanings in SBVR SE?
    And if so, do they always have different meanings? Natural language convention requires that a statement that dates a past event uses the past tense, e.g., 'John was in London in 2008.' Is it meaningful in SBVR SE to say (in 2012) 'John is in London in 2008'? And does that mean a different proposition from 'John was in London in 2008'?

  • Reported: SBVR 1.1 — Fri, 23 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Inadequate, Overlapping and Disorganized Specs for Sets and Collections of Concepts, Meanings, and Representations

  • Key: SBVR15-39
  • Legacy Issue Number: 17542
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Inadequate, Overlapping and Disorganized Specifications for Sets and Collections of Concepts, Meanings, and Representations

    Problem:

    Assumptions

    Two assumptions are basic to the eight points of this problem statement:
    • SBVR must provide a business vocabulary for business people and business analysts to talk clearly and precisely about terminological dictionaries and rulebooks and what they represent.
    • The various aspects of this Issue must be addressed holistically. They can be resolved only by unifying, normalizing and completing all related specifications. (Thus, the need for a new unifying Issue.)

    Problems

    1. A known problem in SBVR is that the current version does not make clear what the fundamental unit of interoperability in SBVR is. No matter how that issue is resolved the unit should:
    • Be identifiable from a business point of view.
    • Not always have to be the full, non-redundant set of concepts, meanings, or representations.
    The existing content of Clause 11 does not currently provide an adequate term for the second of these. This Issue proposes “collection” for that purpose.

    Note: The term “collection” in the following discussion is never actually used on its own. Rather, it always appears with qualification – e.g., ‘collection of representations’.

    2. Another known problem in SBVR centers on the use of the word “container” in e-mails and discussion. (Use of the signifier “container” per se is not part of this Issue.) It is unclear (to some) whether “container” refers to the ‘thing that contains’, to ‘what is contained’, or to both. The term is easily misused and misinterpreted. Also there are many variations of what is (or could be) contained (e.g., sets, collections, etc.). SBVR needs a precise, non-overlapping vocabulary for these things from a business point of view.

    3. Another known problem in SBVR is that the existing content of Clause 11.2.2.3 “communication content” (a.k.a. “document content”) is not adequate for all purposes to which it might be put. SBVR needs a richer (but still minimal) set of concepts to address this area.

    4. Certain existing terms in the existing content of Clause 11 (e.g., ‘terminological dictionary’ and ‘rulebook’) conflate ‘completeness and non-redundancy’ (i.e., being a set) with ‘primary purpose’ or ‘essence’. This conflation needs to be eliminated. In the real world for example, a rulebook does not have to be complete (e.g., it may contain only what is appropriate for a given audience), and it does not have to be non-redundant. It can contain the same rule statements in different sections, the intent being to provide the greatest clarity when being used by members of some speech community.

    5. SBVR currently provides no means to talk about a collection of representations that is complete with respect to one or more specific concepts, but not complete with respect to all concepts in the body of shared meanings. Example: A listing of all baseball rules that address the concepts “strike” and “ball” only.

    6. With respect to interoperability there is a minimum set of pragmatic business specifications (such as completeness, effective date, shelf life, mutability, etc.) needed for things communicated. SBVR does not currently support such specifications.

    Note: There is no intent or need to get into document management or rule management. The dividing line is this: SBVR does not get into organizational issues (e.g., author, sponsor, reviewer, etc.), workflow issues (e.g., status, pre-approval distribution, sign-off, impact assessment, etc.), motivation (rationale, goals, risks), etc. SBVR must, however, provide minimum viability criteria for any sets or collections communicated. Otherwise the communicated content is not really useful and trustworthy on the receiving end. Consequently the purpose of interoperability is defeated.

    7. Certain kinds of collections relevant to inter-operability are missing from the current content of Clause 11 – most notably ‘record’ (not IT ‘records’). Proper incorporation of this and other kinds of collections is needed.

    8. Issue 16103, which addresses “speech community representation”, needs to be worked into a holistic solution.

  • Reported: SBVR 1.1 — Tue, 7 Aug 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Precedence of operators

  • Key: SBVR15-36
  • Legacy Issue Number: 17243
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    The precedence of logical operators ("and", "or", etc.) in Structure English is unspecified which may make some rules ambiguous. Furthermore, they sould be called "operators" and not "operations".

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Fix the objectification example

  • Key: SBVR15-34
  • Legacy Issue Number: 18703
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The objectification example “EU-Rent reviews each corporate account at EU-Rent Headquarters” in SBVR v1.1 clause 9.2.7 (as modified per the resolution to issue 16309), is expressed in the usual sequence of sentences. The formal logic interpretation of those sentences is:
    For each corporate account A, there exists a state of affairs S such that

    S objectifies “EU-Rent reviews A”,

    and S occurs at EU Rent HQ.

    Now, per Clause 8 there is only one such state of affairs; and its existence is a given, that is, for every proposition of the form ‘company reviews account’, the corresponding state of affairs necessarily exists. But nothing is said here about that state of affairs being actual. Moreover, since there is probably more than one “occurrence” of that state of affairs, the definition of ‘state of affairs occurs at place’ would be less than obvious. Or is it the intent that there is only one review of each corporate account? Whatever it means for an abstract state of affairs (that might be a set, including the empty set) to ‘occur at a place’, it is not clear, and it is important to the example of objectification – what is the state of affairs that it produces.

    In SBVR v1.0, the variable S ranges over the verb concept ‘company reviews account’, because the instances of the verb concept were then said to be actualities. The resolution of Issue 14849 makes instances of a verb concept ‘states of affairs’ instead of actualities. But states of affairs need not be actual. It is obvious that some thought was given to this example, because v1.1 changed it. What is not clear is whether it is any closer to what was intended.

    A definition of ‘state of affairs occurs at place’ should probably follow the DTV pattern for ‘state of affairs occurs at time’. In DTV parlance, what was intended is: Each occurrence of the state of affairs “EU Rent reviews A” ‘occurs at’ EU Rent HQ. But SBVR lacks the vocabulary to express that.

  • Reported: SBVR 1.1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition

  • Key: SBVR15-33
  • Legacy Issue Number: 14029
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    There two closely related flaws in SBVR Clause 8.1:
    1. a conflation of 'proposition' with "'performative' + 'proposition'"
    2. a disconnect between 'concept' and its subcategories and 'proposition' and its subcategories which are really one concept or two perspectives on the same thing.

    Conflation of 'Proposition' with "'Performative' + 'Proposition'"

    • 'proposition' meaning that is true or false (the "semantic content"
      part in 'proposition' + performative')
    • 'proposition' + 'performative' (where the 'performative' part is the
      "communicative function") e.g.:

    o proposition + "deontic" performative = behavioral guidance
    o proposition + "alethic" performative = definitional rule
    o proposition + "taken to be true" performative = fact

    The core meanings are in the propositions which are then made into something else by combination with a particular performative. This is why there is no reason to include the concept 'fact' at all in Clauses 8, 9 11 or 12 except to support the formulation of fact statements – which are really out of scope for a standard for "concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definiton-centric dictionaries". Examples of general concepts can be provided by using names and fact type forms of individual concepts without needing to turn the individual concepts into facts (by adding the performative "taken to be true") so that fact statements can be used as examples.

    Disconnect between 'Concept' and its Subcategories and 'Proposition' and its Subcategories

    Clause 8.1 defines two concepts ('concept' and 'proposition') as if they were completely separate things when in fact they are at most two perspectives on the same thing:

    · general noun concept = open (existential) proposition
    · individual noun concept = closed (existential) proposition
    · general verb concept = open (relational) proposition
    · individual verb concept = closed (relational) proposition
    (this is the verb concept that corresponds to a given state of affairs)

    Resolution:
    Remove the Conflation of 'Proposition' with "'Performative' + 'Proposition'"
    1. Add the concept (definition) for "performative" and term it "communicative function" [3.7] as per ISO/CD 24617-2 "Language resource management – Semantic annotation framework (SemAF) – Part 2: Dialogue acts".
    2. Add the three performative (communicative function) individual concepts used in SBVR: "taken to be true", "true by definition", and behavioral guidance.
    3. Add the concept (definition) for "performative' + proposition" and term it "dialogue act" [3.2], as per ISO/CD 24617-2.
    4. Show fact, behavioral guidance, and definitional guidance as concept type dialogue act with their respective performative (communicative function) instances instead of their current definition as subcategories of proposition.
    5. Review all references to 'proposition' to determine whether the intended reference is to semantic content or to a discourse act (proposition + performative); e. g. statement expresses dialogue act (not proposition).
    Remove the Disconnect between 'Concept' and its Subcategories and 'Proposition' and its Subcategories
    1. Add open/closed proposition categories, and existential/relational proposition categories.
    2. Fix the subcategories of concept to fit the above, and have both 'concept' and 'proposition' as more general concepts for the subcategories.
    3. Replace all current uses of 'individual concept' to 'individual noun concept'.

    Revised Text:
    …to follow, including redrawn diagram(s)

  • Reported: SBVR 1.0 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: Mis-use of Date-Time Concepts

  • Key: SBVR15-32
  • Legacy Issue Number: 19015
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR 1.2 beta annex G (EU Rent Example) adopts concepts from the Date-Time Vocabulary (DTV) but deliberately gives them names that are both inconsistent with DTV and in fact are confusingly similar to the names of other concepts that are defined in DTV. Although any business can use any vocabulary terms desired, an OMG standard should maintain consistency with other OMG vocabularies for reasons of quality and to avoid user confusion. Especially a portion of a standard that is specifically intended to "to provide an aid to help them understand the specification " (annex G.2).

    The Annex is also inconsistent in its own terminology with respect to dates and times. For example, "maximum rental period" (Annex G.6.6) is a kind of "duration" even though G.8.6 defines "period" as a kind of "time interval" and a "rental period" (G.6.8.3) is a kind of "period".

    This annex also defines its own concepts that relate states of affairs to time, and for quantities – rather than using the corresponding concepts defined by the Date-Time Vocabulary. It fails to give definitions for these concepts, which means they are subject to varying interpretations. The example would be stronger if it used the carefully worked-out concepts defined in the Date-Time Vocabulary.

    Specifically:

    • Annex G.8.4 specifies, but does not define, concepts such as "state of affairs at point in time". 'Point in time' is a synonym for Date-Time's 'time point', which is a time interval that is a single member of a time scale. The authors of this Annex apparently did not understand that the duration of a time point depends upon the granularity of the time scale that is used. Consider a time scale of years. What does it mean to say that a "state of affairs at [a year]? Is the state of affairs "at" throughout the year or just during some portion of the year. The Annex G concept is fundamentally ambiguous.
    • Annex G.8.5 defines concepts such as "period", "period1 overlaps period2", and many others, using the definitions from Date-Time's "time interval", "time interval1 overlaps time interval2", etc., but with its own terms. This is particularly confusing because Date-Time has other concepts with similar names, such as "time period". (I do not object to terms that are clearly business specific, such as "rental period".) Moreover, the Annex probably should be built on the DTV "time period" concept, rather than "time interval". The discussion of the "Rental Time Unit" makes it clear that EU-Rent is interested in periods that are based on calendars (i.e. DTV "time period") rather than arbitrary periods ("time interval"). Probably the authors of the Annex did not understand the difference.
    • Annex G.8.5 defines a concept "date-time1 is before date-time2" that is unnecessary in light of the fact that a "date-time" is a kind of "time coordinate", which is a representation of a "time interval". The existing "time interval1 precedes time interval2" is applicable to all time coordinates, in the same way that representations of quantities (e.g. "5") may be used in instance of the verb concept "quantity1 is less than quantity2".
    • Annex G.8.5 misquotes some definitions from the Date-Time Vocabulary. For example, the definition of "current day" is misquoted.
    • The concept "date time" is defined twice: in G8.5 and in G.8.9.5. Another concept "date-time" has almost the same spelling, but has a different definition – another likely source of user confusion. Plus the definition does not make sense.
    • The Annex mixes two distinct types of concepts: "time intervals" (spans of time) and "time coordinates" (representations of time intervals). It should use one or the other throughout. The confusion is particularly obvious in places like the definition of "rental is late", which talks about the "end date-time" of a "grace period".
  • Reported: SBVR 1.1 — Sat, 12 Oct 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

extending an adopted concept

  • Key: SBVR15-31
  • Legacy Issue Number: 19433
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In the SBVR Meaning and Representation Vocabulary, the entries for ‘noun concept’ and ‘verb concept’ contain reference schemes that refer to the concept ‘closed projection’ and related fact types that do not appear in the MRV itself. In the MRV per se, these are undefined terms. I am told, but do not find in SBVR v1.2, that if only the MRV is implemented, such Reference Schemes are ignored, while clause 13.4.2 explicitly says that the UML/MOF classes must have the corresponding properties. If properly documented, this approach may be fine for the specification of SBVR itself. In general, however, this approach assumes that the speech community that develops a formal vocabulary is omniscient about reference schemes used by speech communities who ADOPT the original vocabulary. In general, an adopting community might add new fact types about an adopted concept that result in new reference schemes for the concept. Also, the adopting community might add new synonyms or synonymous forms for an adopted concept. There is no reason to suppose that the original speech community is even aware of the adoption, and there is no way these additional elements can have been present in the original terminological entry. So, the approach used in SBVR itself is unworkable for general use.

    When a concept is adopted by another vocabulary, it should be expressly possible for the “adopting entry” to include new reference schemes and synonymous forms, and possibly other elements of a terminological entry.

    Further, if such a mechanism is introduced, the SBVR vocabularies themselves should use it, rather than incorporating reference schemes in the base terminology entry that refer to fact types that don’t exist in that vocabulary per se. For example, the LRMV should formally adopt the MRV concepts and add the reference schemes involving closed projections in the ADOPTING ‘noun concept’ and ‘verb concept’ entries.

  • Reported: SBVR 1.1 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Issue "fact type role is in fact type"

  • Key: SBVR15-27
  • Legacy Issue Number: 12437
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 8.1.1.1, we have "fact type has role", with a synonymous form
    "fact type role is in fact type". Figure 8.2 also shows "fact type role
    is in fact type".

    Issue: a "fact type role" is a specialization of "role", so it is confusing
    to see the preferred form of the fact type use "role" but the synonymous
    form use "fact type role". Especially because figure 8.2 seems to indicate
    that a "fact type role" is in a fact type but that a "role" is explicitly
    not in a fact type. So the figure appears to contradict "fact type has
    role".

    Recommendation: I think the preferred entry is wrong, and should be changed
    to "fact type has fact type role".

  • Reported: SBVR 1.0 — Mon, 12 May 2008 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

'categorization scheme' and 'categorization type' are related

  • Key: SBVR15-25
  • Legacy Issue Number: 19549
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    'categorization scheme' and 'categorization type' are related, yet SBVR says nothing about this relationship.

    Upon comparing the entries for these terms in 11.2.2.3, it is seen they are coextensive; the extension of each is a set of concepts; they could be defined having the same extensions. Compare the examples in each entry.

    A difference is that categorization schemes are restricted to categorizing general concepts, whereas categorizations types are not so restricted.

    Another difference is that categorization schemes define partitionings, whereas categorization type are not so restricted.

    Accordingly, it seems like the definition should be:
    categorization scheme: categorization type that defines a partitioning of one or more general concepts.

    'categorization type' is defined in such a way that it is not meaningfully different from 'concept type' (p.22); compare the definitions on p.22 with that on p.149. A concept, by its very nature and definition, defines a category of things. See 'concept', p.21. 'categorization type' should be made a synonym of 'concept type'.

    'Categorization scheme' is involved in the verb concept 'categorization scheme is for general concept'. The general concept(s) are inferred by the general concepts of the concepts in a categorization scheme or a categorization type coextensive with the it. This verb concept is not necessary.

    'Categorization scheme' is involved in verb concept 'categorization scheme contains category'. Either can be defined to have the same extension, by an extensive definition. This verb concept is not necessary.

    The two verb concepts mentioned above are redundant; their purpose is more simply served by providing extensional definitions of categorization types and categorization schemes, as suggested by the examples. They could be deprecated or deleted, as they do not add any new information to a model. They increase the complexity and maintenance burden on the model.

    The changes suggested here would affect Figure 11.2 on p.146.

  • Reported: SBVR 1.2 — Sun, 27 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

No way to adopt a concept or a glossary item

  • Key: SBVR15-59
  • Legacy Issue Number: 19543
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR provides for a speech community to adopt a definition, or an element of guidance, but no clear way for a vocabulary to adopt a term and its definition from another vocabulary. The Date Time Vocabulary (clause 4) formally adopts a set of terms from the SBVR specification with the intent that the term means the definition given in SBVR and has whatever other associations that term may have to other adopted SBVR terms. (This is the usual practice for adopted terminology in an ISO standard.) But SBVR does not provide a formal expression for this. Instead, it appears that DTV must introduce all the required SBVR terms and their definitions and then cite SBVR as the Source of the definitions. (This is a practice ISO recommends against, because of the problem of synchronization of changes.) We believe that this is a shortcoming in SBVR.

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Vocabularies Relationship to SBVR Subclause 10.1.1

  • Key: SBVR15-58
  • Legacy Issue Number: 16684
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
    The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined.
    The underlying issue is:
    1. SBVR’s metamodel is defined in Clauses 8, 9, 10, 12 and 13. Its instances (domain models) are linguistic models of meanings.
    2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR’s metamodel. Its instances (domain models) are fact models.
    The proposed resolution is:
    1. State, in introductory text in Clauses 8 and 10, that the models are different
    2. Somewhere in Clause 10:
    a. List the major differences between the two models
    b. Describe informally what transformation would be needed to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification

    Resolution:
    1. Add a subclause to Subclause 10.1.1 to discuss to an appropriate level of detail all aspects of the relationship between the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 and the formal interpretation in Subclause 10.1.1, as well as removing ambiguity from Clause 10.1.1 by consistent use of terms intension, extension, fact population, and the set of all possible facts..

  • Reported: SBVR 1.1 — Fri, 4 Nov 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Concept System

  • Key: SBVR15-57
  • Legacy Issue Number: 19541
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Rectifying the Relationship Between SBVR and ISO 1087 Terms "Concept System" and "Relation"

    SBVR uses two terms "concept system" and "relation" found in ISO 1087 but extends these notions in important ways. Specifically, SBVR supports more "elements of concept system structure" than ISO 1087 does – especially, but not exclusively, associations (verb concepts). ISO 1087 defines only some kinds of relation, such as 'generic relation', 'partitive relation', 'hierarchical relation'. Use of the terms "concept system" and "relation" in SBVR should be rectified.

    1. "Concept System" appears in several places in SBVR, as follows:

    • In the definition of Characteristic Type (p. 147)
    • In the name and definition of "Elements of Concept System Structure" (p. 154)
    • In text (p. 190 and p. 195)
      However, "concept system" is not defined in SBVR.

    2. "Relation" (in the ISO sense roughly meaning 'connection') appears in several places in SBVR, as follows:

    • In the definition of Body of Shared Meaning (p. 142) and in a note for that entry.
    • in the definition of Category (p. 148) Note: Its use here may not be inconsistent with ISO.
    • In the definition of More General Concept (p. 148) Note: Its use here may not be inconsistent with ISO.

    RESOLUTION

    1. "Concept System" is a synonym in SBVR for "Body of Shared Concepts" and should be explicitly treated as such.
    2. "Concept System" should be indicated as the preferred term for the concept "Body of Shared Concepts". ("Body of Shared Concepts" is awkward and not memorable.)
    3. A Note should be added to the entry for "Body of Shared Concepts" indicating ISO 1087 as the source for the term "concept system". Note: The ISO definition should not be indicated as the Basis for the entry since the ISO meaning is much more restricted.
    4. Replace "relation" with "connection" in the definition of Body of Shared Meaning (p. 142) and in a note for that entry.
    5. Replace "relation" with "connection" in the definitions of Category (p. 148) and More General Concept (p. 148).

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Existential and Elementary

  • Key: SBVR15-56
  • Legacy Issue Number: 15157
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Describing the facts of a fact model, SBVR’s clause 10 says, “Population facts are restricted to elementary and existential facts.”

    This “restriction” appears to be a restriction on the clause 10 mapping to a relational database, requiring a sort of normalization. It is certainly not a restriction discernable from SBVR’s definition of “fact model”. Nor is it a restriction on formal interpretation of fact models for knowledge bases in general. Facts that do not fall into those two categories (elementary and existential) can occur in fact models and can be mapped to formal logic. They can be formulated using concepts in a fact model’s conceptual schema, even if they cannot be formulated using those concepts in a way that is considered existential or elementary. Facts can be formulated using disjunction, universal quantification, etc.

    A fact model can have a fact like the following, not as a rule in its schema, but simply as a fact:

    “Every son of Mary has a car and a kayak”.

    Whether this is a “good” fact in terms of being structured according to best practices is not relevant. Once we have a fact model, then we can use tools or guidelines to measure quality and recommend improvements. But that comes after we have fact model to examine.

    Is the fact elementary? Not if it can break into “Every son of Mary has a car” and “Every son of Mary has a kayak”.

    Is it existential? I cannot see it that way.

    But it can map to formal logic, so clause 10 of SBVR should accommodate that mapping. It does not map directly into a relational table, but there is no reason to limit SBVR’s formal underpinnings to relational modeling.

    As it turns out, clause 10 would handle the fact, “Every son of Mary has a car and a kayak”, just fine as long as it is formulated using a unary fact type as would be represented by a unary predicate like this: EverySonOfHasACarAndAKayak(Mary). That sort of contrived fact type is not likely to be found in a conceptual schema made up of meanings of words in a business vocabulary. Requiring a fact model with a business origin to have such a contrived fact type in its conceptual schema is inappropriate for SBVR, even though such contriving is sometimes part of database design. Conceptual schemas based on business vocabularies, rather than database design, involve meanings of words used by business people. Use of such vocabularies starts with an assumption that basic language works (quantifiers, conjunction, disjunction, restriction, demonstration, etc.) for putting words together to make statements. So formulations of facts so stated can tend towards complex formulations involving various sorts of quantifications, objectifications, logical operators, etc. Mapping such fact models into normalized databases is great, but requiring a direct mapping is not and must not be a limitation imposed by SBVR.

    Some confusion is created in clause 10 from using the words “elementary” and “existential” as attributes of facts, when they seem to be attributes of formulations of facts, not of the facts themselves. For example, if the characteristic ‘employee number is assigned’ is define as “there exists an employee that has the employee number”, then by definitional substitution, these are two statements of the very same fact:

    Employee number 777 is assigned.

    There exists an employee that has the employee number 777.

    So we have one fact that appears to be both elementary and existential. The difference is in formulation, not the fact.

    It would be more clear for clause 10 to apply the ideas of “ground”, “elementary” and “existential” to formulation of facts rather than to facts. “Population” in the clause 10 sense seems to be strictly tied to formulation. It gives an example: “pop(Employee drives Car)= set of (employee, car) pairs …”.

    Recommendation:

    Remove the clause 10 general “restriction” to elementary and existential facts. Any such restriction should apply only to the clause’s relational mappings.

    In clause 10, clarify how the concepts of “ground”, “elementary”, “existential” and “population” are tied to formulation.

  • Reported: SBVR 1.0 — Fri, 2 Apr 2010 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1

  • Key: SBVR15-53
  • Legacy Issue Number: 16685
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    OMG Issue No: 16685
    Title: Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1
    Source:
    SBVR Co-chair, Donald Chapin [Donald.Chapin@BusinessSemantics.com]
    Summary:
    Spin-off from Resolution of Issue 15623 (and 14843 which was Merged into it)
    Fix the entries in SBVR Subclause 10.1.2.1 to bring them in line with what Clause 10.1 says as revised by the resolution to Issues 15623 & 14843.

  • Reported: SBVR 1.1 — Mon, 14 Nov 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Annex H recommends faulty UML constructs

  • Key: SBVR15-49
  • Legacy Issue Number: 17241
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Annex H provides detailed guidance on the representation of SBVR vocabulary concepts in UML diagrams. Much of that guidance produces invalid UML constructs per UML 2.4.

    H.1 "If there are additional terms for the concept they can be added within the rectangle, labeled as such – e.g., “also: is-category-of
    fact type” as depicted in Figure H.1." There is no UML syntax for this.

    H.2 "Alternatively, an individual concept can be depicted as an instance of its related general concept (noun concept), as in Figure H.3." The diagram uses an unidentified Dependency, which has no meaning. It should be formally stereotyped.

    H.3.1 shows three representations of the fact type 'semantic community shares understanding of concept'. The third is invalid – an association can have only one name. Also the name of the association is 'shares understanding of'; it does not include the placeholder terms.

    H.3.1 Figure H.4 shows associations that are navigable in both directions, inducing unnamed UML properties on 'semantic community' and 'concept' that are not intended. (This is a vestige of UML v1 ambiguity.) It should show no navigable ends, using UML 2.4 syntax.

    H.3.4 Figure H.9 depicts an invalid relationship symbol; an association is required to have 2 or more roles.

    H.4.2 Figure H.11 shows a stereotype <<is role of>> on a Generalization. I'm not sure this is valid UML, but in any case such a stereotype would have to be defined in a formal Profile. (Semantically, some "roles" are object types that specialize more general concepts, others are association ends (verb concept roles), and others are things in their own right that have the property 'role has occupant'.)

    H.4.3 suggests that there is no consistent mapping for association names. In any case, the UML model of a 'fact type role' is a named association end, regardless of ownership.

    H.6.1 Figure H.14. It is not clear what UML element has the name "Results by Payment type", and the text does not say. It may be a GeneralizationSet.

    H.6.2 Figure H.16. ":modality" appears to be a TagValue associated with some unnamed and undefined Tag, or it may just be another string that names no model element.

    H.8 In, Figure H.17 there is a meaningless dashed line between 'car recovery' and a ternary association (verb concept). It is said to represent 'objectification'. That dashed line should be a Dependency that has a stereotype indicating the nature of that relationship, e.g., <<objectification>>, defined in a Profile.

    H.9 says that the default multiplicity on association ends is 0..*. According to the UML metamodel v2.4, the default multiplicity on a UML association end is 1..1, i.e., exactly one. This makes most of the SBVR UML diagrams implicitly erroneous.

    So Annex H needs to be rewritten, and if it is to include standard stereotypes and tag values, it needs a standard UML Profile that defines them.

    Further, it demonstrates the need for minor repairs to the UML diagrams throughout SBVR, to make them match the MOF model described in Clause 13.

  • Reported: SBVR 1.1 — Thu, 15 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Most or maybe all points are fixed by resolution of SBVR 15-08 - Review in SBVR v1.6

    (see attached Word document)

  • Updated: Tue, 8 Oct 2019 17:48 GMT
  • Attachments:

Notation for the Logical Representation of Meaning

  • Key: SBVR15-47
  • Legacy Issue Number: 19584
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    When DTV v1.0-alpha was adopted, it contained a proposed simplified text representation for SBVR LRMV constructs (as distinct from the long and involved sequences of sentences used in SBVR examples, that make references to undefined concepts like'first variable'). The DTV FTF resolved issues about the disposition of the annex containing this SBVR LRMV notation by improving the description of the notation, but also revising the informative text that used the notation in such a way that the notation is no longer used in DTV. This LRMV notation therefore no longer has a use in DTV and is out of scope for the DTV specification. It is likely that the annex (DTV v1.1 Annex F) will be deleted from DTV v1.2.

    The simplified LRMV notation has value for the wider SBVR community, and its description should be an informative Annex to SBVR. It is within the expertise and purview of the SBVR RTF to address any problems with the notation specification, and to maintain alignment with the SBVR specification generally. Accordingly, the SBVR RTF should maintain the adopted text of DTV Annex F as an Annex to SBVR.

  • Reported: SBVR 1.1 — Wed, 20 Aug 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete

  • Key: SBVR15-50
  • Legacy Issue Number: 16631
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Clause 10 of SBVR provides a formal logic interpretation of SBVR in terms of Object Role Modeling (ORM).

    There has been a long-standing agreement within the OMG community to provide a formal interpretation in terms of Common Logic (CL). CL is an ISO standard (ISO 24707) for which there is an OMG standard metamodel in the Ontology Definition Metamodel (ODM) specification, and which is being used as a basis for logical interpretation in the OMG Date Time vocabulary.

    A partial interpretation of SBVR in CL is given in clause 10.2, but significant work is needed to complete this grounding. Completion is essential to supporting downstream alignment of OMG specifications that are expressed in terms of other logic languages, to reuse of SBVR vocabularies by commercial rule engines, and to facilitate interoperability with other work in the ISO community. It may also be needed to support development of new vocabularies in SBVR, such as potential financial services vocabularies related to the FIBO (Financial Industry Business Ontology) effort in the Finance DTF.

  • Reported: SBVR 1.0 — Wed, 19 Oct 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Additional Improvements to Clause 10

  • Key: SBVR15-74
  • Legacy Issue Number: 11296
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Issue Description:

    1. Spin-off Issue for items not resolved In Issue 9959 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

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

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

no glossary entry for intensional roles

  • Key: SBVR15-73
  • Legacy Issue Number: 19542
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR Clause A.2.6 provides syntax for a concept called ‘intensional role’, but there is no such terminological entry and no clear definition.

    In one of the business usage examples for DTV, we have encountered a usage of ‘time period’ in two intensional roles: ‘fixed period’ and ‘variable period’, but we can’t declare them: Concept type: intensional role.

    As A.2.6 says, intensional roles arise when a concept designation is used with verbs of specification and change, and possibly others. The reference is to an unspecified thing of that will satisfy the concept. When one ‘specifies the rental period for X’, the rental period does not denote any time period. The whole idea is that one associates the concept ‘rental period for X’ with an extension that will only exist when the specifying action completes. Similarly, one cannot ‘change the rental period’, one can only change which time period “the rental period for X” denotes. With these verbs, the “intensional role” is equivalent to an ‘answer’ (at least in structure): one specifies “what time period the rental period is”.

    The same idea seems to apply to a verb like ‘prevents’. If someone “prevents a forest fire”, there is no forest fire that is prevented; rather the concept ‘forest fire’ is not instantiated. But unlike the above, one does not prevent “what forest fire it is.” And if one ‘orders 1000 widgets’, they may or may not already exist so that they can be ordered. What one orders is a characterization of objects that are to be instantiated.

    So, the intensional role seems to be a valuable concept for verb concept wordings, because it has real business use

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Redefinition of "Body of Shared Concepts" (Clause 11)

  • Key: SBVR15-70
  • Legacy Issue Number: 17440
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Problem: If "body of shared concepts" were defined as [the set of] all of the concepts within a body of shared meanings", then I dont think the following entry would be needed: "body of shared concepts includes concept".

    Resolution:

    1. Change the definition of "body of shared concepts" to: the set of all of the concepts within a body of shared meanings"

    2. Eliminate the entry: body of shared concepts includes concept

  • Reported: SBVR 1.1 — Fri, 15 Jun 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Distinguishing between Representation Expressions With and Without Embedded Markup

  • Key: SBVR15-68
  • Legacy Issue Number: 16166
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    SBVR is not clear about how markup should or should not be embedded within
    Representation Expressions.

    The specification needs to be clear about exactly what is included in basic
    Representation Expressions, especially Fact Type Forms, which contain no
    embedded markup. It also needs to be clear about the kinds of markup that
    can be embedded in Representation Expressions and how to communicate which
    markup specification is being used.

  • Reported: SBVR 1.0 — Fri, 6 May 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Clean up and Complete Vocabulary for Clause 10.1.1

  • Key: SBVR15-67
  • Legacy Issue Number: 13139
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    SBVR Issue – Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces)Please see attached Word document for Issue details.

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

    • the proposed resolution of this spin-off Issue which will be posted when it has a number;
    • the proposed resolution to Issue 12540; and
    • the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number.
  • Reported: SBVR 1.0 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR issue - Need verb concept to support "local closure"

  • Key: SBVR15-65
  • Legacy Issue Number: 16610
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Disposition: Resolved
    OMG Issue No: ????
    Title: Need business-oriented verb concepts to support "local closure"
    Source:
    Mark H. Linehan, IBM Research
    Summary:
    Clause 10.1.1.3 has an extensive discussion of "Open/Closed World Semantics". In particular, the penultimate paragraph near the bottom of page 94 of version 1.0 of the specification says:
    "For any given schema, the business might have complete knowledge about some parts and incomplete knowledge about other parts. So in practice, a mixture of open and closed world assumptions may apply. We use the term “local closure” (or “relative closure”) for the application of the closed world assumption to just some parts of the overall schema. One might assume open world semantics by default, and then apply local closure to specific parts as desired; or alternatively, assume closed world semantics by default and then apply “local openness.” We adopt the former approach as it seems more realistic when modeling real business domains."

    In SBVR 1.0, local closure is supported by the verb concepts "fact type is internally closed in conceptual schema" and "concept is closed in conceptual schema" in clause 8.5. The resolution of issue 13138 moves clause 8.5 to clause 10, thus making these verb concepts no longer available in the normative specification or in the clause 15 supporting documents. The result is that the specification no longer supports the semantics mentioned in the quote given above. This issue requests that similar functionality be added to clause 11.

    The original clause 8.5 verb concepts used designations that are not meaningful to business people. The resolution of this issue should adopt business-oriented terminology. Discussions have identified at least four possible approaches:

    1. A verb concept "set is completely known", meaning that the semantic community knows all the elements of the set. This would be particularly useful when applied to a set as the extension of a concept.
    2. A verb concept "concept has completely known extension". Similar to the above, but applying specifically to the extension of concepts.
    3. A verb concept such as "semantic community completely knows concept".
    4. Building on the concept "communication concept" in clause 11.2.2.3 to define closure with respect to an information record.

    Example use cases for local closure include the following:

    Example 1

    This example is about a concept called order that includes a list of line items, where each line item has a quantity, a catalog id, etc. A minimal vocabulary is shown here, just enough to illustrate the example.

    order
    Definition: A customer request for one or more products and a promise to pay the total cost of the order.
    line item
    Definition: Details about an order for a particular product.
    quantity
    Definition: positive integer that is the number of units of the product that is desired by the customer
    catalog id
    Definition: text that identifies the product desired by the customer
    line item has quantity
    Necessity: Each line item has exactly one quantity.
    line item has catalog id
    Necessity: Each line item has exactly one catalog id.
    order includes line item
    Necessity: Each order includes at least one line item.
    "order includes line item" is internally closed in the business xx conceptual schema

    The "internally closed" fact says that the business knows all the line items that are included in each order: there are no other line items. Consider a rule such as "Each order must be shipped within 24 hours if the order does not include a line item that has quantity greater than 100." As described in clause 10.1.1.3, this rule makes no sense with the default SBVR "open world" semantics because under those semantics, the business cannot know that no "line item that has quantity greater than 100".

    Example 2

    Consider a business that has a vocabulary about employees. The business considers it knows all its employees; there are no employees that it does not know.

    employee
    Definition: person that works for the business

    Under SBVR's default open world semantics, the glossary entry given above is insufficient because it does not capture the business sense that it knows all its employees. To accomplish that, the vocabulary needs the following:
    "employee" is closed in the business xx conceptual schema

    Example 3

    Continuing example 2, suppose the business needs concepts relating to employee names and work phone numbers:

    employee name
    Definition: text that identifies an employee
    work phone number
    Definition: number used to phone an employee at work

    The business requires that it knows the employee name of each employee because the government requires this information on tax and employment reports. So the employee name is authoritative.

    The business knows that, in practice, it does not know the work phone number of each employee. These change too often to keep up with.

    SBVR needs verb concepts to express the idea that the employee name is reliably know, but the work phone number is not reliably known.

    Resolution:
    Revised Text:
    Disposition:

  • Reported: SBVR 1.0 — Mon, 17 Oct 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Inconsistent use of terminology when relating facts to fact types

  • Key: SBVR15-64
  • Legacy Issue Number: 15124
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Inconsistent use of terminology when relating facts to fact types

    It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type – obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings.

    Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places.

    Recommended changes:

    1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says:

    A ‘Fact’ is of a particular ‘Fact Type.’

    2. REPLACE the third paragraph of 10.1.1.2, which says this:

    The conceptual schema declares the fact types (kinds of facts, such as “Employee works for Department”) and rules relevant to the business domain.

    With this:

    The conceptual schema declares the fact types (such as “Employee works for Department”) and rules relevant to the business domain.

    3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says:

    The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema).

    REPLACE it with this:

    The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema).

    4. Just above figure 10.1 on page 90 there is the following sentence.

    Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts.

    REPLACE it with this:

    Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts.

  • Reported: SBVR 1.0 — Tue, 9 Mar 2010 05:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Keyword "another"

  • Key: SBVR15-62
  • Legacy Issue Number: 17244
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another <person3>" refers to <person1> and/or <person2>:

    It is prohibited that a <person1> <is married to> <person2>, if that <person1> <is married to> another <person3>.

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Formalize the 'quantity' entry

  • Key: SBVR15-60
  • Legacy Issue Number: 19332
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    'quantity' is defined informally. A formalization of the existing definition is proposed, along with changes in terminology and related entries that would be affected by the change.

    The proposed changes unify some fundamental concepts in SBVR and application domains and significantly enhance the ability to reason about SBVR models.

    Full details are provided in a paper I authored but am unable to attach to this message because of limitations of this OMG Web site, which does not accept attachments. Please contact me if you would like to review the paper, and I'll send it by email.

  • Reported: SBVR 1.2 — Thu, 10 Apr 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: 'denotes' is too narrowly defined

  • Key: SBVR15-93
  • Legacy Issue Number: 19883
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR v1.3, clause 8.7, Figure 8.12, 'expression denotes thing' represents the bottom edge of the semiotic triangle, but unlike 'represents' and 'corresponds to', which represent the other two edges of the semiotic triangle, 'expression denotes thing' is not an SBVR verb concept. Instead, we have 'term denotes thing', 'name references thing', 'statement denotes state of affairs'. But none of 'term', 'name', and 'statement' is (said to be) an expression. So, none of the SBVR concepts actually represents the 'denotes' concept in the semiotic triangle. And apparently an SBVR verb symbol cannot denote anything!

    This is completely inconsistent with established linguistic and semiotic practice, and it is inconsistent with ISO 1087. Yes, SBVR distinguishes expressions by their roles – term, name, verb symbol, definition, statement – but they all denote things. The idea of the diagram 8.12 is that each role of expression constrains the things that it can denote, but that model is incomplete. Verb symbols and definitions are also roles of expressions in representing concepts and can thus denote the things to which the concept corresponds. Further the use of 'references' instead of 'denotes' for 'name denotes thing' is a pointless inconsistency, which reduces the clarity of the specification.

    Note also that the term 'denotes' (without markup) is incorrectly used in the definition of 'designation'. 'denotes' is correctly used in the definition of 'placeholder', but that use assumes the missing generic concept 'expression denotes thing', because a role expression can be anything from a simple term/name to a quantified definitional expression. That is, SBVR uses the common understanding of the term 'denotes' but the SBVR concept system does not contain that concept.

    [This is a replacement for Issue 19715, which is confused.]

  • Reported: SBVR 1.2 — Mon, 13 Jun 2016 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue - What is a 'terminological entry'

  • Key: SBVR15-80
  • Legacy Issue Number: 19749
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR

    Version: 1.3 (from RTF Report)

    Title: What is a 'terminological entry'

    Summary:

    SBVR clause 6.2 (How to read this specification) says:

    "This specification describes a vocabulary, or actually a set of vocabularies, using terminological entries. Each entry

    includes a definition, along with other specifications such as notes and examples."

    But the term 'terminological entry' is not defined anywhere in the text of SBVR. In particular, it does not appear in Clause 19.3 in relationship to 'terminological dictionary'.

    Clause 19.3 says a 'terminological dictionary' is a collection of representations, that it "includes representations" and "presents a vocabulary". But then a vocabulary is a "set of designations", and is apparently related to them by 'thing is in set', because there is no other stated verb concept to relate them. So the vocabulary is a subset of the "set of representations" that is included in a terminological dictionary that presents it? But a 'terminological entry' seems to be none of the above, and a 'terminological dictionary' does not include them? This set of circumlocutions completely fails to present a clear model for the exchange of a vocabulary or of a terminological dictionary. The central idea in a terminological entry, if SBVR is any indication, is a concept, and representations of it, and related commentary.

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Multiple interpretations of the General Concept caption

  • Key: SBVR15-79
  • Legacy Issue Number: 19748
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Annex A.4.5 says: "The 'General Concept' caption can be used to indicate a concept that generalizes the entry concept."

    In point of fact, the General Concept caption represents three entirely different verb concepts in different contexts:

    • In the entry for a general noun concept or verb concept X, General Concept: Y means 'X specializes Y'.
    • In the entry for an individual noun concept X, General Concept: Y means 'X is an instance of Y'.
    • In the entry for a "role concept" X, Genera Concept: Y means 'X ranges over Y' (see also Issue 19519).

    Further, it is possible for a role concept to specialize another role concept, as 'first member' (of a list) specializes 'member' (of a list). But the range of 'first member' is whatever the list is a list of. Similarly, 'captain (of ship)' specializes 'officer (of ship)' but both range over 'person'. So, overloading General Concept in the way SBVR does makes it less capable of conveying the semantics of roles.

    [Note that UML and MOF distinguish between the range of an association end (role) -- the class (general concept) to which it is connected -- and any association end (role) that it subsets/redefines (specializes). SBVR apparently cannot.]

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue - Annex A is a mistitled grab bag

  • Key: SBVR15-78
  • Legacy Issue Number: 19747
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR

    Version: 1.3 (from RTF Report)

    Title: Annex A is a mistitled grab bag

    Annex A is titled "SBVR Structured English", and every paragraph of A.1 is about that topic, except for the last, which indicates that every subsection after A.2 is about other topics. In particular, A.3 and A.4 are about the structure of the SBVR specification as a terminological dictionary, and A.5 and A.6 are guidance for creating 'rule set' structures.

    It is imperative that A.3 and A.4 be packaged as a section, either in section 6.2 (How to read this specification), or in an Annex that 6.2 points to. Those two sections are "how to read the SBVR specification" and interpret the terminological entries in it. This issue arose from trying to find that guidance.

    Guidance for creating rule sets (A.5 and A.6) is not a characterization of either SBVR SE or the structure of the SBVR specification. It is a separate topic, associated with clauses 16 thru 18.

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Metamodel Fixes Related to a Formal Logics Interpretation

  • Key: SBVR15-77
  • Legacy Issue Number: 11303
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The following SBVR metamodel formal logic-based errors and omissions need to be dealt with as we ran out of time to deal with them:

    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.

  • Reported: SBVR 1.0b1 — Thu, 23 Aug 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

The Notion of “Involvement” has not been Adequately Specified with in SBVR

  • Key: SBVR15-76
  • Legacy Issue Number: 11301
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The ‘involvement’ Issue is as follows (from my email sent on Saturday):

    Issue Submitter’s Name: Donald Chapin

    Issue Submitter’s Company: Business Semantics Ltd (submitted as SBVR FTF Chair)

    Issue Submitter’s Email: Donald.Chapin@btinternet.com

    Issue Name: The Notion of “Involvement” has not been Adequately Specified with in SBVR

    Document No: dtc/06/03/01

    Document Revision Date: March 2006

    Document Version No: —

    Chapter/Section: 8.1.1

    Page No(s): 16

    Nature of Issue: Revision

    Severity of Issue: Major

    Issue Description:

    The notion of Involvement has not totally been taken into account by the resolution of Issue 9948 as stated in that resolution.

    Several clarifications are needed regarding Involvement such as the nature of instance of roles (see the sum example in the initial 9948 statement).

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

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre

  • Key: SBVR15-75
  • Legacy Issue Number: 11328
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    As a result of the vote on Issue 9959, there is a need to clarify and strengthen the Note in front of the Formal Logic Interpretation Table in Clause 10.2, particularly to cover these points:

    • a major subset of SBVR has a complete formal logic interpretation whose principles are set forth in Clause 10.1
    • the table will contain:

    o a formal logic interpretation specified in ISO Common Logic based on Clause 10.1

    o a cross-reference to OWL constructs that equivalent to SBVR constructs

    • the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force
  • Reported: SBVR 1.0b2 — Thu, 30 Aug 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: Definitions should be tagged by language

  • Key: SBVR15-92
  • Legacy Issue Number: 19829
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification SBVR v1.3

    Summary:

    The distinction between text that is not intended to be completely marked up as well-defined SBVR SE and text that is intended to be natural English should be somehow noted in the paragraph tag or some text annotation, and similarly distinguished in the XML file. Otherwise the recipient tool cannot determine whether the ‘text’ object is intended to be interpretable. SBVR Structured English is not English; it is a formal language that one might expect a receiving tool to parse and interpret, while that cannot be expected for arbitrary business English. SBVR SE is not unique in this regard. It is important to tools that define their own restricted natural languages to be able to label definitions and necessities as having that particular form, so that they can know to parse it. The text markup tricks that distinguish the languages in the SBVR specification do not transfer into the XML file. Some means of identifying a 'controlled' natural language for a given definition or necessity should be provided in the XML, and possibly in the terminological entry presentation.

    The examples in clause 27.3 describe patterns for definitions in XML that are based on the non-normative markup conventions used in SBVR. Those distinctions are not specified as SBVR concepts and are not necessarily supported by conforming tools. So the text is unclear about the normative requirement. There is only one pattern for definitions. The intent is that, regardless of the form of the definition, if the tool knows the more general concept, it should provide the ‘specializes’ fact, and may provide an LRMV representation.

  • Reported: SBVR 1.2 — Thu, 3 Sep 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: 'partitive verb concept' is ill-defined

  • Key: SBVR15-90
  • Legacy Issue Number: 19807
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR v1.3

    Title: 'partitive verb concept' is ill-defined

    Summary:

    Clause 14.1.2 defines ‘partitive verb concept’ as “verb concept where each instance is an actuality that a given part is in the composition of a given whole.” The examples include ‘car model is in car group’, which is a logical grouping, and ‘barrel is included in mechanical pencil’, which is a physical composition. In several upper ontologies, these concepts – logical grouping and physical composition – are significantly different; that is, the group-member relationship is not considered to be a whole-part relationship. And UML distinguishes them as “aggregation” and “composition”.

    The following all involve some business concept of “part of”:

    A line item is part of a budget.

    A disc is part of a brake assembly.

    A triangle has 3 sides and 3 internal angles.

    Answering the phone is part of the receptionist’s duties.

    John was a part of the team that designed Curiosity.

    John is a member of the Republican Party.

    The Tea Party is an outspoken segment of the Republican Party.

    What is it that they all have in common? What rule applies to all of them?

    If the reader understands what the relationship is, saying that it is partitive conveys nothing s/he does not know. If the reader does not clearly understand the verb concept, what can s/he conclude from the statement that it is 'partitive'? Is it subjective?

    Edward J. Barkmeyer

    Thematix Partners

    Email: ebarkmeyer@thematix.com

    Phone: +1 240-672-5800

  • Reported: SBVR 1.2 — Mon, 15 Jun 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Not all closed logical formulations formulate propositions

  • Key: SBVR15-95
  • Legacy Issue Number: 19822
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR clause 21.3 (Logical formulations) says:

    "Each meaning formulated by a closed logical formulation is a proposition".

    This statement is false. If we assume the existence of a verb concept 'person is in location', then in a statement like: "John is in London on Tuesdays", the logical formulation of "John is in London" is closed – it contains no variables. But this usage is not intended to formulate a proposition. No assertion is made that "John is in London" is true or false, or that anyone cares. The 'meaning' that this closed logical formulation formulates is a concept – a category of 'state of affairs', whose instances are states in which John is in London.

    By comparison, assuming that we also have 'state of affairs occurs on time interval', the whole sentence also has a closed logical formulation: For each Tuesday t, there is an instance of the concept "John is in London" that occurs on t. And that formulation IS intended to formulate a proposition.

    When a closed logical formulation is used to represent a proposition, the interpretation as a proposition produces either 'true' or 'false', and the interpretation of the same closed logical formulation as a category of state of affairs produces a concept that corresponds to at most 1 actuality. So the SBVR statement that a true proposition corresponds to an actuality is consistent with both interpretations, and the idea that a false proposition does not correspond to an actuality is also consistent.

    Now, SBVR asserts that a false proposition corresponds to a state of affairs that is not an actuality. But the closed logical formulation of a false proposition when it is interpreted as a category of state of affairs is simply a concept that does not correspond to any actuality. There is no need for it to correspond to some fictitious event or situation.

    For "XYZCo needs to have an office in Miami", i.e., "XYZCo needs that XYZCo has an office in Miami", "XYZCo has an office in Miami" has a closed logical formulation that is not intended to represent a proposition, but rather a category of states of affairs. XYZCo does not need a fictitious instance of that category, it needs the category to correspond to an actuality. It is the nature of verbs like "needs" and "wants" to refer to a category with that intent. And it is no different from "XYZCo needs an XYZCo office in Miami" – "XYZCo office in Miami" refers to a concept with the intent that it should have at least one instance. There is no existing or fictitious 'XYZCo office in Miami' that XYZCo needs.

    Similarly, if "Mary prevents Jimmy from playing with matches", what Mary prevents is "a 'playing with matches' by Jimmy", or equivalently, the situation 'Jimmy plays with matches'. The latter form is a closed logical formulation that is not intended to represent a proposition. It represents the same category of state of affairs that "a 'playing with matches' by Jimmy" does. Mary does not prevent one fictitious instance of that concept, but rather that the concept has any instances at all. It is the nature of "prevents" to refer to a category of states of affairs with that intent. In a similar way, one can "prevent forest fires". There is no need for the concept "forest fire" to have a fictitious instance that is prevented.

    Technically, these latter usages mean is that the verb concept wording for "needs" should be:

    thing1 needs thing2*

    where the asterisk indicates an "intensional role" as described in SBVR A.2.6. And similarly for "prevents", "wants", etc. Similarly, the concept of occurrence should be worded:

    state of affairs* occurs on time interval

    The use of the intensional role makes it clear that when the thing2 or state of affairs role is played by a closed logical formulation, the intended interpretation is a concept, not a proposition.

    Understanding this dual role of closed logical formulations (and the corresponding English and Structured English formulations) is critical to resolving a number of conflicts about states of affairs between SBVR and other OMG business specifications. It allows us to distinguish 'category of state of affairs' from 'state of affairs' in usages, and to recognize that 'state of affairs' and 'actuality' have exactly the same instances.

  • Reported: SBVR 1.2 — Fri, 31 Jul 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Rulebook is for governed community

  • Key: SBVR15-81
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    In some situations, a community is governed by a rulebook owned by another community. This frequently occurs in contracts. For example:

    • EU-Rent’s renters are governed by its rental contract. Like most contracts for services, it contains terms and conditions (respectively, the explicitly-defined vocabulary of the contract and the rules of the contract). The rental contract governs the ‘renter’ and ‘additional driver’ roles of its customers, but is owned by (is under the business jurisdiction of) EU-Rent. The rental contract is the rulebook for rental customers.
    • Almost all over-the-counter (OTC) derivatives trading is conducted under the ISDA Master Agreement, which governs the counterparties in a trade but is owned by The International Swaps and Derivatives Association.

    There are often rules for the owning and governed communities that are related. For example:

    • EU-Rent has a rule in its rental contract (i.e. for renters): “The rented car of an open rental must not be outside the area authorized for the rental”. This would probably be stated in the contract as “You must not take your rented car outside the area authorized in your rental contract. If you do, your contract will be canceled.” or something similar. The second sentence is not a rule with which the renter must comply. It's a warning of the consequence of not complying with the rule. (Note: an open rental is a rental in which the renter has possession of the rented car).
    • There is a related rule for EU-Rent staff: “If the rented car of an open rental is outside the area authorized for the rental then the rental contract must be canceled”. EU-Rent staff are not governed by the rule for renters (unless they have rented a car from the company).

    The noun concept "governed community" and the verb concept "rulebook is for governed community" should be added to SBVR

  • Reported: SBVR 1.3 — Wed, 15 Jun 2016 12:48 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Use of SBVR markup in specifications

  • Key: SBVR15-94
  • Legacy Issue Number: 19828
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR v1.3

    Summary:

    Experience with DTV teaches that the SBVR markup practices are very expensive in editor time, and do not improve readability of definitions and necessities in OMG specifications. The marked up text can only usefully be output from an authoring tool; the author should be able to input plain text for definitions and necessities. And, in the case of complex definitions, the markup reduces the readability of the text.

    The function of the markup as output from a tool is twofold:

    • to allow the business analyst to identify vocabulary entries in text
    • to allow the business analyst to verify that a text consists only of keywords and vocabulary entries

    In the absence of a tool that can recognize vocabulary and keywords in plain text and generate the marked up form, it should not be the practice of OMG specifications to use the markup. Further, even when it is possible, the use of the markup in definitions and necessities reduces readability, partly as a consequence of oversize sans-serif font, which is known to disrupt the visual flow of text to readers. In short, SBVR itself “leads by bad example” in this area.

    SBVR should be clear that its use of markup is what one might expect a tool to be able to do, but not what one would expect an author to provide. And it should be made clear that the use of SBVR has nothing to do with using the markup, while the vocabulary headings are important. (The best example would have been not to use it in the SBVR spec.)

  • Reported: SBVR 1.2 — Thu, 3 Sep 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR Issue: Erroneous normative requirements for SBVR XML

  • Key: SBVR15-91
  • Legacy Issue Number: 19830
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification SBVR v1.3

    Clause 23.7

    In the second paragraph of clause 23.7, we find:

    " The XML patterns provide a normative definition of which SBVR concepts are represented by each use of SBVR Structured English in the vocabulary descriptions and entries contained in Clauses 7 through 21. The general principles used for the patterns are these: First, the facts of what is presented using SBVR Structured English are represented using XML."

    This suggests that the normative requirements for XML representation are based on the use of the non-normative SBVR SE. That is obviously wrong, and could not be the intent, but unfortunately this misconception carries through into the 'example' patterns.

    In particular, noun concepts have multiple forms of Definition, but the distinctions are based on use of SBVR SE markup. There should be only one XML form.

    Also, if the patterns are normative, as the cited paragraph says, then the inclusion of the LRMV representation of a noun concept as a projection is apparently required. If the following XML elements are optional, the text does not say so:

    <sbvr:closedProjectionFormalizesDefinition closedProjection="def-formal-projection" definition="def-formal"/> <sbvr:closedProjectionDefinesNounConcept closedProjection="def-formal-projection" nounConcept="meaning"/>

    Similarly, the unary verb pattern contains the XML element:

    <sbvr:placeholderUsesDesignation placeholder="eis-p" designation="example"/>

    Presumably this element is optional, and not meaningful if the placeholder does not 'use' some other designation. Is there some normative significance to the appearance of a term within a placeholder expression? Is a placeholder expression required to contain some other term? (There is a convention in clause 12, but no normative statement about this convention.)

    And the verb definition pattern contains:

    <sbvr:closedProjectionFormalizesDefinition closedProjection="efe-projection" definition="efe-def-formal"/> <sbvr:closedProjectionDefinesverbConcept closedProjection="efe-projection" verbConcept="meaning"/>

    <sbvr:variableMapsToVerbConceptRole variable="efe-var1" verbConceptRole="efe-r1"/>

    <sbvr:variableMapsToVerbConceptRole variable="efe-var2" verbConceptRole="efe-r2"/>

    Are these parts of a verb Definition required?

    The patterns for Necessities and Possibilities similarly apparently require logicalFormulation elements, but they should be optional.

    The whole problem here is that the text provides examples that are examples, not the normative patterns that the cited paragraph says they are. The text has to clarify what parts of the patterns are required (under what circumstances), and what parts are optional.

    Note also that the pattern for the synonymous form seems to be missing a sbvr:verbConceptRoleDesignation element for the first placeholder.

    Finally, Clause 23 provides no pattern for verb concept wordings that involve more than two roles. So they have no defined XML representation at all, and one cannot expect successful exchange of such verb concepts.

  • Reported: SBVR 1.2 — Thu, 3 Sep 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

SBVR issue - "behavioral business rule" vs. "behavioral

  • Key: SBVR15-88
  • Legacy Issue Number: 19891
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    "Behavioral rule" is not infrequently used in discussion and writing. For example, in SBVR itself it appears in the the first line of the Note at the top of p.119. It also appears 4 times in headings and figure titles.

    However, SBVR doesn't currently recognize the term. There is (and can be) no such thing as a behavioral rule that is not a business rule. SBVR should indicate explicitly that "behavioral rule" is simply a synonym for "behavioral business rule".

  • Reported: SBVR 1.2 — Sun, 31 Jul 2016 04:00 GMT
  • Disposition: Deferred — SBVR 1.5
  • Disposition Summary:

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

    Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

  • Updated: Tue, 8 Oct 2019 17:48 GMT

Definition of Rulebook

  • Key: SBVR14-99
  • Legacy Issue Number: 19797
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The current definition of “rulebook” in SBVR is counterintuitive and simply wrong if judged on the basis of real-life rulebooks. People who use rulebooks expect to find a collection of rules first and foremost, not a terminological dictionary plus a set of rules. It is even possible (though not a good practice) to produce a rulebook with no definitions (terminological entries) whatsoever.

    Also, the Note in the entry for “rulebook” seems to overlook definitional elements of guidance. Obviously a rulebook can and almost always do include definitional elements of guidance.

  • Reported: SBVR 1.2 — Fri, 12 Jun 2015 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    1. Change the current definition of “rulebook” in SBVR to remove the unintended consequence of the “terminological dictionary plus” that makes rulebook a subcategory of terminological dictionary, which was never intended.
    2. Remove the unintended subtype connection in diagram Figure 19.5 from rulebook to terminological dictionary.
    3. Change the Note in the entry for rulebook to remove the “terminological dictionary plus” which is superfluous.
    4. Add an entry for the special case of '
    SBVR rulebook' (or 'complete rulebook'), as reflected in SBVR Part 1:

    • page 4, in Clause 1.4, second bullet.
    • page 4, in Clause 1.5, second paragraph, fourth line.
    • page 6, in Clause 2.2, fourth line from the very top.
      (The other uses of 'rulebook' in Part 1 do not relate to this Issue.)
      An 'SBVR rulebook' (or 'complete rulebook') is a rulebook that includes a complete terminological dictionary.
      5. Make other related edits (e.g., revised wording in Notes to correspond to these changes.)
  • Updated: Thu, 6 Apr 2017 13:51 GMT

Behavioral Rule Is Violated

  • Key: SBVR14-104
  • Legacy Issue Number: 19796
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Summary:
    A fundamental idea in SBVR is that behavioral rules can be broken – that is, violated by people. This idea is intrinsic to the distinction SBVR makes between definitional rules and behavioral rules.

    Yet nowhere does SBVR currently provide a means to capture the circumstances under which a particular behavioral rule is actually violated. This represents a critical shortcoming. An exact understanding of such circumstances is needed for any robust treatment of business rules.

    Fortunately, the resolution of this issue is quite straightforward – SBVR already has the needed concepts to resolve it. In particular, SBVR already includes the concept of acceptable world, providing the necessary deontic basis for the resolution. Only a single new verb concept is needed, behavioral rule is violated, along with appropriate definition.

  • Reported: SBVR 1.2 — Fri, 12 Jun 2015 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    A behavioral rule can be imposed on a semantic community that is broader than, or different from, the authority that has business jurisdiction over the rule. For example, many of EU-Rent's behavioral rules are imposed on sub-communities of its employees, but some are imposed on its rental customers (mostly in the terms and conditions of the Rental Contract).
    The enforcing authority for a behavioral rule is often, but not always, a sub-community within the authority that has business jurisdiction over the rule – for example, police and courts.
    The enforcing authority for a behavioral rule needs to consider three things:
    4. What remedial action is needed to address the violation
    5. What consequential action may be needed
    6. Whether some sanction should be applied to whoever is responsible for the violation
    However, these actions are separate from the violation.
    For example, EU-Rent has a rule that no rented car may be taken outside the area authorized for its rental. If EU-Rent discovers that the rented car of an open rental is outside the area authorized for the rental, it will apply the following enforcement:
    4. EU-Rent will cancel the rental contract.
    5. EU-Rent needs to: notify the insurer; advise the renter that the contract is canceled and that they are no longer insured and must not drive the car; recover the car and charge the cost to the renter; etc.
    6. EU-Rent could cancel any future rental contracts for the renter, and bar the renter from being an additional driver on current or future rentals.
    Since both determining and recording whether or not a behavioral rule has been violated is out of scope for SBVR, the concept ‘behavioral rule is violated’ is added to the list (at the end of the introduction to Clause 23.3 - added by SBVR Issue 19840) of concepts that do not go into an SBVR Content Model exchange document and the SBVR XMI metamodel.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR-Issue: 'no' as an SBVR key word (styled)

  • Key: SBVR14-97
  • Legacy Issue Number: 19890
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    There are over 50 places in SBVR where ”no” is used (styled) as a key word and yet it does not appear in any of the Annex A key word groups.

    Add ”no” to the appropriate list of key words in Annex A, supporting its current use in the body of the SBVR document

  • Reported: SBVR 1.2 — Wed, 27 Jul 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    Styled ”no” needs be added to the appropriate list of key words in Annex A, supporting its current use in the body of the SBVR document.
    Add 'no' to the end of the A.2.1.1 list:

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Stand-Alone 'Must' in a Necessity

  • Key: SBVR14-98
  • Legacy Issue Number: 19889
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Issue: Stand-Alone 'Must' in a Necessity

    The second Necessity for "adopted definition" on p.137 includes a stand-alone "must". Use of a stand-alone "must", with its inherent sense of obligation, in Necessities is inappropriate. (In reviewing the whole document, this is the only case I find of its use in a Necessity.)

    Resolution

    Change:

    Necessity: Each adopted definition must be of a concept in the body of shared meanings that unites the semantic community that has the speech community.

    to

    Necessity: Each adopted definition is of a concept in the body of shared meanings that unites the semantic community that has the speech community.

  • Reported: SBVR 1.2 — Tue, 14 Jun 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    Change:
    Necessity: Each adopted definition must be of a concept in the body of shared meanings that unites the semantic community that has the speech community.
    to
    Necessity: Each adopted definition is of a concept in the body of shared meanings that unites the semantic community that has the speech community.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Rule Set

  • Key: SBVR14-102
  • Legacy Issue Number: 19882
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    A very common need for rules is to organize them into named sets. These named sets can be referenced by other rules. Because of that fact, this Issue is one pertaining to semantics – i.e., it is within SBVR scope.

    SBVR-SE provides for the specification of rule sets (Annex A.5). This is a further reason for some appropriate entry/ies within SBVR proper for “rule set”.

    SBVR currently includes the following entry:

    body of shared guidance all of the elements of guidance within a body of shared meanings

    But a rule set (or ruleset) organizes some, not all, elements of guidance within a body of shared meanings. In other words, a rule set need not be ‘complete’ (but should be non-redundant).

    Annex A.5 indicates that a rule set can have a:

    • Name
    • Description
    • Vocabulary
    • Note
    • Source

    However, some or all of these same properties probably apply to many or all kinds of bodies/sets/collections, and so it properly addressed under Issue 17542 (Containers Holistically).

    Resolution:

    Add the following entries into Clause 19:

    rule set
    Definition: set of one or more elements of guidance within a body of shared guidance
    Synonym: ruleset

    ruleset
    See: rule set

    body of shared guidance includes rule set
    Synonymous Form: rule set is included in body of shared guidance

    rule set includes element of guidance
    Synonymous Form: element of guidance is included in rule set

  • Reported: SBVR 1.2 — Wed, 17 Feb 2016 05:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    The concept ‘rule set’ is referenced in the context of the SBVR Content Model exchange document in SBVR Clause 23 which is normative, but it is not defined in the SBVR Vocabulary, nor is this concept included in either the SBVR XMI Metamodel file (Clause 25.2) or the SBVR XMI Metamodel XML Schema file (Clause 25.3). The concept ‘rule set’ and its two supporting concepts needs to be added to SBVR to close this internal gap in SBVR.

    Add into Clause 19 the entries for:
    • rule set (ruleset)
    • body of shared guidance includes rule set
    • rule set includes element of guidance

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Swap Preferred Signifiers for (Business) Rules and Advices

  • Key: SBVR14-15
  • Legacy Issue Number: 19458
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    In the early days of team discussions about alethic vs. deontic modalities for rules and advices, the signifiers "structural" and "operative" were introduced to make this important distinction between modalities (respectively). Later, the signifiers "definitional" and "behavioral" were introduced as synonyms.

    Over time the synonyms have proven more accurate, intuitive, and popular, both within SBVR team discussions and externally. For example:
    • The signifier "operative" has not been used in the Business Rules Journal on www.BRCommunity.com as a primary signifier since at least 2009.
    • Both of my books (Business Rule Concepts and Business Analysis with Business Rules) use the synonyms.
    • In my judgment, an internet search on "behavioral (business) rules" produces more relevant results than one on "operative (business) rules".

    The time has come to designate the newer pair as the preferred signifiers and to switch usage throughout the SBVR standard itself. There are at least two reasons this change over should be made immediately:

    1) The re-sequenced /reorganized version of SBVR currently underway should not be appear in a revised form until the preferred terminology is corrected.
    2) Version 3.0 of IIBA's BABOK, widely influential within the business analysis community and beyond, is now in its final public renew stage. (The deadline is July 11.) Several RTF team members would like to be in a position to inform them of the revised preferred terminology, and to be able to say it's mandated this is the standard terminology by according to SBVR. This window of opportunity will close for at least 3 years or so unless we do it now.

  • Reported: SBVR 1.1 — Mon, 9 Jun 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    Change the entry for 'structural rule' (in 17.1.2) to use 'definitional rule' as the entry term and to use 'structural rule' as a Synonym. Make the corresponding changes to swap terms in the synonym ("See:") entry that follows. Also change the entry for 'structural business rule' (in 17.1.2) to use 'definitional business rule' as the entry term and to use 'structural business rule' as a Synonym. Make the corresponding changes to swap terms in the synonym ("See:") entry that follows.
    Ignoring these four entries in 17.1.2 AND the cases listed below, change (everywhere) the term 'structural' to 'definitional'. The cases where "structural" does NOT change are:
    • in Clause 14: the 14.1 title & the 14.2 title.
    • in the uses of "structurally" — all such cases are valid as is and should not be changed.
    Change the entry for 'operative business rule' (in 18.1.2) to use 'behavioral business rule' as the entry term and to use 'operative business rule' as a Synonym. Make the corresponding changes to swap terms in the synonym ("See:") entry that follows.
    Ignoring these two entries in 18.1.2, change (everywhere) the term 'operative' to 'behavioral' and correct the article 'an' to use 'a', where needed.
    Change the diagrams where 'structural' and 'operative' appear to reflect the new primary terms.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Definition of Business Rule – Being Practicable

  • Key: SBVR14-103
  • Legacy Issue Number: 19827
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    A very fundamental idea about business rules is that they are practicable. The current SBVR entry for “business rule” (p.98), however, makes no mention of it:

    rule that is under business jurisdiction

    Yet, the counterpart of “business rule”, the entry for “advice” (p.99), does:

    element of guidance that is practicable and that is a claim of permission or of possibility

    If one is extremely observant and patient, one can work out that a business rule does have to be practicable. Here’s how:

    • The entry for “business policy” (p.100) has a Necessity that says “No business policy is a business rule”. (*Typo: Needs a period.*)

    • The definition of “business policy” (p.100) states that a business policy is an “element of governance that is not directly enforceable”.

    --> Putting the meaning of those two expressions together means that business rules have to be directly enforceable ... because they're not business policies.

    • The previous entry (p. 100) has a Necessity that says “Each element of governance that is directly enforceable is practicable.”.

    --> Since business rules are directly enforceable they therefore have to be practicable.

    Who would get that though?!
    Resolution:

    1. Change the current definition of “business rule” in SBVR from:

    rule that is under business jurisdiction

    to:

    rule that is practicable and that is under business jurisdiction

  • Reported: SBVR 1.2 — Thu, 13 Aug 2015 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    1. Change the current definition of “business rule” in SBVR from:
    rule that is under business jurisdiction
    to:
    rule that is practicable and that is under business jurisdiction

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Note for Rule

  • Key: SBVR14-100
  • Legacy Issue Number: 19798
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The current definition of “rule” in SBVR, while very precise, is opaque for practitioners. (The definition for “business rule” offers no help.) SBVR should be more definitive about the real-life sense/role/purpose of rules. It should also emphasize early-on the crucial distinction between necessities and obligations.

  • Reported: SBVR 1.2 — Fri, 12 Jun 2015 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    The SBVR v1.3 definition of “rule” in SBVR is:

    proposition that is a claim of obligation or of necessity

    SBVR Issue 19840 proposes a change to the definition. Regardless of the specifics of the changes made under that Issue, a precisely-crafted (fully formal) definition of 'rule' can be opaque for practitioners. To communicate, in real-world terms, the sense/role/purpose of rules the following Note is added to the entry for 'rule':

    Note: Rules fall into two fundamental categories, as follows:

    • A behavioral business rule indicates something people or organizations are either obliged to do (an obligation), or prohibited from doing (a prohibition). A behavioral business rule serves to shape conduct or action and to provide a basis for judging the propriety of behavior.

    • A definitional rule indicates either what is always the case (a necessity) or is never the case (an impossibility). A definitional rule serves to specify a condition, in addition to those specified in the definition of the concept, that is true for every instance of the concept(s) to which the rule applies.
    As such it can be used as the basis for inference.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

'necessity' and 'obligation' are missing SBVR concepts

  • Key: SBVR14-101
  • Legacy Issue Number: 19840
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.3, the definition of ?rule? uses the term ?necessity? and ?obligation? with markup that indicates that these terms are defined in one of the SBVR vocabularies. These terms are used again several times in Clause 17, also with markup. But I can not find a glossary entry for either term anywhere in the specification, and they do not appear in the Index of business designations.

  • Reported: SBVR 1.2 — Mon, 15 Jun 2015 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    The terms ‘necessity and ‘obligation’ have always been defined in the vocabulary in Clause 24.2 which defines the terms in Clause 24.1 “SBVR Formal Grounding Model Interpretation”. These terms have never been part of the SBVR Vocabulary. For this reason they should never have been fundamental to the definitions of ‘rule’, ‘advice’, and other rule-related concepts central to the standard. The vocabulary entries and definitions in Clause 8.6 “Connections between Kinds of Meaning and States of Affairs in the Business” should have been used in the rule-related concepts from the beginning.
    Appropriate definitions for the rule-related concepts should be as business-friendly as possible. The guiding SBVR principle in this regard is: “This specification is conceptualized optimally for business people rather than automated processing.” (SBVR Clause 1.2). The current dictionary basis for ‘rule’ clearly indicates the original intent for ‘rule’ in the standard:
    Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity ... a law or principle that operates within a particular sphere of knowledge, describing, or prescribing what is possible or allowable. [ODE]
    The rule-related concepts in SBVR fundamentally address states of affairs and actualities. Their definitions should be framed on that basis. Central to the set of rule-related concepts are “definitional rule” and “behavioral business rule”, which should therefore be defined as follows.
    definitional rule
    Definition: rule that necessitates a given state of affairs
    behavioral business rule
    Definition: business rule that obligates a given state of affairs
    The verb concept element of guidance obligates state of affairs already exists in SBVR (see Clause 8.6.3) and is defined as “the element of guidance entails that the state of affairs must be an actuality”. This definition, with the addition of “in all acceptable worlds” at the end, is exactly suited for the definition of “behavioral business rule” above.
    An appropriate definition of ‘rule’ therefore becomes:
    rule
    Definition: proposition that obligates a given state of affairs or that necessitates a given state of affairs
    For the definition of ‘advice of permission’, SBVR already includes the appropriate verb concept in Clause 8.6.3, as follows:
    element of guidance gives permission for state of affairs
    The word ‘permission’ should be replaced in this verb concept since it is a modal operator like 'necessity' and 'obligation'. The revised verb concept becomes:
    element of guidance permits state of affairs
    Based on that verb concept, the appropriate definition of ‘advice of permission’ is:
    advice of permission
    Definition: advice that permits a given state of affairs

    Currently in SBVR the verb concept element of guidance permits state of affairs is given as a synonymous form of element of guidance authorizes state of affairs. However, only in a ‘dark world’ do permissions become authorizations (SBVR Clause 16.4.1). Therefore, the main entry for this business concept should be element of guidance permits state of affairs rather than element of guidance authorizes state of affairs.

    It is explicitly noted that the following Notes and Examples are correct (and remain unchanged by this issue):
    1. The Note and three Examples for 'definitional rule statement' (p. 111).
    2. The Note and three Examples for 'behavioral business rule statement' (p. 120).

  • Updated: Thu, 6 Apr 2017 13:51 GMT

new SBVR issue: Add key words to A.2.1.3 Modal Operations

  • Key: SBVR14-96
  • Legacy Issue Number: 19892
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    As part of the work on 19840 it was discovered that ’can’ (a word paralleling ’may' but missing from the Annex A key word list) and ’need not’ (also missing) were being used in several places throughout the SBVR document to specify an intended modality. In some cases the key word was used to express the wrong modality. To make the usage clear (and formally styled) they need to be added to the lists in Annex A (A.2.1.3).

  • Reported: SBVR 1.2 — Wed, 3 Aug 2016 04:00 GMT
  • Disposition: Resolved — SBVR 1.4b2
  • Disposition Summary:

    These are the charts from the July discussion. They illustrate the missing coverage of the two alternative keywords: can (for alethic possibility) & need not (for deontic non-obligation).

    The key words 'can' and 'need not' should be added to the 2nd key word list in Annex A.2.1.3.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

styling of signifiers

  • Key: SBVR14-4
  • Legacy Issue Number: 18378
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Title: SBVR needs a consistently applied policy for styling or not styling signifiers
    Source:
    John Hall, RuleML Initiative
    john.hall@modelsystems.co.uk
    Summary:
    There is some inconsistency in the SBVR specification regarding which signifiers are styled and which are not.
    A policy needs to be agreed and applied consistently through the SBVR specification.
    Resolution:
    1. Style each use of the signifier of a concept (e.g. ‘thing’, ‘meaning’) where that use has the specific meaning defined in its SBVR entry;
    2. If the signifier of a defined concept has an everyday English meaning that is different from its SBVR definition, don’t style uses of it where the everyday meaning is intended;
    3. Add a paragraph to the introduction explaining the basis for styling/not styling.

  • Reported: SBVR 1.1 — Fri, 18 Jan 2013 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Noun form designates two different concepts

  • Key: SBVR14-1
  • Legacy Issue Number: 17532
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 8.3.4, the term 'verb concept wording' is defined as:
    "representation of a verb concept by an expression that has a syntactic structure involving a signifier for the verb concept and signifiers for its verb concept roles"

    In the same clause, the term 'noun form' is defined as:
    "verb concept wording that acts as a noun rather than forming a proposition"

    One would expect therefore, that a noun form of a verb concept would be a gerund, such as 'car transfer' for 'branch1 transfers car to branch2', where the 'noun form' denotes the same actualities as the verb concept.

    But only the last Example (which is hard to understand because of a particularly bad choice of verb) is said to be about gerunds. The other examples clearly are not. The first Example is: "'transferred car of car transfer' for the verb concept 'car transfer has transferred car'. This form yields a transferred car."

    The instances of 'car transfer has transferred car' are actualities of a car being involved in a car transfer. But the cited text says the instances of the 'noun form' 'transferred car of car transfer' are cars, not actualities. Similarly, the interpretation of the other two examples of 'noun forms' correspond to numbers, not actualities.

    So the instances of a noun form of a verb concept need not be instances of the verb concept! The noun form therefore cannot be a 'verb concept wording'. The noun form does not represent the verb concept!

    It appears that there are two different concepts here. Noun form 1 is "verb concept wording that acts as a noun." That is the gerund in the last Example. In the other examples, the noun form represents a derived concept that is what SBVR calls a 'situational role'. The intent of 'noun form 2' is "representation of a situational role by an expression that has a syntactic structure involving a signifier for the verb concept that the role is derived from and signifiers for some of its verb concept roles".

    Finally, use of noun form 2 in declaring a glossary item for a situational role would be preferable to using only the role designation. In particular, the explicit appearance of other role placeholders in the noun form would permit them to be used directly in defining the situational role.

    For example:
    cardinality
    Definition: nonnegative integer that is the number of distinct elements in a given set or collection

    could be declared with the noun form:
    cardinality of set
    Definition: nonnegative integer that is the number of distinct elements in the set

  • Reported: SBVR 1.1 — Fri, 27 Jul 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR issue: Can there be multiple instances of a thing?

  • Key: SBVR14-3
  • Legacy Issue Number: 16314
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR defines the concept "thing" in clause 8.7. The
    definition is unclear as to whether the extension of "thing" contains only
    singletons (i.e. individual things) or can contain instances that recur in
    some way.

    Proposed Resolution: Add a Necessity or Possibility or Note that explains
    whether individual things can recur. Add examples.

  • Reported: SBVR 1.0 — Mon, 6 Jun 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

'another' unnecessarily restricts the concept 'other'

  • Key: SBVR14-9
  • Legacy Issue Number: 19727
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause A.2.2, the keyword 'another' is introduced, with the interpretation:

    (used with a term that has been previously used in the same statement) existential quantification plus a condition that the referent thing is not the same thing as the referent of the previous use of the term

    The idea "existential quantification plus" is an unnecessary and undesirable addition. The useful keyword is 'other'. As described, "other X" means "instance of the general concept X that is not the same thing as the referent of the previous occurrence of the term X". But "another" is just a conventional spelling of "an other", and might equally have been spelled "some other". The term 'other' can be usefully quantified by quantifiers other than "an". Each other, at least n other, at most n other, exactly n other, and no other are all valid uses of 'other' with the given interpretation, less the "existential quantification plus".

    Defining only the portmanteau keyword 'another' greatly and unnecessarily limits the expressiveness of SBVR Structured English in this area.

  • Reported: SBVR 1.1 — Sat, 21 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES

  • Key: SBVR14-11
  • Legacy Issue Number: 19519
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, 'role': 'ranges over' vs. 'specializes'.

    Clause 8, entry for ‘role’. Should the addition at the end of the second Example text: "(which generalizes the role)" read: "(which the role ranges over)"? As I understand it, you mean to say that the role shipment ranges over the general concept shipment. The reverse reading of "ranges over" is not "generalizes" (there is a specific Note at the lemma "role ranges over general concept" that warns against this confusion).

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Misleading text in A.4.2.3

  • Key: SBVR14-2
  • Legacy Issue Number: 19522
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The first statement in Annex A.4.2.3 is misleading:

    A definition given for a verb concept is an expression that can be substituted for a simple statement expressed using a verb

    concept wording of the verb concept.

    Unlike a noun concept definition, the definition of a verb concept cannot simply be substituted for an occurrence of the verb concept wording. Like the verb concept wording itself, it is a structured pattern with placeholder parameters, and the substitution process is complex. In “substituting the definition expression for a simple statement expressed using the verb concept wording”, it is also necessary to substitute the role phrases that are used in the verb concept wording in that simple statement for the corresponding placeholders in the definition. That is significantly different from what happens in the noun concept case.

    In the same subclause, the sentence:

    “A definition of a verb concept can generally be read using the pattern below ...
    A fact that ... is a fact that ...”

    is not quite general enough. The definition characterizes the same state of affairs, even when it is not a fact. It could be written:

    A state of affairs in which ... is a state of affairs in which ...

  • Reported: SBVR 1.1 — Mon, 14 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

omission of the word 'if'

  • Key: SBVR14-13
  • Legacy Issue Number: 19671
  • Status: closed  
  • Source: AFAS Software B.V. ( Casper Lange)
  • Summary:

    Note nr. 1 of 'proposition is true' reads:
    "A proposition is true if and only the state of affairs..."
    And should read:
    "A proposition is true if and only if the state of affairs..."

  • Reported: SBVR 1.2 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles

  • Key: SBVR14-5
  • Legacy Issue Number: 19683
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles (a renter, even of a car, may or may not drive it)

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

The notion of “well-formedness” in compliance point 1 should be defined

  • Key: SBVR14-6
  • Legacy Issue Number: 19675
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notion of “well-formedness” in compliance point 1 should be defined

  • Reported: SBVR 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

How can an attributive role be declared?

  • Key: SBVR14-7
  • Legacy Issue Number: 17791
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR v1.1 Clause 8 says:
    Note: in the glossary entries below, the words “Concept Type: role” indicate that a general concept being defined is a role.
    Because it is a general concept, it is necessarily a situational role and is not a verb concept role.

    How does one declare an attributive role that is not a general concept?

    SBVR v1.1 appears to use such declarations to also declare roles that are attributive roles of a given noun concept and thus also in the attributive namespace of the noun concept. For example, clause 8.6 declares 'cardinality', which is an attributive role of integers with respect to 'sets', in a glossary entry with Concept type: role. But 'cardinality' is not a general concept; nothing is a 'cardinality', full stop. An integer can only be a 'cardinality' OF something. it is a purely attributive term. As a term for a general concept, 'cardinality' is thus a term in the Meaning and Representation namespace; it has no 'context'.

    The problem arises in defining attributive roles of general noun concepts, such as 'occurrence has time span' and 'schedule has time span', where the definitions of the two roles are importantly different because they are attributes of different general concepts that are only similar in nature. Neither is a situational role. That is, neither is a general concept. No time interval is a 'time span', full stop. A time interval must be a time span OF something. One 'time span' is in the attributive namespace of 'schedule', and a different 'time span' designation is in the attributive namespace of 'occurrence'. Neither is in the DTV.Situations vocabulary namespace per se. How can this be declared using SBVR conventions? Declaring them both in glossary entries with Concept Type: role apparently makes them conflicting designations for 'situational roles' in the DTV.Situations vocabulary.

    Does simply declaring the verb concept 'occurrence has time span' declare the attributive role? If so, how is the range of the role declared? And where does the definition of the attributive role go?

  • Reported: SBVR 1.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Revise Modeling of Fact Model and Conceptual Schema

  • Key: SBVR14-19
  • Legacy Issue Number: 13150
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    understand you will be discussing the topic of packaging SBVR tomorrow, and I want to provide a perspective on this topic and make a request.

    In my view, the key packaging concepts “fact model” and “conceptual schema” need to be in the normative SBVR metamodel to support widespread sharing and reuse of SBVR models. We want to promote the development of libraries of SBVR fact models and conceptual schemas and to compose fact models and conceptual schemas from other fact models and conceptual schemas. The ability to package these in a standard way is crucial to this end. A normative approach to globally identifying these models is needed to support their sharing and reuse. Concepts of packaging, identification, and composition of fact models and conceptual schemas are preferably included in Clause 8. As the most basic compliance point, Clause 8 needs to be expressible in terms of itself, and to include concepts for packaging, identification, and composition of fact models and conceptual schemas. I understand a proposal is under consideration to move “fact model” and “conceptual schema” entries to Clause 10. This would be a mistake, as we would then have no normative way of specifying the packaging.

    The definition of “conceptual schema” should be refined to reflect the fact that a conceptual schema is a kind of fact model. The distinction between a conceptual schema and other fact models is that a conceptual schema includes at least one fact that asserts the existence of a concept. Other fact models that are not conceptual schemas contain only ground facts. The text of SBVR makes it clear that a conceptual schema is a fact model, that every SBVR interchange document is a fact model. That “conceptual schema” specializes “fact model” should be reflected in the definition of “conceptual schema.”

    The term “vocabulary” is not used in the SBVR specification consistently with its definition as a “set of designations and fact type forms…” Each of the normative clauses of SBVR, called a “Vocabulary,” is actually an annotated conceptual schema. A conceptual schema comprises a “combination of concepts and facts (with semantic formulations that define them)…” The designations and fact type forms in each SBVR normative “Vocabulary” constitute the vocabulary of that “Vocabulary”. The definitions and necessities in the SBVR entries are statements of schema facts. The notes and examples are annotations of the conceptual schema. Ability to include annotations is crucial to practical development and use of any model, and is universally provided for in other and modeling and programming languages. It should be possible to normatively include annotations in a SBVR conceptual schema or fact model. Accordingly, it is recommended that “description” and related concepts of notes and examples in Clause 11.2.2 be moved to Clause 8 to support annotation of fact models. With respect to the semantic formulations of a conceptual schema, it is preferred that Clause 8 only include statements of the definitions and schema facts, and leave it to Clause 9 to include the semantic formulations of these. Either “vocabulary namespace” and fact types that use the term should be moved to Clause 11, or “vocabulary” should be moved to Clause 8. The concept “vocabulary” is not necessary in Clause 8 but might be conveniently located there. Namespaces adequately serve the purpose of organizing designations and fact type forms. It is suggested the RTF consider providing recommendations for naming conventions for URIs of namespaces and related conceptual schemas that define and constrain the concepts represented by the designations and fact type forms in the namespaces.

    Here are some suggested entries for Clause 8 that show how the concepts described above might be modeled:

    conceptual schema

    Definition: fact model that includes at least one existential fact asserting a concept

    Note: This definition extends the definition of ‘conceptual schema’ in SBVR to formalize that a conceptual schema is a kind of fact model. This is evident in the specification text, but is not included in the current definition.

    Note: The facts of a conceptual schema in addition to the concept existential facts describe what is possible, necessary, permissible, and obligatory in each possible world of the domain being modeled.

    Note: Two levels of formalization of fact models (including conceptual schemas) are possible. 1) A fact model may contain only statements of definitions and other facts and not their semantic formulations. In this case, the fact model can meet the Meaning and Representation compliance point, 2.2.1. 2) A fact model may contain semantic formulations of its definitions and facts, in which case the fact model can meet the Logical Formulation of Semantics compliance point, 2.2.2.

    fact model1 includes fact model2

    Note: This fact type enables recursive composition of fact models and conceptual schemas.

    Necessity: This fact type is reflexive, antisymmetric, and transitive, i.e. related fact models are at least partially ordered.

    fact model includes description

    Note: This fact type enables the annotation of fact models and conceptual schemas.

    thing has URI

    Note: This fact type enables modeled things to be identified globally for future reference.

    I am requesting that these concepts, or some refinement of them, be included in the next release of SBVR.

  • Reported: SBVR 1.0 — Wed, 10 Dec 2008 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

'reality' and 'in-practice' models

  • Key: SBVR14-20
  • Legacy Issue Number: 15953
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

    In recognizing that an organization is not necessarily interested in recording all information about the real world, the SBVR proposes that there be two models of the world: a ‘reality model’ (of the real world) and an ‘in-practice model’ (of the organization’s view of the real world), which leads to some bizarre rule statements, listed below. Surely there is only 1 model in which both real-world objects and representations of them exist. The relevant quote from the SBVR is “Suppose the following two fact types are of interest: Employee was born on Date; Employee has Phone Number. In the real world, each employee is born, and may have more than one phone number. Hence the reality model includes the constraint ‘Each Employee was born on at least one Date’ (sic) and allows that ‘It is possible that the same Employee has more than one Phone Number.’ [If] the business decides to make it optional whether it knows an employee’s date of birth, [and] is interested in knowing at most one phone number for any given employee, … the in-practice model excludes the reality constraint ‘Each Employee was born on at least one Date’, but it includes the following constraint that does not apply in the reality model: ‘Each Employee has at most one Phone Number’. ”
    I believe there should be one model (not two), in which for each fact type there may be multiple rules reflecting specific requirements. Considering just dates of birth, the assertion “Each Employee was born on at least one Date” (which might be better worded as “Each Employee was born on exactly one Date”, “Each person has exactly one date of birth” or perhaps “Each person has a date of birth”) is a statement about the real world.
    Consider an insurance business that decides that it must collect the date of birth of each customer purchasing personal life insurance but does not need it for those purchasing only home insurance. Following the logic expressed in the SBVR (as quoted above) the ‘in-practice model(s)’ contain a new constraint: “Each person purchasing personal life insurance has a date of birth” (or “Each person purchasing personal life insurance must have a date of birth”) and an advice: “Each person purchasing only home insurance may not have a date of birth”.
    In fact the original assertion (“Each person has a date of birth”) still applies in the world view of the business, even to persons purchasing only home insurance. What is required is an additional constraint, which may be worded in one of the following forms “Each person who purchases personal life insurance must supply the date of birth of that person.” or “Each application for personal life insurance must specify the date of birth of the applicant.” and an advice “A person who purchases home insurance need not supply the date of birth of that person.”

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue: Problematic necessity in 8.5.2

  • Key: SBVR14-10
  • Legacy Issue Number: 18824
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.5.2, the following Necessity appears:

    Necessity: If a concept[sub]1 is coextensive with a concept[sub]2 then the extension of the concept[sub]1 is the extension of the concept[sub]2.

    (where [sub] is used to show subscripts).

    There are three problems with this Necessity:

    1. This Necessity just restates the definition of ‘concept is coextensive with concept’ in 8.1.1.1. It adds nothing.

    2. It is the only occurrence in SBVR v1.1 of the use of a subscript outside of a placeholder term, and that use is not defined in Annex C.

    3. The meaning of the article ‘a’ before concept (1) and concept (2) is universal in this case, not existential, which contradicts Annex C.

    Delete it!

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

"thing has property".

  • Key: SBVR14-18
  • Legacy Issue Number: 16727
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    (a) Clause 11 should include the verb concept "thing has property". This verb concept should appear in figure 11.5.

    (b) Property needs to be indicated as an abstract concept in Clause 13 (since it is in the universe of discourse, not the model).

  • Reported: SBVR 1.1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

'closed semantic formulation' is not properly defined

  • Key: SBVR14-14
  • Legacy Issue Number: 19713
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR Clause 9.2 defines: ‘semantic formulation’ as ‘a conceptual structure of meaning’.

    And then closed semantic formulation is defined as 'semantic formulation that includes no variable without binding'

    But no SBVR concept associates semantic formulation (in general) with variables. And some other conceptual structure of meaning, e.g., phrased in SBVR structured English or OWL, might not have any notion of ‘variable’ or ‘binding’ at all. So the definition appeals to a delimiting characteristic that may be meaningless for the general concept, and thereby admit semantic formulations that were not intended.

    Every structure of meaning presumably formulates a meaning; otherwise it formulates nonsense. But clause 9.2 has only ‘closed semantic formulation formulates meaning’, which suggests that open semantic formulations (involving free variables) formulate nonsense. That is simply not true of a ‘structure of meaning’ formulated in CLIF. What is really meant is that LRMV ‘closed logical formulations’ formulate propositions, and LRMV ‘closed projections’ formulate concepts. But those are special cases.

    The definition of ‘closed semantic formulation’ should be ‘closed logical formulation or closed projection’, which makes it clearly an LRMV concept, and then those concepts must state their relationship to free variables.

    The general idea for all conceptual structures of meaning is ‘semantic formulation formulates meaning’, which would allow other semantic formulations, e.g., in SBVR SE, OWL, etc., to be related to the meanings they formulate. If an LRMV projection or logical formulation that is not closed does not formulate a meaning, that is a LRMV Necessity for those specific concepts.

    Finally, note that a (clause 8) Definition is always a representation of a conceptual structure of meaning that formulates a concept. The important idea in ‘definition serves as designation’ in clause 11.2.3 is that the representation of a semantic formulation (a conceptual structure of meaning) is used to refer to the concept itself, rather than just the properties contained in the formulation. This idea of semantic formulation as conceptual structure of meaning is fundamental to the notion ‘definition’, and should not be buried in the LRMV.

  • Reported: SBVR 1.1 — Wed, 21 Jan 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

qualifiers whose subject is a property of the referent

  • Key: SBVR14-17
  • Legacy Issue Number: 19728
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The title of this issue is an example of common problem in SBVR Structured English.

    Impossibility: An SBVR SE statement contains a qualifier whose subject is a property of the referent.

    Given the verb concept 'sequence has member' aka 'thing is member of sequence', how is the following definition to be written in SBVR SE: "sequence each member of which is a time point"?

    The referent of the pronoun 'which' is the sequence, but the subject of the qualifier clause is a quantified property of the referent. But SBVR SE only permits the (anaphor) pronoun to be 'that' or 'who' and apparently requires it to follow the referent noun immediately.

    SBVR SE does not permit: "sequence of which each member is a time point".

    And it does not provide a 'where' or 'such that' construct that would allow the back reference to be represented by 'the sequence', as in: "sequence where each member of the sequence is a time point".

    Even the simpler case of a reference to a unique property of the referent in the qualifier clause --"shipment whose delivery date has passed" – requires a circumlocution ("shipment that has a delivery date that has passed"), because 'whose' is not an SBVR SE keyword. And the cascading 'that's interfere with the expression of compound qualifiers (using 'and that …').

    In our experience, this shortcoming significantly limits the clear expression of definitions and rules in SBVR SE.

  • Reported: SBVR 1.1 — Sat, 21 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR SE does not support the DateTime usage of subscripts

  • Key: SBVR14-16
  • Legacy Issue Number: 18825
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The Date Time Vocabulary specification contains several Definitions and Necessities that use subscripted terms, e.g.,

    Necessity: For each time interval(2) and each time interval(3) that finishes time interval(2), the duration of the time interval(1) that starts time interval(2) complementing time interval(3) is equal to the duration of time interval(2) minus the duration of time interval(3).

    time point1 to time point2 specifies time period

    Definition: time point(1) is the first time point of a time point sequence and time point(2) is the

    last time point of the time point sequence and there is a time point(3) that is just before time point(2) in

    the time point sequence and time point(1) through time point(3) specifies the time period

    Each case introduces a subscripted term that is used to denote the same ‘referent’ ‘thing’ elsewhere in the definition/necessity. In the Necessity, all the subscripts are introduced terms. In the Definition, time point(1) and time point(2) refer to placeholders in the verb concept wording being defined, but time point(3) is an introduced term. These introduced terms were patterned on a usage of subscripts in SBVR clause 8.5.2 that introduces similar “local names”. SBVR Annex C does not describe such usages. Without them, it is not possible to formulate these definitions and necessities in SBVR Structured English.

    Is it the intent of SBVR SE to support such usages? If yes, then SBVR Annex C needs wording to support them. If no, then DTV needs to convert these formulations to plain text.

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS

  • Key: SBVR14-22
  • Legacy Issue Number: 19518
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Annex B, references to diagramming conventions

    Annex B has a number of references to diagramming conventions that are too colloquial. The implication is that the reader is already familiar with the UML or CDG diagramming conventions, but this is not appropriate, since the whole point of the Annex is to be explanatory at this level. For example:

    B.3.5. “UML’s arrow style for ‘instantiation’” What is this arrow style? Where is it explained?

    B.3.5. The notation has been adapted from standard UML notation to make it more ‘business friendly’. For example, in UML, in instance (‘object’) would be labeled as, Canada: country.

    This information does not belong here, but in Annex C.

    B.3.5. “the box in box style”. Where is this explained? Is it UML or CDG?

    Suggested solution: when referencing UML or CDG diagramming conventions, do not attempt to be descriptive of symbols or drawing conventions, but use ‘base’ references instead: all the diagramming information should be in one place, ie., in Annex C or I respectively, but not in Annex B. Make sure the same format is used for all references to Annexes C and I, and that the difference between the two diagramming techniques is signposted adequately. An even better, more practical solution would be in each case to depict the symbol(s) involved and to refer to the appropriate paragraph in Annex C or I for any textual explanation. This would cause duplication of symbols between the Annexes but it would make Annex B much more helpful.

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

the scope/namespace of a placeholder

  • Key: SBVR14-21
  • Legacy Issue Number: 19124
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.4.4, there is a necessity in the entry for ‘placeholder’: “Each placeholder is in exactly one verb concept wording”. Now, immediately before section 8.4.4, in the entry for ‘statement expresses proposition’, there is a synonymous form: ‘proposition has statement’. So, ‘statement’ is the text of two placeholders. A.4.12 (Synonymous forms) tries to say that these two different placeholders refer to the same verb concept role, but the statement is garbled: “The ones using the same designation as placeholders of the primary form represent the corresponding verb concept roles…” The ‘designation used by a placeholder’ is the representation of the range concept by a signifier for that concept, per 8.4.4 ‘placeholder uses designation’. What is intended here is: “A placeholder that has the same expression as a placeholder of the primary verb concept wording represents the same verb concept role.”

    Further, in that same example entry, there is a Definition: “the statement represents the proposition”. According to A.4.2.3, the expression ‘statement’ refers to a placeholder in the verb concept wording, but that is ambiguous, since there are two verb concept wordings. That text should say the primary verb concept wording, so as to disambiguate the reference.

    Again, in A.4.12, the following sentence appears: “The order of placeholders for verb concept roles can be different.” What does that mean? By the necessity above, the placeholders are different, so they cannot be reordered. The intent is that the relative positions of the placeholders for the same verb concept role may be different.

    Finally, all of this is an elaborate convention to maintain the given Necessity. It seems that it would be much easier to make the placeholder a representation of the verb concept role throughout the terminological entry, as distinct from having it denote the verb concept role in the primary entry and in the Definition(s), but not in Synonymous forms, Descriptions, Notes, etc. The only function of that Necessity is to make a single ternary fact type: “Verb concept wording has placeholder at starting character position” into two binary fact types that each convey half the concept. A great deal of effort is expended to explain use of a business-friendly syntax that violates the stated model of a purely syntactic concept – the intent is that the placeholder expression represents the same verb concept role throughout the entry. And verb concept wordings are ONLY about expressions. The underlying problem is that the concept ‘terminological entry’ is not part of the clause 8 vocabulary, and is therefore not available to be the scope of a placeholder. But then, the concept ‘primary verb concept wording’ is not in the clause 8 vocabulary, either.

  • Reported: SBVR 1.1 — Mon, 25 Nov 2013 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

The use of UML described in the Annex does not represent any known UML tool nor the UML specification

  • Key: SBVR14-8
  • Legacy Issue Number: 19680
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The use of UML described in the Annex does not represent any known UML tool nor the UML specification. The examples are UML-like diagrams presumably created with a drawing tool.

    • In Figure C.1 the right hand class is shown with 2 names and an italicized label “also:” – this is not supported.
    • Section C.3 and Figure C.2: in UML, Instance diagrams only the class and not the instance name is ever underlined
    • Figure 6.3 is not a valid UML diagram if the lower shapes are InstanceSpecifications: they should have a colon after the names which should not be underlined. The use of Dependencies is not valid for class membership.
    • Figure 6.4 is not valid – an association may have only one name optionally accompanied by one direction indicator.
    • Figure C.7, C.12: In general UML does not include the notion of underline/font within a name: it’s modeled only as a text string.
    • Figure C.9 is not valid – one cannot have an association with only one end.
    • C.7.1, Figure 14: these 2 renderings are semantically identical in UML and serialized the same in XMI. UML has the ability to render the distinction using a GeneralizationSet with isDisjoint – so why not use that?
    • C.15: powertypes should not have a name before the colon in UML, though the property of type “branch type” may
    • C.9, Figure C.17: the dashed lien to association diamond is not valid in UML
  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Distinguishing the senses of infinitive and present tense

  • Key: SBVR14-25
  • Legacy Issue Number: 17571
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    New SBV issue: Distinguishing the senses of infinitive and present tense
    From Don Baisley

    There are many verbs for which the present tense of a verb conveys a particularly different sense than the infinitive. The difference I refer to is not about "the present time", but about "occurring at least occasionally". For example, the statement that "Pam surfs" (present tense) combines the meaning of "to surf" (the infinitive) and the meaning that “it happens at least occasionally”.

    For such verbs, there is a challenge when using SBVR's typical pattern of defining verb concepts in the present tense. It tends to conflate the infinitive sense of a verb with the different sense meant by the present tense. That conflation causes problems. This is not an issue for ORM or other approaches that do not try to support natural language tense in a generic way. The problem has no apparent impact for many verbs where the present tense sense of "occurring at least occasionally" is inconsequential or inapplicable. The problem is especially troublesome for eventive verbs. Most SBVR verbs are stative, so the problem has tended to go unnoticed in the SBVR vocabulary itself.
    If supporting tense in a generic way, in logical formulations, the other tenses should be built on objectifications that start with the infinitive sense of a verb, not with the present tense. Also, modal operations like obligation build on the infinitive sense.

    For examples below, I define verb concept forms for generic "tense" concepts using the verb "occurs" (where the there is a role that ranges over the concept 'state of affairs'). The choices of signifier and form are arbitrary (not necessary), but seem to convey the sense of the tenses naturally.

    Example:
    'person surfs' (present tense)
    'person surf' (the infinitive sense)

    Where someone puts 'person surfs' in a business glossary, there is an underlying verb concept that has the sense of "to surf", the infinitive. I show it here in examples as 'person surf' (leaving out the infintizing "to"). This underlying verb concept is necessary to correctly formulate other tenses, and even necessary to formulate use of the present tense in some cases, which I will show later.

    Here are several examples of statements and interpretations using generic tense concepts built on the verb "occur". To be terse, I show objectification using brackets.

    Pam surfs.
    [Pam surf] occurs

    Pam is surfing.
    [Pam surf] is occurring

    Pam was surfing.
    [Pam surf] was occurring

    Pam has been surfing.
    [Pam surf] has been occurring

    Pam surfed.
    [Pam surf] occurred

    Pam will be surfing.
    [Pam surf] will be occurring

    Pam will surf.
    [Pam surf] will occur

    Pam will have been surfing.
    [Pam surf] will have been occurring

    The second example above, "Pam is surfing", can serve to illustrate the need to build on the infinitive rather than the present tense sense. To build on the present tense would be to say the thing that “is occurring” is Pam surfing at least occasionally, which is incorrect. The present continuous and other tenses do not include the present tense sense of occurring at least occasionally, so they cannot rightly be built upon a concept that conveys that sense.

    I said above I would show where the infinitive sense is sometimes needed even for the present tense. Here is a case where the infinitive 'person surf' concept is needed to formulate a statement that uses "surf" only in the present tense:

    Pam talks while she surfs.

    Wrong Interpretation I1: [Pam surfs] occurs while [Pam talks] occurs

    I1 misses the key sense of the statement, because [Pam surfs] (present tense) means that surfing is something Pam does at least occasionally and [Pam talks] means that talking is something that Pam does at least occasionally. I1 applies 'state of affairs1 occurs while state of affairs2 occurs' to the wrong states of affairs (the states in which Pam occasionally surfs and Pam occasionally talks).

    Right Interpretation I2: [[Pam surf] occur while [Pam talk] occur] occurs

    I2 correctly factors out the tense and applies it at an outer level (as we often do with modal operations). The conjunction joins objectifications of the underlying sense of "to surf" and "to talk" without the added meaning of the present tense (that the surfing or talking is at least occasional). The sense of present tense (happening at least occasionally) is then added at the outside where it applies to the simultaneous actions.

    SBVR does not prevent verbs concepts from being defined in glossaries in the infinitive , as is typical of dictionary definitions of verbs. That approach has always been available. But that approach is not used in SBVR’s own glossary and examples. In general, the sense of “occurs at least occasionally” is absent from SBVR’s own verb concepts, so the distinction is unimportant. But business rules and facts run into the problem. E.g., a EU-Rent rule about whether a renter smokes vs. a rule about whether he is smoking when in a rental car.

    Recommendation:

    It will be best to resolve this in a way that does not disturb the business-friendly approach of showing verb concept readings in the present tense. It might be possible to define a pattern in SBVR Structured English by which verb concepts with an infinitive sense are implied where present tense versions are explicitly presented in a glossary.

    Examples of formulations need to show the distinction. Existing examples should be examined and fixed as needed. New formulation examples might be helpful to demonstrate using generic tense concepts to build on a root verb concept.
    None of this changes the meaning of 'state of affairs' or 'objectification', but understanding this issue and its solution might help bring clarity to some of the examples that have been discussed.

  • Reported: SBVR 1.1 — Tue, 28 Aug 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Define that Clause 10 ‘Fact Models’ are by Default Closed World Models

  • Key: SBVR14-23
  • Legacy Issue Number: 16683
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
    The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns:
    1. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption.
    The proposed resolution is:
    1. Define that Clause 10 ‘fact models’ are by default closed world models

  • Reported: SBVR 1.1 — Mon, 14 Nov 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Updating Annex F "The RuleSpeak Business Rule Notation

  • Key: SBVR14-24
  • Legacy Issue Number: 18621
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The problem statement: The Annex is out of date with respect to RuleSpeak notation, probably the newly released version of EU-Rent, and perhaps newer aspects of SBVR itself.

  • Reported: SBVR 1.1 — Fri, 5 Apr 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Section C.10 states that the default assumed multiplicity for an unannotated association end is *

  • Key: SBVR14-31
  • Legacy Issue Number: 19685
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section C.10 states that the default assumed multiplicity for an unannotated association end is *. That’s a terrible idea since the UML default is 1 (i.e. 1..1).

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

extending an adopted concept

  • Key: SBVR14-33
  • Legacy Issue Number: 19433
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In the SBVR Meaning and Representation Vocabulary, the entries for ‘noun concept’ and ‘verb concept’ contain reference schemes that refer to the concept ‘closed projection’ and related fact types that do not appear in the MRV itself. In the MRV per se, these are undefined terms. I am told, but do not find in SBVR v1.2, that if only the MRV is implemented, such Reference Schemes are ignored, while clause 13.4.2 explicitly says that the UML/MOF classes must have the corresponding properties. If properly documented, this approach may be fine for the specification of SBVR itself. In general, however, this approach assumes that the speech community that develops a formal vocabulary is omniscient about reference schemes used by speech communities who ADOPT the original vocabulary. In general, an adopting community might add new fact types about an adopted concept that result in new reference schemes for the concept. Also, the adopting community might add new synonyms or synonymous forms for an adopted concept. There is no reason to suppose that the original speech community is even aware of the adoption, and there is no way these additional elements can have been present in the original terminological entry. So, the approach used in SBVR itself is unworkable for general use.

    When a concept is adopted by another vocabulary, it should be expressly possible for the “adopting entry” to include new reference schemes and synonymous forms, and possibly other elements of a terminological entry.

    Further, if such a mechanism is introduced, the SBVR vocabularies themselves should use it, rather than incorporating reference schemes in the base terminology entry that refer to fact types that don’t exist in that vocabulary per se. For example, the LRMV should formally adopt the MRV concepts and add the reference schemes involving closed projections in the ADOPTING ‘noun concept’ and ‘verb concept’ entries.

  • Reported: SBVR 1.1 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Correct the scope of placeholder terms

  • Key: SBVR14-26
  • Legacy Issue Number: 18826
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.3.4, in the entry for ‘placeholder’, it is stated that a placeholder exists in only one verb concept wording, and it refers to some role of the verb concept in that wording. It follows that the two placeholders spelled ‘concept1’ in ‘concept1 specializes concept2’ and in the Synonymous form: ‘concept2 generalizes concept1’ (in 8.1.1.1) refer to two roles of the verb concept being defined. Since these two placeholders spelled ‘concept1’ are different designations, how are they related?

    Annex C.3.1 does not say anything about the relationship between placeholders in the primary verb concept wording and placeholders in synonymous forms. (It just says something about subscripts being used to differentiate placeholders.) The intent is that the placeholder expression represents the SAME verb concept role in ALL primary and synonymous forms. That is, the placeholder is the SAME DESIGNATION in all verb concept wordings for the same verb concept. The text of 8.3.4 contradicts this intent, saying that the placeholder only has meaning within a given verb concept wording. If the text is correct, it is necessary to state some rule about the meaning of the same placeholder expression (the distinct designation) in the different synonymous forms.

    Further, in the Definition of ‘concept1 specifies concept2’, the expression ‘concept1’ appears. Since that expression only refers to a verb concept role within a verb concept wording, it is utterly meaningless in the Definition! There are no placeholders in a Definition, and ‘concept1’ is not a signifier for any concept. And yet, the intent is that ‘concept1’ in the Definition is the placeholder expression and is intended to be interpreted as a reference to the thing that plays that verb concept role in an actuality of ‘concept1 specializes concept2’. Annex C says nothing about the use of placeholder expressions in Definitions, and 8.3.4 makes these usages meaningless, but they appear in every verb concept definition in SBVR.

    It appears that the real intent is that a placeholder expression refers to one and the same verb concept role throughout the terminological entry for the verb concept, including at least all synonymous forms and definitions. Whether it also refers to the verb concept role in embedded Necessities needs to be clarified (it is not clear that SBVR ever assumes that, but DTV apparently does). The only aspect of a placeholder that is specific to a given verb concept wording is the ‘starting character position’, which suggests only that that relationship should be ternary, i.e., placeholder has starting character position in verb concept wording.

  • Reported: SBVR 1.1 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

'categorization scheme' and 'categorization type' are related

  • Key: SBVR14-27
  • Legacy Issue Number: 19549
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    'categorization scheme' and 'categorization type' are related, yet SBVR says nothing about this relationship.

    Upon comparing the entries for these terms in 11.2.2.3, it is seen they are coextensive; the extension of each is a set of concepts; they could be defined having the same extensions. Compare the examples in each entry.

    A difference is that categorization schemes are restricted to categorizing general concepts, whereas categorizations types are not so restricted.

    Another difference is that categorization schemes define partitionings, whereas categorization type are not so restricted.

    Accordingly, it seems like the definition should be:
    categorization scheme: categorization type that defines a partitioning of one or more general concepts.

    'categorization type' is defined in such a way that it is not meaningfully different from 'concept type' (p.22); compare the definitions on p.22 with that on p.149. A concept, by its very nature and definition, defines a category of things. See 'concept', p.21. 'categorization type' should be made a synonym of 'concept type'.

    'Categorization scheme' is involved in the verb concept 'categorization scheme is for general concept'. The general concept(s) are inferred by the general concepts of the concepts in a categorization scheme or a categorization type coextensive with the it. This verb concept is not necessary.

    'Categorization scheme' is involved in verb concept 'categorization scheme contains category'. Either can be defined to have the same extension, by an extensive definition. This verb concept is not necessary.

    The two verb concepts mentioned above are redundant; their purpose is more simply served by providing extensional definitions of categorization types and categorization schemes, as suggested by the examples. They could be deprecated or deleted, as they do not add any new information to a model. They increase the complexity and maintenance burden on the model.

    The changes suggested here would affect Figure 11.2 on p.146.

  • Reported: SBVR 1.2 — Sun, 27 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

ANNEX G COLOR-CODED CONCEPT NOT DECLARED

  • Key: SBVR14-28
  • Legacy Issue Number: 19520
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Annex G, G 6.2.8, lemma ‘rental is open’

    There is a color-coded occurrence of ‘end date/time is in the future’ but there is no such declared concept.

    Discussion: The way this Annex has been set up suggests that each colour-coding is meant to imply that the colour-coded concept is either explicitly listed or specifically adopted from a different vocabulary.

    The only like concept is in G.8.5, ‘period is future’. SBVR 1.1 Annex E used to have a concept ‘date/time is in the future’.

  • Reported: SBVR 1.2 — Sat, 12 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR should cover the concept of IRI as well as/instead of URI.

  • Key: SBVR14-32
  • Legacy Issue Number: 19677
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SBVR should cover the concept of IRI as well as/instead of URI.

  • Reported: SBVR 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Definition of "categorization scheme contains category"

  • Key: SBVR14-30
  • Legacy Issue Number: 19631
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The current definition of "categorization scheme contains category" is poorly constructed and therefore hard to understand.

    Current Definition: the category is included in the categorization scheme as one of the categories divided into by the scheme

    Perhaps the definition means the following?

    Possible Revision: the category is included in the categorization scheme as one of the categories into which the scheme divides things

    I think a better definition would perhaps include the verb concept " ... classifies ... ".

  • Reported: SBVR 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Issue "fact type role is in fact type"

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

    In clause 8.1.1.1, we have "fact type has role", with a synonymous form
    "fact type role is in fact type". Figure 8.2 also shows "fact type role
    is in fact type".

    Issue: a "fact type role" is a specialization of "role", so it is confusing
    to see the preferred form of the fact type use "role" but the synonymous
    form use "fact type role". Especially because figure 8.2 seems to indicate
    that a "fact type role" is in a fact type but that a "role" is explicitly
    not in a fact type. So the figure appears to contradict "fact type has
    role".

    Recommendation: I think the preferred entry is wrong, and should be changed
    to "fact type has fact type role".

  • Reported: SBVR 1.0 — Mon, 12 May 2008 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Inadequate, Overlapping and Disorganized Specs for Sets and Collections of Concepts, Meanings, and Representations

  • Key: SBVR14-41
  • Legacy Issue Number: 17542
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Inadequate, Overlapping and Disorganized Specifications for Sets and Collections of Concepts, Meanings, and Representations

    Problem:

    Assumptions

    Two assumptions are basic to the eight points of this problem statement:
    • SBVR must provide a business vocabulary for business people and business analysts to talk clearly and precisely about terminological dictionaries and rulebooks and what they represent.
    • The various aspects of this Issue must be addressed holistically. They can be resolved only by unifying, normalizing and completing all related specifications. (Thus, the need for a new unifying Issue.)

    Problems

    1. A known problem in SBVR is that the current version does not make clear what the fundamental unit of interoperability in SBVR is. No matter how that issue is resolved the unit should:
    • Be identifiable from a business point of view.
    • Not always have to be the full, non-redundant set of concepts, meanings, or representations.
    The existing content of Clause 11 does not currently provide an adequate term for the second of these. This Issue proposes “collection” for that purpose.

    Note: The term “collection” in the following discussion is never actually used on its own. Rather, it always appears with qualification – e.g., ‘collection of representations’.

    2. Another known problem in SBVR centers on the use of the word “container” in e-mails and discussion. (Use of the signifier “container” per se is not part of this Issue.) It is unclear (to some) whether “container” refers to the ‘thing that contains’, to ‘what is contained’, or to both. The term is easily misused and misinterpreted. Also there are many variations of what is (or could be) contained (e.g., sets, collections, etc.). SBVR needs a precise, non-overlapping vocabulary for these things from a business point of view.

    3. Another known problem in SBVR is that the existing content of Clause 11.2.2.3 “communication content” (a.k.a. “document content”) is not adequate for all purposes to which it might be put. SBVR needs a richer (but still minimal) set of concepts to address this area.

    4. Certain existing terms in the existing content of Clause 11 (e.g., ‘terminological dictionary’ and ‘rulebook’) conflate ‘completeness and non-redundancy’ (i.e., being a set) with ‘primary purpose’ or ‘essence’. This conflation needs to be eliminated. In the real world for example, a rulebook does not have to be complete (e.g., it may contain only what is appropriate for a given audience), and it does not have to be non-redundant. It can contain the same rule statements in different sections, the intent being to provide the greatest clarity when being used by members of some speech community.

    5. SBVR currently provides no means to talk about a collection of representations that is complete with respect to one or more specific concepts, but not complete with respect to all concepts in the body of shared meanings. Example: A listing of all baseball rules that address the concepts “strike” and “ball” only.

    6. With respect to interoperability there is a minimum set of pragmatic business specifications (such as completeness, effective date, shelf life, mutability, etc.) needed for things communicated. SBVR does not currently support such specifications.

    Note: There is no intent or need to get into document management or rule management. The dividing line is this: SBVR does not get into organizational issues (e.g., author, sponsor, reviewer, etc.), workflow issues (e.g., status, pre-approval distribution, sign-off, impact assessment, etc.), motivation (rationale, goals, risks), etc. SBVR must, however, provide minimum viability criteria for any sets or collections communicated. Otherwise the communicated content is not really useful and trustworthy on the receiving end. Consequently the purpose of interoperability is defeated.

    7. Certain kinds of collections relevant to inter-operability are missing from the current content of Clause 11 – most notably ‘record’ (not IT ‘records’). Proper incorporation of this and other kinds of collections is needed.

    8. Issue 16103, which addresses “speech community representation”, needs to be worked into a holistic solution.

  • Reported: SBVR 1.1 — Tue, 7 Aug 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition

  • Key: SBVR14-35
  • Legacy Issue Number: 14029
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    There two closely related flaws in SBVR Clause 8.1:
    1. a conflation of 'proposition' with "'performative' + 'proposition'"
    2. a disconnect between 'concept' and its subcategories and 'proposition' and its subcategories which are really one concept or two perspectives on the same thing.

    Conflation of 'Proposition' with "'Performative' + 'Proposition'"

    • 'proposition' meaning that is true or false (the "semantic content"
      part in 'proposition' + performative')
    • 'proposition' + 'performative' (where the 'performative' part is the
      "communicative function") e.g.:

    o proposition + "deontic" performative = behavioral guidance
    o proposition + "alethic" performative = definitional rule
    o proposition + "taken to be true" performative = fact

    The core meanings are in the propositions which are then made into something else by combination with a particular performative. This is why there is no reason to include the concept 'fact' at all in Clauses 8, 9 11 or 12 except to support the formulation of fact statements – which are really out of scope for a standard for "concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definiton-centric dictionaries". Examples of general concepts can be provided by using names and fact type forms of individual concepts without needing to turn the individual concepts into facts (by adding the performative "taken to be true") so that fact statements can be used as examples.

    Disconnect between 'Concept' and its Subcategories and 'Proposition' and its Subcategories

    Clause 8.1 defines two concepts ('concept' and 'proposition') as if they were completely separate things when in fact they are at most two perspectives on the same thing:

    · general noun concept = open (existential) proposition
    · individual noun concept = closed (existential) proposition
    · general verb concept = open (relational) proposition
    · individual verb concept = closed (relational) proposition
    (this is the verb concept that corresponds to a given state of affairs)

    Resolution:
    Remove the Conflation of 'Proposition' with "'Performative' + 'Proposition'"
    1. Add the concept (definition) for "performative" and term it "communicative function" [3.7] as per ISO/CD 24617-2 "Language resource management – Semantic annotation framework (SemAF) – Part 2: Dialogue acts".
    2. Add the three performative (communicative function) individual concepts used in SBVR: "taken to be true", "true by definition", and behavioral guidance.
    3. Add the concept (definition) for "performative' + proposition" and term it "dialogue act" [3.2], as per ISO/CD 24617-2.
    4. Show fact, behavioral guidance, and definitional guidance as concept type dialogue act with their respective performative (communicative function) instances instead of their current definition as subcategories of proposition.
    5. Review all references to 'proposition' to determine whether the intended reference is to semantic content or to a discourse act (proposition + performative); e. g. statement expresses dialogue act (not proposition).
    Remove the Disconnect between 'Concept' and its Subcategories and 'Proposition' and its Subcategories
    1. Add open/closed proposition categories, and existential/relational proposition categories.
    2. Fix the subcategories of concept to fit the above, and have both 'concept' and 'proposition' as more general concepts for the subcategories.
    3. Replace all current uses of 'individual concept' to 'individual noun concept'.

    Revised Text:
    …to follow, including redrawn diagram(s)

  • Reported: SBVR 1.0 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Use of morphological variants of terms is inadequately addressed

  • Key: SBVR14-42
  • Legacy Issue Number: 17269
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR apparently assume that business terms are composed of natural language words, and that those words may have multiple morphemes that are nonetheless the same word and the same term. That is, a vocabulary term like 'purchase contract' may also have the form 'purchase contracts', and a vocabulary term like 'is owned by' may be expressed as 'has been owned by'. But SBVR says nothing about any of this in defining 'designation' or 'signifier'.
    When a signifier for the same concept is in a formal language like OWL or CLIF, this idea of multiple morphemes is not (usually) part of the language syntax. So this should be carefully addressed.

    For the SBVR Structured English language, Annex C.1 explicitly says that these alternate morphemes are "implicitly available for use", which may mean they are treated as equivalent, or just that they are recognized as uses of the same designation.

    In natural language, such morphemes carry additional meaning , e.g., plurality or tense or mood. And a morphological variant of the same designation may or may not carry additional meaning, This is important, because SBVR examples assume that plurals are conventional and irrelevant, but the Date Time Vocabulary says that the use of verb tenses in natural language conveys indexical time intent. That is:
    'John is in London' and 'John was in London' have different meanings in English. Do they have different meanings in SBVR SE?
    And if so, do they always have different meanings? Natural language convention requires that a statement that dates a past event uses the past tense, e.g., 'John was in London in 2008.' Is it meaningful in SBVR SE to say (in 2012) 'John is in London in 2008'? And does that mean a different proposition from 'John was in London in 2008'?

  • Reported: SBVR 1.1 — Fri, 23 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Precedence of operators

  • Key: SBVR14-38
  • Legacy Issue Number: 17243
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    The precedence of logical operators ("and", "or", etc.) in Structure English is unspecified which may make some rules ambiguous. Furthermore, they sould be called "operators" and not "operations".

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Fix the objectification example

  • Key: SBVR14-36
  • Legacy Issue Number: 18703
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The objectification example “EU-Rent reviews each corporate account at EU-Rent Headquarters” in SBVR v1.1 clause 9.2.7 (as modified per the resolution to issue 16309), is expressed in the usual sequence of sentences. The formal logic interpretation of those sentences is:
    For each corporate account A, there exists a state of affairs S such that

    S objectifies “EU-Rent reviews A”,

    and S occurs at EU Rent HQ.

    Now, per Clause 8 there is only one such state of affairs; and its existence is a given, that is, for every proposition of the form ‘company reviews account’, the corresponding state of affairs necessarily exists. But nothing is said here about that state of affairs being actual. Moreover, since there is probably more than one “occurrence” of that state of affairs, the definition of ‘state of affairs occurs at place’ would be less than obvious. Or is it the intent that there is only one review of each corporate account? Whatever it means for an abstract state of affairs (that might be a set, including the empty set) to ‘occur at a place’, it is not clear, and it is important to the example of objectification – what is the state of affairs that it produces.

    In SBVR v1.0, the variable S ranges over the verb concept ‘company reviews account’, because the instances of the verb concept were then said to be actualities. The resolution of Issue 14849 makes instances of a verb concept ‘states of affairs’ instead of actualities. But states of affairs need not be actual. It is obvious that some thought was given to this example, because v1.1 changed it. What is not clear is whether it is any closer to what was intended.

    A definition of ‘state of affairs occurs at place’ should probably follow the DTV pattern for ‘state of affairs occurs at time’. In DTV parlance, what was intended is: Each occurrence of the state of affairs “EU Rent reviews A” ‘occurs at’ EU Rent HQ. But SBVR lacks the vocabulary to express that.

  • Reported: SBVR 1.1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Annex F is in the wrong specification

  • Key: SBVR14-43
  • Legacy Issue Number: 16871
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Date/Time Annex F is titled: Annex F Simplified Syntax for Logical Formulations.

    First, the title is wrong. The Date/Time standard contains logical formulations in OCL and CLIF. This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9. It should be titled: Simplified Syntax for SBVR Logical Formulations.

    Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification. If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it. If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it.
    Recommendation: Delete Annex F and refer to the OMG (SBVR) specification that actually includes it. Otherwise, use a standardized SBVR notation in Annex E.
    The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification – a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification.

  • Reported: SBVR 1.1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR ISSUE - definite description

  • Key: SBVR14-44
  • Legacy Issue Number: 16527
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Definite descriptions do not always define individual concepts

    The entry for ‘definite description’ in SBVR 11.1.3 includes this structural rule:

    Necessity: Each definite description is the definition of an individual concept.

    The rule is incorrect. A definite description defining a concept in a schema might well be taken as defining an individual concept, but a definite description within a statement of a fact in a model need not define an individual concept because it need not identify the same individual in all possible worlds. It would identify an individual in the world described by the fact. Similarly, a definite description in the context of a rule statement might identify a single individual in each situation addressed by the rule, but not necessarily the same individual in all possible worlds. E.g., “the previous calendar month” definitely describes one month, but which month it describes depends on the current month, which can vary across possible worlds.

    Also, a note should be added to the entry for “definite description” to point out that the one thing defined by a definite description can be a set (e.g., “the cars owned by EU-Rent”, which, by the way, is not the same set in all possible worlds).

  • Reported: SBVR 1.0 — Tue, 6 Sep 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue: representations of propositions by name

  • Key: SBVR14-45
  • Legacy Issue Number: 19715
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Many business rules, laws of nature, etc., are given ‘names’ that are representations of those rules/laws as ‘individual concepts’.

    For example, “Murphy’s Law” represents the proposition: Anything that can go wrong will. Similarly, “Newton’s First Law of Motion” represents the proposition: A body at rest will stay at rest unless acted on by an outside force. (Laws like “Sarbanes-Oxley” are not just propositions, they are actually bodies of guidance.)

    What is the SBVR relationship between these signifier expressions and the propositions? The expressions are very like designations, there are different expressions in different languages, and a few such ‘laws’ are known by different names in different subject areas. But it does not appear that they can be contained in Vocabularies or terminological dictionaries.

    These representations cannot be ‘designations’. Propositions cannot be (individual) concepts, unless the dichotomy of ‘meaning’ (= concept xor proposition) is not valid. And they are clearly not ‘statements’.

  • Reported: SBVR 1.1 — Mon, 2 Feb 2015 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”.

  • Key: SBVR14-39
  • Legacy Issue Number: 19684
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”.

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue: Mis-use of Date-Time Concepts

  • Key: SBVR14-34
  • Legacy Issue Number: 19015
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR 1.2 beta annex G (EU Rent Example) adopts concepts from the Date-Time Vocabulary (DTV) but deliberately gives them names that are both inconsistent with DTV and in fact are confusingly similar to the names of other concepts that are defined in DTV. Although any business can use any vocabulary terms desired, an OMG standard should maintain consistency with other OMG vocabularies for reasons of quality and to avoid user confusion. Especially a portion of a standard that is specifically intended to "to provide an aid to help them understand the specification " (annex G.2).

    The Annex is also inconsistent in its own terminology with respect to dates and times. For example, "maximum rental period" (Annex G.6.6) is a kind of "duration" even though G.8.6 defines "period" as a kind of "time interval" and a "rental period" (G.6.8.3) is a kind of "period".

    This annex also defines its own concepts that relate states of affairs to time, and for quantities – rather than using the corresponding concepts defined by the Date-Time Vocabulary. It fails to give definitions for these concepts, which means they are subject to varying interpretations. The example would be stronger if it used the carefully worked-out concepts defined in the Date-Time Vocabulary.

    Specifically:

    • Annex G.8.4 specifies, but does not define, concepts such as "state of affairs at point in time". 'Point in time' is a synonym for Date-Time's 'time point', which is a time interval that is a single member of a time scale. The authors of this Annex apparently did not understand that the duration of a time point depends upon the granularity of the time scale that is used. Consider a time scale of years. What does it mean to say that a "state of affairs at [a year]? Is the state of affairs "at" throughout the year or just during some portion of the year. The Annex G concept is fundamentally ambiguous.
    • Annex G.8.5 defines concepts such as "period", "period1 overlaps period2", and many others, using the definitions from Date-Time's "time interval", "time interval1 overlaps time interval2", etc., but with its own terms. This is particularly confusing because Date-Time has other concepts with similar names, such as "time period". (I do not object to terms that are clearly business specific, such as "rental period".) Moreover, the Annex probably should be built on the DTV "time period" concept, rather than "time interval". The discussion of the "Rental Time Unit" makes it clear that EU-Rent is interested in periods that are based on calendars (i.e. DTV "time period") rather than arbitrary periods ("time interval"). Probably the authors of the Annex did not understand the difference.
    • Annex G.8.5 defines a concept "date-time1 is before date-time2" that is unnecessary in light of the fact that a "date-time" is a kind of "time coordinate", which is a representation of a "time interval". The existing "time interval1 precedes time interval2" is applicable to all time coordinates, in the same way that representations of quantities (e.g. "5") may be used in instance of the verb concept "quantity1 is less than quantity2".
    • Annex G.8.5 misquotes some definitions from the Date-Time Vocabulary. For example, the definition of "current day" is misquoted.
    • The concept "date time" is defined twice: in G8.5 and in G.8.9.5. Another concept "date-time" has almost the same spelling, but has a different definition – another likely source of user confusion. Plus the definition does not make sense.
    • The Annex mixes two distinct types of concepts: "time intervals" (spans of time) and "time coordinates" (representations of time intervals). It should use one or the other throughout. The confusion is particularly obvious in places like the definition of "rental is late", which talks about the "end date-time" of a "grace period".
  • Reported: SBVR 1.1 — Sat, 12 Oct 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Issue: 'sentential form' is ambiguous

  • Key: SBVR14-37
  • Legacy Issue Number: 19514
  • Status: closed  
  • Source: USoft ( Rob van Haarst)
  • Summary:

    SBVR 1.2, Formal Specification

    Problem: In Annex B.2.3 the term ‘sentential form’ is used with a different meaning than defined for this term in Clause 8.4.4.

    · In Annex B, it means the standardised form or ‘handle’ by which a verb concept is known in a presentation format such as a glossary. Going by this meaning, ‘customer rents car’ is the sentential form (Annex B uses ‘primary reading’ as a synonym) for the verb concept in question, and “car is rented by customer” is not a sentential form of the verb concept.

    · In Clause 8.4.4, it means any verb concept wording that is available for a given verb concept, except noun forms. Going by this meaning, as the examples provided make clear, “car is rented by customer” and “customer rents car” are alternative sentential forms.

    Suggested solution: Keep 8.4.4 as it is. Remove occurrences of ‘sentential form’ from Annex B, keeping only ‘primary reading’ in that context.

    Discussion:

    The dictionary basis for selecting the adjective ‘sentential’ in Annex B seems to be the meaning of ‘aphoristic’, as in ‘sentential saying’ or ‘sentential book’.

    The dictionary basis for selecting the adjective ‘sentential’ in 8.4.4. seems to be the meaning ‘of a sentence, concerning a sentence’, i.e., the association with ‘sentence’ as a linguistic term.

    The former use of ‘sentential’ in English seems to be the more common. This would explain why the issue has occurred. It also suggests that ‘sentential form’ in Clause 8 is not ideal.

    ‘Verb form’ as a complementary concept of ‘noun form’ would not have this problem but I agree that, because of cases where the wording contains no verb form at all, ‘verb form’ cannot be used. It could be said that ‘verb concept wording’ has the same problem, but I think it is more acceptable to say that a word like ‘of’ or ‘in’ is a “verb concept wording” than to say that it is a “verb form”.

  • Reported: SBVR 1.1 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Notation for the Logical Representation of Meaning

  • Key: SBVR14-49
  • Legacy Issue Number: 19584
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    When DTV v1.0-alpha was adopted, it contained a proposed simplified text representation for SBVR LRMV constructs (as distinct from the long and involved sequences of sentences used in SBVR examples, that make references to undefined concepts like'first variable'). The DTV FTF resolved issues about the disposition of the annex containing this SBVR LRMV notation by improving the description of the notation, but also revising the informative text that used the notation in such a way that the notation is no longer used in DTV. This LRMV notation therefore no longer has a use in DTV and is out of scope for the DTV specification. It is likely that the annex (DTV v1.1 Annex F) will be deleted from DTV v1.2.

    The simplified LRMV notation has value for the wider SBVR community, and its description should be an informative Annex to SBVR. It is within the expertise and purview of the SBVR RTF to address any problems with the notation specification, and to maintain alignment with the SBVR specification generally. Accordingly, the SBVR RTF should maintain the adopted text of DTV Annex F as an Annex to SBVR.

  • Reported: SBVR 1.1 — Wed, 20 Aug 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR should re-consider the use of smart quotes

  • Key: SBVR14-50
  • Legacy Issue Number: 19676
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SBVR should re-consider the use of smart quotes

  • Reported: SBVR 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR should use the latest MOF rather than sticking with MOF 2.0.

  • Key: SBVR14-40
  • Legacy Issue Number: 19674
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SBVR should use the latest MOF rather than sticking with MOF 2.0.

  • Reported: SBVR 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

No relationship defined between clause 8 concepts and clause 11 concepts

  • Key: SBVR14-54
  • Legacy Issue Number: 12541
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

    Some issues: 2) No relationship is defined between the clause 8 concepts and the clause
    11 concepts. Is a body of shared concepts based on a conceptual schema?
    How does a fact model relate to a terminological dictionary?

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Existential and Elementary

  • Key: SBVR14-58
  • Legacy Issue Number: 15157
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Describing the facts of a fact model, SBVR’s clause 10 says, “Population facts are restricted to elementary and existential facts.”

    This “restriction” appears to be a restriction on the clause 10 mapping to a relational database, requiring a sort of normalization. It is certainly not a restriction discernable from SBVR’s definition of “fact model”. Nor is it a restriction on formal interpretation of fact models for knowledge bases in general. Facts that do not fall into those two categories (elementary and existential) can occur in fact models and can be mapped to formal logic. They can be formulated using concepts in a fact model’s conceptual schema, even if they cannot be formulated using those concepts in a way that is considered existential or elementary. Facts can be formulated using disjunction, universal quantification, etc.

    A fact model can have a fact like the following, not as a rule in its schema, but simply as a fact:

    “Every son of Mary has a car and a kayak”.

    Whether this is a “good” fact in terms of being structured according to best practices is not relevant. Once we have a fact model, then we can use tools or guidelines to measure quality and recommend improvements. But that comes after we have fact model to examine.

    Is the fact elementary? Not if it can break into “Every son of Mary has a car” and “Every son of Mary has a kayak”.

    Is it existential? I cannot see it that way.

    But it can map to formal logic, so clause 10 of SBVR should accommodate that mapping. It does not map directly into a relational table, but there is no reason to limit SBVR’s formal underpinnings to relational modeling.

    As it turns out, clause 10 would handle the fact, “Every son of Mary has a car and a kayak”, just fine as long as it is formulated using a unary fact type as would be represented by a unary predicate like this: EverySonOfHasACarAndAKayak(Mary). That sort of contrived fact type is not likely to be found in a conceptual schema made up of meanings of words in a business vocabulary. Requiring a fact model with a business origin to have such a contrived fact type in its conceptual schema is inappropriate for SBVR, even though such contriving is sometimes part of database design. Conceptual schemas based on business vocabularies, rather than database design, involve meanings of words used by business people. Use of such vocabularies starts with an assumption that basic language works (quantifiers, conjunction, disjunction, restriction, demonstration, etc.) for putting words together to make statements. So formulations of facts so stated can tend towards complex formulations involving various sorts of quantifications, objectifications, logical operators, etc. Mapping such fact models into normalized databases is great, but requiring a direct mapping is not and must not be a limitation imposed by SBVR.

    Some confusion is created in clause 10 from using the words “elementary” and “existential” as attributes of facts, when they seem to be attributes of formulations of facts, not of the facts themselves. For example, if the characteristic ‘employee number is assigned’ is define as “there exists an employee that has the employee number”, then by definitional substitution, these are two statements of the very same fact:

    Employee number 777 is assigned.

    There exists an employee that has the employee number 777.

    So we have one fact that appears to be both elementary and existential. The difference is in formulation, not the fact.

    It would be more clear for clause 10 to apply the ideas of “ground”, “elementary” and “existential” to formulation of facts rather than to facts. “Population” in the clause 10 sense seems to be strictly tied to formulation. It gives an example: “pop(Employee drives Car)= set of (employee, car) pairs …”.

    Recommendation:

    Remove the clause 10 general “restriction” to elementary and existential facts. Any such restriction should apply only to the clause’s relational mappings.

    In clause 10, clarify how the concepts of “ground”, “elementary”, “existential” and “population” are tied to formulation.

  • Reported: SBVR 1.0 — Fri, 2 Apr 2010 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete

  • Key: SBVR14-52
  • Legacy Issue Number: 16631
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Clause 10 of SBVR provides a formal logic interpretation of SBVR in terms of Object Role Modeling (ORM).

    There has been a long-standing agreement within the OMG community to provide a formal interpretation in terms of Common Logic (CL). CL is an ISO standard (ISO 24707) for which there is an OMG standard metamodel in the Ontology Definition Metamodel (ODM) specification, and which is being used as a basis for logical interpretation in the OMG Date Time vocabulary.

    A partial interpretation of SBVR in CL is given in clause 10.2, but significant work is needed to complete this grounding. Completion is essential to supporting downstream alignment of OMG specifications that are expressed in terms of other logic languages, to reuse of SBVR vocabularies by commercial rule engines, and to facilitate interoperability with other work in the ISO community. It may also be needed to support development of new vocabularies in SBVR, such as potential financial services vocabularies related to the FIBO (Financial Industry Business Ontology) effort in the Finance DTF.

  • Reported: SBVR 1.0 — Wed, 19 Oct 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Annex H recommends faulty UML constructs

  • Key: SBVR14-51
  • Legacy Issue Number: 17241
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Annex H provides detailed guidance on the representation of SBVR vocabulary concepts in UML diagrams. Much of that guidance produces invalid UML constructs per UML 2.4.

    H.1 "If there are additional terms for the concept they can be added within the rectangle, labeled as such – e.g., “also: is-category-of
    fact type” as depicted in Figure H.1." There is no UML syntax for this.

    H.2 "Alternatively, an individual concept can be depicted as an instance of its related general concept (noun concept), as in Figure H.3." The diagram uses an unidentified Dependency, which has no meaning. It should be formally stereotyped.

    H.3.1 shows three representations of the fact type 'semantic community shares understanding of concept'. The third is invalid – an association can have only one name. Also the name of the association is 'shares understanding of'; it does not include the placeholder terms.

    H.3.1 Figure H.4 shows associations that are navigable in both directions, inducing unnamed UML properties on 'semantic community' and 'concept' that are not intended. (This is a vestige of UML v1 ambiguity.) It should show no navigable ends, using UML 2.4 syntax.

    H.3.4 Figure H.9 depicts an invalid relationship symbol; an association is required to have 2 or more roles.

    H.4.2 Figure H.11 shows a stereotype <<is role of>> on a Generalization. I'm not sure this is valid UML, but in any case such a stereotype would have to be defined in a formal Profile. (Semantically, some "roles" are object types that specialize more general concepts, others are association ends (verb concept roles), and others are things in their own right that have the property 'role has occupant'.)

    H.4.3 suggests that there is no consistent mapping for association names. In any case, the UML model of a 'fact type role' is a named association end, regardless of ownership.

    H.6.1 Figure H.14. It is not clear what UML element has the name "Results by Payment type", and the text does not say. It may be a GeneralizationSet.

    H.6.2 Figure H.16. ":modality" appears to be a TagValue associated with some unnamed and undefined Tag, or it may just be another string that names no model element.

    H.8 In, Figure H.17 there is a meaningless dashed line between 'car recovery' and a ternary association (verb concept). It is said to represent 'objectification'. That dashed line should be a Dependency that has a stereotype indicating the nature of that relationship, e.g., <<objectification>>, defined in a Profile.

    H.9 says that the default multiplicity on association ends is 0..*. According to the UML metamodel v2.4, the default multiplicity on a UML association end is 1..1, i.e., exactly one. This makes most of the SBVR UML diagrams implicitly erroneous.

    So Annex H needs to be rewritten, and if it is to include standard stereotypes and tag values, it needs a standard UML Profile that defines them.

    Further, it demonstrates the need for minor repairs to the UML diagrams throughout SBVR, to make them match the MOF model described in Clause 13.

  • Reported: SBVR 1.1 — Thu, 15 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

typo in clause 10.1

  • Key: SBVR14-57
  • Legacy Issue Number: 17144
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    "vocabularies" is miss-spelled "vocabulaires" in the sixth paragraph of clause 10.1.1 in convenience document 8.

  • Reported: SBVR 1.1 — Mon, 20 Feb 2012 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Error message from XML Schema validator when trying a SVBR XSD

  • Key: SBVR14-46
  • Legacy Issue Number: 18651
  • Status: closed  
  • Source: Ericsson ( Torbjorn Lindqvist)
  • Summary:

    We're currently building a Corporate Vocabulary and our idea is to use the SVBR provided XML Schema for all source documents.

    However, when trying the XSD-file available at the SVBR specification page in an XML Schema validator a got the error message:

    Src-import.3.1: The Namespace Attribute, 'http://schema.omg.org/spec/XMI/2.1', Of An <import> Element Information Item Must Be Identical To The TargetNamespace Attribute, 'http://www.omg.org/spec/XMI/20071213', Of The Imported Document.

    The XML Schema validator is available at the URL:
    http://www.freeformatter.com/xml-validator-xsd.html

    I have a sceen dump as well that I can send via email.

    I downloaded the XSD-file and changed the namespace to match the namespace in the import element.
    But it only resultet in a new fault.

    Any ideas?

  • Reported: SBVR 1.0 — Thu, 11 Apr 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1

  • Key: SBVR14-55
  • Legacy Issue Number: 16685
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    OMG Issue No: 16685
    Title: Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1
    Source:
    SBVR Co-chair, Donald Chapin [Donald.Chapin@BusinessSemantics.com]
    Summary:
    Spin-off from Resolution of Issue 15623 (and 14843 which was Merged into it)
    Fix the entries in SBVR Subclause 10.1.2.1 to bring them in line with what Clause 10.1 says as revised by the resolution to Issues 15623 & 14843.

  • Reported: SBVR 1.1 — Mon, 14 Nov 2011 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Vocabularies Relationship to SBVR Subclause 10.1.1

  • Key: SBVR14-60
  • Legacy Issue Number: 16684
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
    The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined.
    The underlying issue is:
    1. SBVR’s metamodel is defined in Clauses 8, 9, 10, 12 and 13. Its instances (domain models) are linguistic models of meanings.
    2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR’s metamodel. Its instances (domain models) are fact models.
    The proposed resolution is:
    1. State, in introductory text in Clauses 8 and 10, that the models are different
    2. Somewhere in Clause 10:
    a. List the major differences between the two models
    b. Describe informally what transformation would be needed to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification

    Resolution:
    1. Add a subclause to Subclause 10.1.1 to discuss to an appropriate level of detail all aspects of the relationship between the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 and the formal interpretation in Subclause 10.1.1, as well as removing ambiguity from Clause 10.1.1 by consistent use of terms intension, extension, fact population, and the set of all possible facts..

  • Reported: SBVR 1.1 — Fri, 4 Nov 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Move 'rulebook' to Clause 12

  • Key: SBVR14-47
  • Legacy Issue Number: 16062
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Clause 11 includes an entry for 'rulebook' (specifically, in 11.2.2.4). To maintain the separation of vocabulary-related items from rule/governance-related items (which has been the convention for Clauses 11 and 12), this should appear in Clause 12 rather than Clause 11.

    Resolution: Move 'rulebook' to Clause 12.

    [issue requested in the telcon of Mar. 18 2011]

  • Reported: SBVR 1.0 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

C.5.2, including the diagram, should use single guillemet characters not >> and <<

  • Key: SBVR14-56
  • Legacy Issue Number: 19682
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    C.5.2, including the diagram, should use single guillemet characters not >> and <<

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Missing " Concept Type" in 'at least n quantification'

  • Key: SBVR14-48
  • Legacy Issue Number: 18890
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In SBVR clause 8.x, in the entry for 'at least n quantification', the Definition ends with the term ‘logical fomulation kind’, which makes no sense in the context.

    What was intended is a new paragraph:

    Concept Type: logical formulation kind

  • Reported: SBVR 1.1 — Mon, 9 Sep 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR 1.2 - Error in Annex E figure (p. 6)

  • Key: SBVR14-65
  • Legacy Issue Number: 19242
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    The figure on p. 6 of Annex E (SBVR 1.2) contains an error (use of 'fact type'). Ref. leftmost box in the screenshot below.

    If you can supply the image source I will make the correction

  • Reported: SBVR 1.1 — Sat, 15 Feb 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Concept System

  • Key: SBVR14-59
  • Legacy Issue Number: 19541
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Rectifying the Relationship Between SBVR and ISO 1087 Terms "Concept System" and "Relation"

    SBVR uses two terms "concept system" and "relation" found in ISO 1087 but extends these notions in important ways. Specifically, SBVR supports more "elements of concept system structure" than ISO 1087 does – especially, but not exclusively, associations (verb concepts). ISO 1087 defines only some kinds of relation, such as 'generic relation', 'partitive relation', 'hierarchical relation'. Use of the terms "concept system" and "relation" in SBVR should be rectified.

    1. "Concept System" appears in several places in SBVR, as follows:

    • In the definition of Characteristic Type (p. 147)
    • In the name and definition of "Elements of Concept System Structure" (p. 154)
    • In text (p. 190 and p. 195)
      However, "concept system" is not defined in SBVR.

    2. "Relation" (in the ISO sense roughly meaning 'connection') appears in several places in SBVR, as follows:

    • In the definition of Body of Shared Meaning (p. 142) and in a note for that entry.
    • in the definition of Category (p. 148) Note: Its use here may not be inconsistent with ISO.
    • In the definition of More General Concept (p. 148) Note: Its use here may not be inconsistent with ISO.

    RESOLUTION

    1. "Concept System" is a synonym in SBVR for "Body of Shared Concepts" and should be explicitly treated as such.
    2. "Concept System" should be indicated as the preferred term for the concept "Body of Shared Concepts". ("Body of Shared Concepts" is awkward and not memorable.)
    3. A Note should be added to the entry for "Body of Shared Concepts" indicating ISO 1087 as the source for the term "concept system". Note: The ISO definition should not be indicated as the Basis for the entry since the ISO meaning is much more restricted.
    4. Replace "relation" with "connection" in the definition of Body of Shared Meaning (p. 142) and in a note for that entry.
    5. Replace "relation" with "connection" in the definitions of Category (p. 148) and More General Concept (p. 148).

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Clause 8 does not include the concepts needed to represent itself

  • Key: SBVR14-53
  • Legacy Issue Number: 12540
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

    Some issues:

    1) Clause 8 does not include the concepts needed to represent itself, even
    though clause 2 says clause 8 is a standalone compliance point. Clause 8
    claims to be a vocabulary, but the concept "vocabulary" is in clause 11,
    not clause 8. Hence an implementation of clause 8 cannot model clause 8
    itself.

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Clean up and Complete Vocabulary for Clause 10.1.1

  • Key: SBVR14-69
  • Legacy Issue Number: 13139
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    SBVR Issue – Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces)Please see attached Word document for Issue details.

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

    • the proposed resolution of this spin-off Issue which will be posted when it has a number;
    • the proposed resolution to Issue 12540; and
    • the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number.
  • Reported: SBVR 1.0 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Inconsistent use of terminology when relating facts to fact types

  • Key: SBVR14-66
  • Legacy Issue Number: 15124
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Inconsistent use of terminology when relating facts to fact types

    It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type – obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings.

    Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places.

    Recommended changes:

    1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says:

    A ‘Fact’ is of a particular ‘Fact Type.’

    2. REPLACE the third paragraph of 10.1.1.2, which says this:

    The conceptual schema declares the fact types (kinds of facts, such as “Employee works for Department”) and rules relevant to the business domain.

    With this:

    The conceptual schema declares the fact types (such as “Employee works for Department”) and rules relevant to the business domain.

    3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says:

    The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema).

    REPLACE it with this:

    The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema).

    4. Just above figure 10.1 on page 90 there is the following sentence.

    Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts.

    REPLACE it with this:

    Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts.

  • Reported: SBVR 1.0 — Tue, 9 Mar 2010 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR issue - Need verb concept to support "local closure"

  • Key: SBVR14-67
  • Legacy Issue Number: 16610
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Disposition: Resolved
    OMG Issue No: ????
    Title: Need business-oriented verb concepts to support "local closure"
    Source:
    Mark H. Linehan, IBM Research
    Summary:
    Clause 10.1.1.3 has an extensive discussion of "Open/Closed World Semantics". In particular, the penultimate paragraph near the bottom of page 94 of version 1.0 of the specification says:
    "For any given schema, the business might have complete knowledge about some parts and incomplete knowledge about other parts. So in practice, a mixture of open and closed world assumptions may apply. We use the term “local closure” (or “relative closure”) for the application of the closed world assumption to just some parts of the overall schema. One might assume open world semantics by default, and then apply local closure to specific parts as desired; or alternatively, assume closed world semantics by default and then apply “local openness.” We adopt the former approach as it seems more realistic when modeling real business domains."

    In SBVR 1.0, local closure is supported by the verb concepts "fact type is internally closed in conceptual schema" and "concept is closed in conceptual schema" in clause 8.5. The resolution of issue 13138 moves clause 8.5 to clause 10, thus making these verb concepts no longer available in the normative specification or in the clause 15 supporting documents. The result is that the specification no longer supports the semantics mentioned in the quote given above. This issue requests that similar functionality be added to clause 11.

    The original clause 8.5 verb concepts used designations that are not meaningful to business people. The resolution of this issue should adopt business-oriented terminology. Discussions have identified at least four possible approaches:

    1. A verb concept "set is completely known", meaning that the semantic community knows all the elements of the set. This would be particularly useful when applied to a set as the extension of a concept.
    2. A verb concept "concept has completely known extension". Similar to the above, but applying specifically to the extension of concepts.
    3. A verb concept such as "semantic community completely knows concept".
    4. Building on the concept "communication concept" in clause 11.2.2.3 to define closure with respect to an information record.

    Example use cases for local closure include the following:

    Example 1

    This example is about a concept called order that includes a list of line items, where each line item has a quantity, a catalog id, etc. A minimal vocabulary is shown here, just enough to illustrate the example.

    order
    Definition: A customer request for one or more products and a promise to pay the total cost of the order.
    line item
    Definition: Details about an order for a particular product.
    quantity
    Definition: positive integer that is the number of units of the product that is desired by the customer
    catalog id
    Definition: text that identifies the product desired by the customer
    line item has quantity
    Necessity: Each line item has exactly one quantity.
    line item has catalog id
    Necessity: Each line item has exactly one catalog id.
    order includes line item
    Necessity: Each order includes at least one line item.
    "order includes line item" is internally closed in the business xx conceptual schema

    The "internally closed" fact says that the business knows all the line items that are included in each order: there are no other line items. Consider a rule such as "Each order must be shipped within 24 hours if the order does not include a line item that has quantity greater than 100." As described in clause 10.1.1.3, this rule makes no sense with the default SBVR "open world" semantics because under those semantics, the business cannot know that no "line item that has quantity greater than 100".

    Example 2

    Consider a business that has a vocabulary about employees. The business considers it knows all its employees; there are no employees that it does not know.

    employee
    Definition: person that works for the business

    Under SBVR's default open world semantics, the glossary entry given above is insufficient because it does not capture the business sense that it knows all its employees. To accomplish that, the vocabulary needs the following:
    "employee" is closed in the business xx conceptual schema

    Example 3

    Continuing example 2, suppose the business needs concepts relating to employee names and work phone numbers:

    employee name
    Definition: text that identifies an employee
    work phone number
    Definition: number used to phone an employee at work

    The business requires that it knows the employee name of each employee because the government requires this information on tax and employment reports. So the employee name is authoritative.

    The business knows that, in practice, it does not know the work phone number of each employee. These change too often to keep up with.

    SBVR needs verb concepts to express the idea that the employee name is reliably know, but the work phone number is not reliably known.

    Resolution:
    Revised Text:
    Disposition:

  • Reported: SBVR 1.0 — Mon, 17 Oct 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Definition of "representation uses vocabulary" (Clause 11

  • Key: SBVR14-63
  • Legacy Issue Number: 17441
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Problem: The current definition of "representation uses vocabulary" is "the representation is expressed in terms of the vocabulary". I think the un-styled "term" (in terms of) is a bad choice for the definition. A better choice might be based on.

    Resolution:

    Change the definition of "representation uses vocabulary" to: "the representation is expressed based on the vocabulary".

  • Reported: SBVR 1.1 — Fri, 15 Jun 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Keyword "another"

  • Key: SBVR14-64
  • Legacy Issue Number: 17244
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another <person3>" refers to <person1> and/or <person2>:

    It is prohibited that a <person1> <is married to> <person2>, if that <person1> <is married to> another <person3>.

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular

  • Key: SBVR14-73
  • Legacy Issue Number: 19681
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular

    Again, no UML tool will be able to add/remove “has” in diagrams.

  • Reported: SBVR 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Formalize the 'quantity' entry

  • Key: SBVR14-62
  • Legacy Issue Number: 19332
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    'quantity' is defined informally. A formalization of the existing definition is proposed, along with changes in terminology and related entries that would be affected by the change.

    The proposed changes unify some fundamental concepts in SBVR and application domains and significantly enhance the ability to reason about SBVR models.

    Full details are provided in a paper I authored but am unable to attach to this message because of limitations of this OMG Web site, which does not accept attachments. Please contact me if you would like to review the paper, and I'll send it by email.

  • Reported: SBVR 1.2 — Thu, 10 Apr 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

No way to adopt a concept or a glossary item

  • Key: SBVR14-61
  • Legacy Issue Number: 19543
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR provides for a speech community to adopt a definition, or an element of guidance, but no clear way for a vocabulary to adopt a term and its definition from another vocabulary. The Date Time Vocabulary (clause 4) formally adopts a set of terms from the SBVR specification with the intent that the term means the definition given in SBVR and has whatever other associations that term may have to other adopted SBVR terms. (This is the usual practice for adopted terminology in an ISO standard.) But SBVR does not provide a formal expression for this. Instead, it appears that DTV must introduce all the required SBVR terms and their definitions and then cite SBVR as the Source of the definitions. (This is a practice ISO recommends against, because of the problem of synchronization of changes.) We believe that this is a shortcoming in SBVR.

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

no glossary entry for intensional roles

  • Key: SBVR14-75
  • Legacy Issue Number: 19542
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    SBVR Clause A.2.6 provides syntax for a concept called ‘intensional role’, but there is no such terminological entry and no clear definition.

    In one of the business usage examples for DTV, we have encountered a usage of ‘time period’ in two intensional roles: ‘fixed period’ and ‘variable period’, but we can’t declare them: Concept type: intensional role.

    As A.2.6 says, intensional roles arise when a concept designation is used with verbs of specification and change, and possibly others. The reference is to an unspecified thing of that will satisfy the concept. When one ‘specifies the rental period for X’, the rental period does not denote any time period. The whole idea is that one associates the concept ‘rental period for X’ with an extension that will only exist when the specifying action completes. Similarly, one cannot ‘change the rental period’, one can only change which time period “the rental period for X” denotes. With these verbs, the “intensional role” is equivalent to an ‘answer’ (at least in structure): one specifies “what time period the rental period is”.

    The same idea seems to apply to a verb like ‘prevents’. If someone “prevents a forest fire”, there is no forest fire that is prevented; rather the concept ‘forest fire’ is not instantiated. But unlike the above, one does not prevent “what forest fire it is.” And if one ‘orders 1000 widgets’, they may or may not already exist so that they can be ordered. What one orders is a characterization of objects that are to be instantiated.

    So, the intensional role seems to be a valuable concept for verb concept wordings, because it has real business use

  • Reported: SBVR 1.1 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR typo - duplicated entry in Index (p. 225)

  • Key: SBVR14-74
  • Legacy Issue Number: 19283
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    SBVR 1.2, p. 225, the Index entry for ”proposition” appears twice (and once out of alpha order).

  • Reported: SBVR 1.1 — Mon, 10 Mar 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue: Use of 'Partitioning' in the Definition of Categorization Scheme

  • Key: SBVR14-68
  • Legacy Issue Number: 19567
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:
    • "Partitioning" is a defined term in SBVR. It is a synonym of Segmentation.
    • "Segmentation" is a category of Categorization Scheme. Segmentation has a very particular, more restrictive meaning than Categorization Scheme: "categorization scheme whose contained categories are complete (total) and disjoint with respect to the general concept that has the categorization scheme ".
    • Yet the word "partitioning" is used in the definition of Categorization Scheme: "scheme for partitioning things in the extension of a given general concept into the extensions of categories of that general concept ". That could be very confusing (even though not stylized ... and shouldn't be). It potentially suggests constraints that are not meant.

    Resolution:
    Substitute the word "allocating" for "partitioning" in the definition of Categorization Scheme.

  • Reported: SBVR 1.1 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre

  • Key: SBVR14-80
  • Legacy Issue Number: 11328
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    As a result of the vote on Issue 9959, there is a need to clarify and strengthen the Note in front of the Formal Logic Interpretation Table in Clause 10.2, particularly to cover these points:

    • a major subset of SBVR has a complete formal logic interpretation whose principles are set forth in Clause 10.1
    • the table will contain:

    o a formal logic interpretation specified in ISO Common Logic based on Clause 10.1

    o a cross-reference to OWL constructs that equivalent to SBVR constructs

    • the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force
  • Reported: SBVR 1.0b2 — Thu, 30 Aug 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

The Notion of “Involvement” has not been Adequately Specified with in SBVR

  • Key: SBVR14-89
  • Legacy Issue Number: 11301
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The ‘involvement’ Issue is as follows (from my email sent on Saturday):

    Issue Submitter’s Name: Donald Chapin

    Issue Submitter’s Company: Business Semantics Ltd (submitted as SBVR FTF Chair)

    Issue Submitter’s Email: Donald.Chapin@btinternet.com

    Issue Name: The Notion of “Involvement” has not been Adequately Specified with in SBVR

    Document No: dtc/06/03/01

    Document Revision Date: March 2006

    Document Version No: —

    Chapter/Section: 8.1.1

    Page No(s): 16

    Nature of Issue: Revision

    Severity of Issue: Major

    Issue Description:

    The notion of Involvement has not totally been taken into account by the resolution of Issue 9948 as stated in that resolution.

    Several clarifications are needed regarding Involvement such as the nature of instance of roles (see the sum example in the initial 9948 statement).

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Additional Improvements to Clause 10

  • Key: SBVR14-79
  • Legacy Issue Number: 11296
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Issue Description:

    1. Spin-off Issue for items not resolved In Issue 9959 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

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Metamodel Fixes Related to a Formal Logics Interpretation

  • Key: SBVR14-91
  • Legacy Issue Number: 11303
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The following SBVR metamodel formal logic-based errors and omissions need to be dealt with as we ran out of time to deal with them:

    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.

  • Reported: SBVR 1.0b1 — Thu, 23 Aug 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue - What is a 'terminological entry'

  • Key: SBVR14-94
  • Legacy Issue Number: 19749
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR

    Version: 1.3 (from RTF Report)

    Title: What is a 'terminological entry'

    Summary:

    SBVR clause 6.2 (How to read this specification) says:

    "This specification describes a vocabulary, or actually a set of vocabularies, using terminological entries. Each entry

    includes a definition, along with other specifications such as notes and examples."

    But the term 'terminological entry' is not defined anywhere in the text of SBVR. In particular, it does not appear in Clause 19.3 in relationship to 'terminological dictionary'.

    Clause 19.3 says a 'terminological dictionary' is a collection of representations, that it "includes representations" and "presents a vocabulary". But then a vocabulary is a "set of designations", and is apparently related to them by 'thing is in set', because there is no other stated verb concept to relate them. So the vocabulary is a subset of the "set of representations" that is included in a terminological dictionary that presents it? But a 'terminological entry' seems to be none of the above, and a 'terminological dictionary' does not include them? This set of circumlocutions completely fails to present a clear model for the exchange of a vocabulary or of a terminological dictionary. The central idea in a terminological entry, if SBVR is any indication, is a concept, and representations of it, and related commentary.

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Multiple interpretations of the General Concept caption

  • Key: SBVR14-93
  • Legacy Issue Number: 19748
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Annex A.4.5 says: "The 'General Concept' caption can be used to indicate a concept that generalizes the entry concept."

    In point of fact, the General Concept caption represents three entirely different verb concepts in different contexts:

    • In the entry for a general noun concept or verb concept X, General Concept: Y means 'X specializes Y'.
    • In the entry for an individual noun concept X, General Concept: Y means 'X is an instance of Y'.
    • In the entry for a "role concept" X, Genera Concept: Y means 'X ranges over Y' (see also Issue 19519).

    Further, it is possible for a role concept to specialize another role concept, as 'first member' (of a list) specializes 'member' (of a list). But the range of 'first member' is whatever the list is a list of. Similarly, 'captain (of ship)' specializes 'officer (of ship)' but both range over 'person'. So, overloading General Concept in the way SBVR does makes it less capable of conveying the semantics of roles.

    [Note that UML and MOF distinguish between the range of an association end (role) -- the class (general concept) to which it is connected -- and any association end (role) that it subsets/redefines (specializes). SBVR apparently cannot.]

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue - Annex A is a mistitled grab bag

  • Key: SBVR14-92
  • Legacy Issue Number: 19747
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR

    Version: 1.3 (from RTF Report)

    Title: Annex A is a mistitled grab bag

    Annex A is titled "SBVR Structured English", and every paragraph of A.1 is about that topic, except for the last, which indicates that every subsection after A.2 is about other topics. In particular, A.3 and A.4 are about the structure of the SBVR specification as a terminological dictionary, and A.5 and A.6 are guidance for creating 'rule set' structures.

    It is imperative that A.3 and A.4 be packaged as a section, either in section 6.2 (How to read this specification), or in an Annex that 6.2 points to. Those two sections are "how to read the SBVR specification" and interpret the terminological entries in it. This issue arose from trying to find that guidance.

    Guidance for creating rule sets (A.5 and A.6) is not a characterization of either SBVR SE or the structure of the SBVR specification. It is a separate topic, associated with clauses 16 thru 18.

  • Reported: SBVR 1.3 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Redefinition of "Body of Shared Concepts" (Clause 11)

  • Key: SBVR14-72
  • Legacy Issue Number: 17440
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    Problem: If "body of shared concepts" were defined as [the set of] all of the concepts within a body of shared meanings", then I dont think the following entry would be needed: "body of shared concepts includes concept".

    Resolution:

    1. Change the definition of "body of shared concepts" to: the set of all of the concepts within a body of shared meanings"

    2. Eliminate the entry: body of shared concepts includes concept

  • Reported: SBVR 1.1 — Fri, 15 Jun 2012 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Distinguishing between Representation Expressions With and Without Embedded Markup

  • Key: SBVR14-70
  • Legacy Issue Number: 16166
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    SBVR is not clear about how markup should or should not be embedded within
    Representation Expressions.

    The specification needs to be clear about exactly what is included in basic
    Representation Expressions, especially Fact Type Forms, which contain no
    embedded markup. It also needs to be clear about the kinds of markup that
    can be embedded in Representation Expressions and how to communicate which
    markup specification is being used.

  • Reported: SBVR 1.0 — Fri, 6 May 2011 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

SBVR Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept

  • Key: SBVR14-71
  • Legacy Issue Number: 19568
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept

    • The entry for Noun Form in SBVR is currently silent as to whether or not a noun form can be based on a unary verb concept.
    • If the answer is no, a Note should say as much.
    • If the answer is yes, an example should be given.

    Resolution:
    Indicate explicitly yes or no, and include an example if yes.

  • Reported: SBVR 1.1 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT

Gap that Needs to be Filled by Concept Role Playing of Thing in Occurrence

  • Key: SBVR14-84
  • Legacy Issue Number: 11285
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    1. An SBVR metamodel noun concept (named something like “role playing of thing in occurrence”) that is very similar to ‘object type’, ‘fact type’, ‘individual concept’, ‘situational role’ (role type), or ‘fact type role’ in that it defines a kind of vocabulary entry that can be entered in an SBVR model is needed in SBVR. It’s omission represents a critical gap in SBVR.

    2. Preferably this noun concept (“role playing of thing in occurrence”) would be a category (subtype) of object type; but it is much better to have the concept in the SBVR metamodel than to require it to be an object type, if that is too difficult (e.g. fact type role is not (a category/subtype of) an object type).

    3. The meaning of this kind of SBVR model vocabulary entry would be that it talks about "the ‘thing’ with respect to (in the context of) its/his playing some role in a fact of a fact type, and so on for each thing that plays that role in a fact of that fact type.

    a. E.g. "the person with respect to (in the context of) his renting a given car on a given date", and so on for each person who rents a car on a date.

    4. The extension of each vocabulary entry concept that is this kind of SBVR metamodel concept (“role playing of thing in occurrence”) must be in one to one correspondence with the actualities that are instances (and the facts [that correspond to the actualities]) that are of a given fact type which is identified in the definition of this kind of vocabulary entry. In the reference scheme below:

    a. The first part (a name of an individual concept that corresponds to the thing that fills the given fact type role) is the thing we’re talking about

    i. Example: Joe Smith (the person)

    b. The second part (the fact type form of the fact type and a name of an individual concept that corresponds to the thing that fills each of the other fact type roles of the fact type) of the context of the role playing

    i. Example: with respect to (in the context of) Joe’s renting of car 1234 on July 30, 2007 (with respect to (in the context of) his renting a given car on a given date)

    5. The instances in the extension of each vocabulary entry concept that is this kind of SBVR metamodel concept (“role playing of thing in occurrence”) must be the ‘playings’ of a given ‘role’ by a ‘thing’ in the ‘facts’ that are for the ‘fact type’ identified in the vocabulary entry concept definition.

  • Reported: SBVR 1.0b2 — Sat, 18 Aug 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:53 GMT

Entry for "categorization scheme", p. 147, Definition. and Example

  • Key: SBVR14-83
  • Legacy Issue Number: 10958
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    The definition currently reads "scheme for partitioning things ..."
    Should read "scheme for classifying things ..."

    'Partitioning' is a segmentation, which is a categorization scheme that is complete and disjoint. The problem here is that the general concept, "categorization scheme" is defined to be a specialization of itself, "partitioning". Categorization schemes are not, in general, segmentations. Categorization schemes are, in general, neither complete nor disjoint. The word "classifying" captures the more general concept and should be substituted for "partitioning" in the definition. The Example is a segmentation. It could be revised to show a categorization scheme that is neither total nor disjoint, e.g.

    {boy, adult}

    . The Example under "categorization scheme" could be moved to be an example under "segmentation."

  • Reported: SBVR 1.0b2 — Wed, 18 Apr 2007 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:53 GMT

owned definition and adopted definition are roles

  • Key: SBVR14-87
  • Legacy Issue Number: 10631
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

    Title: owned definition and adopted definition are roles

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

    Description:

    In clause 11.1.3, the terms 'owned definition' and 'adopted definition' are defined without reference to any category. They are both roles of the concept 'definition'. 'owned definition' is a role in the fact-type 'speech community owns owned definition' and ''adopted definition' is a role in the fact-type 'speech community adopts adopted definition from source vocabulary'.

    Recommendation:

    1. In the entry for 'owned definition', immediately behind the Definition paragraph, ADD:
    "Concept type: role
    General concept: definition"

    2. In the entry for 'adopted definition', immediately behind the Definition paragraph, ADD:
    "Concept type: role
    General concept: definition

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:52 GMT

Definition of 'question'

  • Key: SBVR14-77
  • Legacy Issue Number: 10621
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 8.1.3, 'question' is defined as "meaning of an interrogatory".
    Assuming that "interrogatory" means "interrogatory sentence", this defines the meaning in terms of the form of expression. Because the same interrogatory sentence may have more than one meaning, depending on the context of its utterance, this definition means: the meaning of an interrogatory sentence in context. But the same meaning extends across (some) contexts, while the answer may be different in each such context. That is, some part of the context of utterance affects the interpretation of the utterance; other parts of the context of utterance only affect its result. So this is a poor definition.

    A question is really an "operation" on a concept or proposition that creates a new form of meaning. One can describe a 'question' as a function applied to a concept or proposition whose result is its extension. There are 3 kinds of questions:

    • a concept question (What), which asks for the extension of a concept,
    • a proposition question (Whether), which asks for the truth-value (technically the extension) of a proposition.
    • a propositional relationship question (Why), which asks for the extension of a 2nd-order proposition about propositions (or objectified 'states of affairs' identified by propositions) – the set of all propositions P such that 'P causes Q' or 'P entails Q'.

    Since clause 9 apparently supports 'question' meanings in exactly this way, SBVR should define 'question' to be a meaning that explicitly refers to the extension of a concept. That is, the question means its answer. It should not mean the action of asking.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:52 GMT

'Thing' Is Incorrectly Equated with ISO 1087 'Object'

  • Key: SBVR14-86
  • Legacy Issue Number: 10579
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE TITLE: 'Thing' Is Incorrectly Equated with ISO 1087 'Object' ISSUE DESCRIPTION: In ISO TC 37, and in ISO 1087 in particular, 'object' and 'concept' are mutually exclusive. ISO 1087 'object' is equivalent to SBVR 'res', (thing that is not a meaning). SUGGESTED RESOLUTION: 1. Move the adoption of ISO 1087 'object' from SBVR 'thing' to SBVR 'res'. 2. Make 'res' and 'meaning' a segmentation of 'thing'. 3. Change definition of 'thing' back to the original one supplied by BRG before the adoption of ISO 1087 'object'; i.e.: "whatsoever; literally anything: - that exists external to the mind ; - which can talked about regardless of: a. what it is b. how it is perceived" NOTE: This resolves Sridhar's concern that the definition of 'thing' began with 'anything'.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:51 GMT

Relationships Between Definition Concepts and Semantic Formulation Concepts Seem to be Wrong or Missing

  • Key: SBVR14-88
  • Legacy Issue Number: 10576
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE TITLE: Relationships Between Definition Concepts and Semantic Formulation Concpets Seem to be Wrong or Missing ISSUE DESCRIPTION: The relationships between 'definition' (both intensional and extensional) and 'semantic formulation' (both 'necessity' and 'closed projection') and the 'intension' and 'extension' of a concept in some cases seem to be wrong and other cases missing. - The connections between 'intensional definition', 'necessity' logical formulation (structural rule), 'essential characteristic set' and 'concept' are missing (as discussed above). - The connection between 'definition', 'closed projection' and 'concept' seems ambiguous, and maybe incorrect, as 'closed projection' is usually associated with 'extension' and not directly with 'concept'. Also associating 'closed projection' with 'definition' in general (vs. intensional or extensional definition) seems strange. - The connection between 'extensional definition', some kind of semantic formulation, and extension seemns to be missing.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:50 GMT

Vocabulary Adoption vs. Inclusion

  • Key: SBVR14-90
  • Legacy Issue Number: 10560
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Vocabulary Adoption vs. Inclusion The vocabulary of section 12 is directly built on, and depends on, some (but not all of) of the vocabulary of section 10. Questions have arisen in that regard, including (but not limited to) the following: * Is the latter vocabulary being included or adopted into the former? * Is there a difference between “inclusion” and “adoption”, and if so, what is it? * Can you adopt and/or include concepts and/or definitions without terms? * What exactly is included or adopted when “inclusion” and/or “adoption” occurs? * How exactly does SBVR intend “adoption” and/or “inclusion” to work? SBVR needs to be more specific about the notions of “adoption” and/or “inclusion”, since SBVR itself requires these notions, and since leaving the specifics to practice or interpretation is likely to produce divergent and perhaps undesirable results.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:48 GMT

"SBVR 'Thing' <-> 'Expression' Architecture" Needs Fixing

  • Key: SBVR14-81
  • Legacy Issue Number: 9954
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE: "SBVR 'Thing' <-> 'Expression' Architecture" Needs Fixing 1. Form for Representation needs to be added between 'meaning' and 'representation' to include 'semantic formulations; forms of concept meaning (intensional, extensional,etc.); types of forms of expression. 2. 'Representation' should to tie to 'form of representaiton' instead to directly to meaning and add should only Speech Community considerations (language, Speech Community-specific terms, notations) to 'form of representation'. 3. 'Expression is in Language' needs to be added 4. Representations, at least designations, should be in canonical form 5. The relationship between 'representation' and 'expression' should allow for basic linguistic analysis e.g. multiple spellings, plurals, etc.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:48 GMT

Bring the Specification of SBVR Which is in Terms of Itself to the Full SBVR Metamodel Standard

  • Key: SBVR14-82
  • Legacy Issue Number: 9951
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE: Bring the Specification of SBVR Which is in Terms of Itself to the the Full SBVR Metamodel Standard The current specification of SBVR in terms of itself (SBVR Structured Englich) is not completed or up to full integrity in that: 1. not all SBVR metamodel constructs are specific for each SBVR entry in Clauses 8, 9, 1, and 12 2. some entries are lower quality than they should be, e.g. some definiitions are not fully structured; some necessities are missing; etc. 3. Definitions and Necessities have not been fully tested by software to see that all supporting entries in in SBVR.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:47 GMT

Section: 8.3

  • Key: SBVR14-76
  • Legacy Issue Number: 9946
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE: Use URI to Uniquely Identify and Assert the Existence of Every 'Thing' Represented in an SBVR Model to Support Multi-Classification of 'Things' Need to develop a URI pattern for all kinds of representations that can assert the existence of any 'thing' in an SBVR Model. These patterns need to take Speech Community and Symbol Context / Subejct Area into account. The appraoch chosen needs to support composite identifiers and identifiers with a narrow context scope. Topic Maps has an excellent approach for this and has done extensive work with the W3C to identifying the issues with URIs and the best ways to deal with them. For Topic Map / W3C References see: ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Subject%20Identifiers.doc Another benefit of this is that is laying the necessary foundation for mapping to RDF/ORL as well as the Rules Interchange Format

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:46 GMT

Section: 8.7

  • Key: SBVR14-78
  • Legacy Issue Number: 9943
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    ISSUE: Major Categories of 'Thing' Need to be Related and Made Clear Important in any case, but especially so with the inclusion of 'objects' as vocabulary entires, the major concepts that are subcategories of 'thing' such as 'state of affairs', 'actuality', 'expression', 'res', 'object', (as defined by the terminology community), etc. need to be related and clarified to such the major divisions of 'thing' that are significant in SBVR of SBVR. This will make the real world cornerstone of SVCR much clearer for new audiences.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:45 GMT

SBVR Issue - Context for understanding representations

  • Key: SBVR14-85
  • Legacy Issue Number: 9933
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Context for understanding representations

    A definition given for a fact type commonly refers to the roles of the fact type using placeholders from a form of expression of the fact type. But the SBVR vocabulary provides no relationship between a definition and the form of expression for which the definition makes sense (the one having the placeholders used in the definition). A new fact type must be added to SBVR in order to capture this relationship. Otherwise there is insufficient context to interpret the definition. The problem occurs because there can be many forms of expression for a fact type, and these can uses different designations for placeholders.

    A similar problem occurs where a note or example for a concept only makes sense in relation to a particular designation or form of expression, such as when the example or note refers to the designation or a placeholder of the form of expression. Similarly, the expression of a reference supporting a concept often does not include the designation used in a source document because the reference is given in relation to that particular designation for the concept. But if there are many designations for the concept, the reference cannot be adequately interpreted with respect to the source document.

    Also, a note about a rule might make sense only in the context of a particular statement of the rule because the note refers to specific words used in the rule. But the same rule can be represented by many different statements.

    Recommendation: Add a new fact type to the Meaning and Representation Vocabulary after ‘representation represents meaning’:

    representation relates to representation

    And explain that the first representation is understood in the context of the second representation.

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

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 29 Dec 2016 14:42 GMT

Regroup Concepts into Diagrams and Update Narrative Text based on the Resequenced SBVR Table of Contents

  • Key: SBVR12-105
  • Legacy Issue Number: 19439
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
    Summary:
    The resolution to SBVR Issue 18377 (and Issues 17097,17452,19276 merged into it) restructured the SBVR Table of Contents for greater clarity, regrouped the SBVR terminological entries under the new sub-clauses, and updated Clause 2 conformance to align it with the conformance approach in Simplified UML.
    Given the new SBVR Table of Contents and revised Clause 2 Conformance:
    • Since the SBVR Figures are derived from the SBVR terminological entries, they need to be redrawn based on the grouping of concepts under sub-clauses
    • The Clause 8, 11 & 12 narrative text needs to be moved into the new document structure described in the resequenced Table of contents, and updated as required.
    Resolution:
    1. Produce a new set of diagrams that group the concepts the way they are grouped in the sub-clauses given in the resequenced SBVR Table of Contents.
    2. Add edit instructions to move the existing SBVR v1.2 narrative text as revised by SBVR V1.3 Ballot 1 and 2 into the equivalent places indicated in the resequenced SBVR Table of Contents.
    3. Update narrative text with new clause / sub-clause reference numbers and the Ballot 2 revisions to SBVR v1.2 Clause 7.

  • Reported: SBVR 1.1 — Fri, 30 May 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1. Produce a new set of diagrams that group the concepts the way they are grouped in the sub-clauses given in the resequenced SBVR Table of Contents.
    2. Move the existing SBVR v1.2 narrative text as revised by SBVR V1.3 Ballot 1 and 2 into the equivalent places indicated in the resequenced SBVR Table of Contents.
    3. Update narrative text
    a. with new clause / sub-clause reference numbers and the Ballot 2 revisions to SBVR v1.2 Clause 7,
    b. to clean a few references to things no longer in Clause 2, and
    c. to update introductory text for Part II and Part III to match the revised Table of Contents.
    NOTE: The SBVR XMI Metamodel is generated from the terminological entries in SBVR v1.2 Clauses 7, 8, 9, 11 & 12 (and their equivalent SBVR v1.3 Clauses 7 through 21) according to the transformation rules in SBVR v1.2 Clause 13 (SBVR v1.3 Clause 23). Since this Issue Resolution makes no changes to terminological entries except to update clause references, this Issue Resolution has no impact on the SBVR XMI Metamodel; i.e. the SBVR XMI Metamodel is not changed in any way by this Issue Resolution.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Styling of SBVR terms/wordings in vocabulary clauses

  • Key: SBVR12-104
  • Legacy Issue Number: 19362
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Some words/phrases used in SBVR vocabulary entry Definition subentries that are the expressiosn of SBVR-defined designations are unstyled. Add appropriate styling to words/phrases used in SBVR Definition subentries where the unstyled words/phrases used were intended to have the meaning as defined in SBVR, rather than a different natural language meaning.

  • Reported: SBVR 1.1 — Fri, 25 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Add appropriate styling to terms/wordings used in SBVR Definition clauses where the terms/verbs used have the meaning as defined in SBVR .

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Misc. styling & caption fixes

  • Key: SBVR12-98
  • Legacy Issue Number: 19355
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Some entries of SBVR 1.2 have styling and captioning errors that need to be fixed

  • Reported: SBVR 1.1 — Wed, 23 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1) the entry "unitary verb concept" has a styling error in the 1st Necessity.
    Here is how the entry appears in SBVR 1.2:

    The term "unitary verb concept" should be in term styling.
    2) the entry "proposition is possibly true" is missing a caption.
    Here is how the entry appears in SBVR 1.2:

    The second line of text needs a "Possibility:" caption, the first word of the sentence needs to be capitalized, and the wording needs to be clarrified.
    3) The entry "proposition is obligated to be false" has a styling error in its Definition text.
    Here is how the entry appears in SBVR 1.2:

    The word "not" should be in keyword styling.
    4) The entry "concept has implied characteristic" has a styling error in its Definition text.
    Here is how the entry appears in SBVR 1.2:

    The word "does" should be in verb styling.
    5) the entry "categorization scheme contains category" is missing a caption.
    Here is how the entry appears in SBVR 1.2:

    The line following the Synonymous Form caption — i.e., with the value "partitive verb concept" — needs a "Concept Type:" caption.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Consolidate 2 entries for 'verb concept wording'

  • Key: SBVR12-103
  • Legacy Issue Number: 19360
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    In SBVR 1.2, there are 2 verb concept entries for the same meaning: “verb concept incorporating verb symbols”. This resulted from SBVR meaning and representation entries being arbitrarily separated into two clauses.
    It is clear from

    the “Note:” under ‘verb concept wording demonstrates designation’;
    the “See:” under ‘verb concept wording incorporates verb symbol’;
    the lack of a definition under ‘verb concept wording incorporates verb symbol’;
    the definition of verb symbol; and
    all the subentries of 'verb concept wording'
    that these are already intended to be the same meaning that is split across two clauses.

    In addition, the definition under ‘verb concept wording demonstrates designation’ is quite opaque and needs to be worded more like the Note.

    The verb concept wording ‘verb concept wording incorporates verb symbol’ most accurately gathers up the meaning and should therefore be the preferred verb concept wording.

  • Reported: SBVR 1.1 — Thu, 24 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    In the SBVR restructuring work these two entries now appear in the same sub-clause, where they should be combined into a single entry with a clarified definition as follows:
    verb concept wording incorporates verb symbol
    Definition: the verb concept wording shows a pattern of using the expression of the verb symbol plus expressions of the placeholders for each of the roles of the verb concept that has the verb concept wording
    Synonymous Form: verb symbol is incorporated into verb concept wording
    Synonymous Form: verb concept wording demonstrates designation
    Necessity: Each verb concept wording incorporates at most one verb symbol.
    Necessity: Each verb symbol is incorporated into at least one verb concept wording.
    Note: If a verb concept wording demonstrates a designation, the signifier of that designation is what is seen in the expression of the verb concept wording when placeholder expressions have been removed.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Add entry for "element" Source

  • Key: SBVR12-102
  • Legacy Issue Number: 19359
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    In SBVR 1.2, a vocabulary entry for "element" is missing. This term appears (formally styled in term styling) in the verb concept wording "set has element", but the supporting vocabulary entry for the concept termed "element" is missing. (The term "element" is, therefore, also missing from the Index.)

  • Reported: SBVR 1.1 — Fri, 25 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    A vocabulary entry for "element" needs to be added. Also, the Definition-captioned text of the related entry "thing is in set" needs to be corrected to avoid the use of "element" as an unstyled (informally understood) concept in stating the meaning of the verb concept where this concept plays a role.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

Consolidating 2 verb concept entries that mean concept incorporating characteristics

  • Key: SBVR12-101
  • Legacy Issue Number: 19358
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    In SBVR 1.2, there are 2 verb concept entries for the same meaning: “concept incorporating characteristics”. This resulted from SBVR meaning and representation entries being arbitrarily separated into two clauses. They need to be consolidated into a single entry.

  • Reported: SBVR 1.1 — Thu, 24 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    In the SBVR restructuring work, these two entries now appear in the same sub-clause, where they should be combined into a single entry, as:
    concept incorporates characteristic FL
    Definition: the characteristic is an abstraction of a property of each instance of the concept and is one of the characteristics that makes up the concept
    Synonymous Form: characteristic is essential to concept
    Synonymous Form: concept has essential characteristic
    Concept Type: is-role-of verb concept

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Misc. typo fixes

  • Key: SBVR12-100
  • Legacy Issue Number: 19357
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    Correct typos in SBVR 1.2:

    The Necessity for "proposition" (p. 29) uses "very" where "verb" is intended.
    'proposition' is misspelled in the 2nd Necessity of "statement" (p. 34).
    The first vocabulary entry at the top of p. 45 uses the entry term "state of affairs". It should be "actuality". (The entry for "state of affairs" correctly appears on p. 43.)
    The Definition text for "speech community representation set" (p. 168) should not begin with an article.
    The Definition text for "enforcement level" (p. 176) should not begin with an article.

  • Reported: SBVR 1.1 — Wed, 23 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Make the corrections.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Consolidating 2 verb concept entries that mean

  • Key: SBVR12-99
  • Legacy Issue Number: 19356
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    In SBVR 1.2, there are 2 verb concept entries for the same meaning: “concept generalization/specialization”. This resulted from SBVR meaning and representation entries being arbitrarily separated into two clauses. They need to be consolidated into a single entry.

  • Reported: SBVR 1.1 — Wed, 23 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    clause, where they should be combined into a single entry, as:
    concept1 specializes concept2 FL
    Definition: the concept1 incorporates each characteristic that is incorporated by the concept2 plus at least one differentiator
    Synonymous Form: concept2 generalizes category1
    Synonymous Form: concept1 has more general concept2
    Synonymous Form: concept2 has category1
    Clarify the definition of concept1 specializes concept2 by making it fully formal:
    Definition: the concept1 incorporates each characteristic that is incorporated by the concept2 and the concept1 incorporates at least one characteristic that is not incorporated by the concept2

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue: Correct the wording of text in Semiotic/Semantic Triangle diagram callout

  • Key: SBVR12-97
  • Legacy Issue Number: 19354
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    The figure for the Semiotic/Semantic Triangle (Figure 8.9 of SBVR 1.2) should say "terminological dictionary" rather than "business vocabulary" so that it is parallel with the term 'rulebook' in that diagram.

  • Reported: SBVR 1.1 — Wed, 23 Apr 2014 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1. Correct the text in Figure 8.9 [SBVR 1.2] to read "Terminological Dictionary" rather than "Business Vocabulary"
    2. Add the following text to the end of the last sentence in the narrative of SBVR 1.2, sub-clause 8.6.2 — "; i.e., the world of the organization that uses the Terminological Dictionary and/or Rulebook" — so that the complete, final sentence reads:
    But the following necessities are about the correspondence of meanings to things in the universe of discourse; i.e., the world of the organization that uses the Terminological Dictionary and/or Rulebook.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

Re-Sequencing SBVR

  • Key: SBVR12-96
  • Legacy Issue Number: 19276
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    For many years, I have been critical of the organization of SBVR. It's overall structure was neglected during the periods of rapid development. As a result the SBVR document proves difficult to approach – needlessly so.

    Earlier this year, I was tasked with working on re-sequencing the material. After months of careful consideration, my proposed reorganization is attached. The work is directly based on, and builds from, team discussion and consensus from earlier this year.

    In place of the three existing Clauses 8, 11 and 12, I am proposing the following 9 replacements:

    • 8 Vocabulary for a Community's Meanings
    • 9 Vocabulary for a Community's Representations
    • 10 Vocabulary for a Community's Terminology
    • 11 Vocabulary for Concept System Structure
    • 12 Vocabulary for an Authority's Business Rules
    • 13 Vocabulary for an Authority's Business Rule Statements
    • 14 Fundamental Principles for Business Rules
    • 15 Vocabulary for Collections of Meanings and Representations
    • 16 Vocabulary for Adoption

    Ironically, I personally do not agree with some of the placement of entries and sections. However, I tried to take into account the concerns and preferences (at least as far as I understand them) of all team members. I have proposed a holistic solution, so please understand and evaluate it that way.

    Notes and Observations

    • The resequencing did not require as many Clauses as I earlier anticipated. There are only 3x more than at present.
    • Nowhere does the material dip below 3 levels of structure (2 levels of subclauses). For approachability, I strongly recommend staying within 3 levels.
    • I did not strictly adhere to the rule of "no use of a term in definitions until the term is itself defined". The Chair advised that even ISO had not done this. However, it's certainly a good rule of thumb to follow. whenever possible.
    • Before the new Clauses 15 & 16, which are focused on different themes than the new Clauses 8-14, I stuck to the strict rule of not mixing meanings and representations in the same Clause. I think that rule dramatically improves approachability for those Clauses.
    • Although the new proposed headings and subheadings are not normative (I believe), they are crucial for understanding and accessibility. I considered all choices carefully. I purposely prefixed all 1st and 2nd level (sub)headings with "Vocabulary for ...". I think a constant reminder of what SBVR is about will prove very helpful. (Some subsets of terminology are 'deep'.) Since non-normative (unless I'm wrong), I chose optimal descriptiveness over compulsive precision.
    • The hardest work is likely to be with the very first new Clause (8). These are very fundamental entries from early on in SBVR's development and have suffered from the most entropy. (So don't be discouraged after looking at only that document.)
    • I found a few outlier entries that seemed wildly out of place in their current positions (not too many). You might or might not notice their proposed new placement.
    • I included a lot of attention points to omitted stylings of terms in definitions. (I probably didn't catch them all.) It's very important that we clean this up. I believe it's pure editorial work? (I might be wrong.)
    • The proposed re-sequencing needs to be carefully checked for inadvertent omissions. I did the best I could using documents previously created and others available to me.
    • I have purposely included a number of suggestions and recommendations that either already are, or would need to be, issues. (They are are carefully highlighted in red.) In general, they are mostly related to improving approachability, (In particular I have included notes about my own issues. This is my way of tracking them, as they never seem to bubble up to the agenda. They should not be considered part of the resequencing work per se, although obviously related.)
    • I did not try to address Clauses 9, 10 and 13 (and 14 and 15). All 5 of these Clauses should come after the 9 proposed Clauses above. IMO, I don't think these 5 Clauses should be sequenced as at present. I feel confident there is some overall logical sequencing to be found for them (too). I do feel that existing Clause 10 should be broken into 4 separate Clauses, along the lines of its current 4 subclauses. I haven't studied Clause 9 well enough to know what to recommend there.

    Even though the Chair initiated this whole-document resequencing initiative, I'm not sure there's actually an issue for it. (My original issues applied only to resequencing Clauses 8 and 11 individually.) Obviously there needs to be an issue (if none at present).

    Finally, I am currently on an around-the-world speaking 'tour' including South Africa and Australia for the next 3+ weeks. Please carefully consider the proposal as a whole. I believe the real SBVR shines through.

  • Reported: SBVR 1.1 — Mon, 3 Mar 2014 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Merger with Issue 18377

  • Updated: Tue, 14 Apr 2015 17:27 GMT

Simplification of SBVR by Integrating Clauses 8 & 11

  • Key: SBVR12-95
  • Legacy Issue Number: 18377
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Simplification of SBVR by Integrating Clauses 8 & 11 which Cover the Same Topics and Removing Multiple Compliance Points
    Source:
    Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
    Summary:
    It is not possible to see all of the SBVR “Meaning and Representation” model constructs (terminological entries) on the same subtopics in one place because there are split almost evenly between Clause 8 and Clause 11.
    Since “Meaning” and “Representation” are the foundation topics of SBVR, this is a particularly significant problem.
    It is not easy to see how the whole of SBVR fits together on any one topic. Ambiguities, inconsistencies, and internal disconnects, which lead to significant confusion and misinterpretation, are masked and therefore persist.
    In addition there are a number of Issues that require moving terminological entries between Clause 8 and Clause 11, with equal arguments for having then in both Clauses.
    Further, it is not possible to re-sequence the entries in Clause 8 and Clause 11 in a cohesive way while those two clauses remain as separate top level SBVR Clauses.
    Part of the simplification of SBVR to gain full benefits should follow the example of Simplified UML. UML v2.5 has removed separate conformance levels related to subject areas and relies on vendors providing lists of specific model constructs that they support.
    SBVR already has a very formal requirement for providing list of model constructs supported. Since conformance is already defined in SBVR at the terminological entry level, removing the four level 1 Clause conformance levels will free up the structure of SBVR Clauses to enable the principles below to be implemented.
    Resolution:
    1. Integrate the terminological entires in Clauses 8 and 11 by subtopic.
    2. Remove the four Comformance Levels following the example of UML 2.5.
    Revised Text:
    … to follow

  • Reported: SBVR 1.1 — Fri, 18 Jan 2013 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1. Restructure the SBVR Table of Contents and Regroup/Resequence Terminological Entries from Clauses 8, 11 & 12 under the New Sub-clauses following these principles:
    General Simplification / Clarification Guidelines
    • As part of the simplification of UML, UML v2.5 removed separate conformance levels related to subject areas and now relies on vendors providing lists of specific model constructs that they support.

    SBVR already has a formal requirement at the terminological entry level for providing a list of model constructs supported. Since conformance is already defined in SBVR, it has remained essentially unchanged. Four level-1 Clause conformance levels were removed, thereby freeing up the SBVR clause structure to enable the principles below to be implemented.
    • No changes are proposed to any individual SBVR vocabulary entries in the SBVR Re-sequencing/Reorganizing Issue Resolutions (Ballots 2 & 3) except for updating of clause references.
    o After ballot 3, consistency of styling will be addressed as a separate issue.
    Clause Grouping Guidelines used in the proposed resequencing
    • Existing Clauses 8 and 11, which extensively covered the same topics, have been consolidated and reorganized into topic-focused subclauses.
    • The depth of clause levels has been limited to 3 in all cases. This approach avoids poorly-differentiated, confusing ‘deep dives’ into narrowly-focused topical areas. Some clauses have only 2 levels; 3 levels were not forced where unnecessary. The number of level-1 clauses has been more than doubled to provide clearer, more selective entry points into overall document content.
    • Short, descriptive clause headings were chosen at each of the 3 levels. These headings focus on essential subject matter, not mechanics or underlying assumptions. This approach keeps them as understandable and as unbiased as possible.
    • The reorganization makes it easy for business users who are primarily concerned with terminological dictionary content to recognize the SBVR clauses they need for concept definitions and definitional rules. Similarly, those primarily concerned with rulebooks can easily recognize the SBVR clauses they need for behavioral guidance.
    • "Meaning" entries and "representation" entries have been included under the same level-1 clause only in special circumstances (e.g., the guidance clauses). This separation visibly reflects the importance of the distinction between these kinds of entries, a fundamental principle in SBVR.
    • With a few important exceptions, including those listed below, sets and collections (sometimes referred to as “containers”) are treated in their own unified clause. This clause, which includes vocabularies, terminological dictionaries and rulebooks, forms a natural grouping of entries. These containers are quite different from the individual things making them up. This new clause has been placed after all clauses that introduce the kinds of individual members the containers might include. Also, the definitions and relationships of these containers are carefully separated from the verb concepts that indicate what goes into them.
    o Exception: The concept “extension” is included in the very first clause since it is fundamental to understanding of Semiotic Triangle, part of the linguistic foundation of SBVR.
    o Exception: Communities and Authorities are included in an early, level-1 clause. Without them, no meanings or elements of guidance can be birthed.
    • Adoption also forms a natural grouping in its own right and therefore is the basis of a new clause. This new clause follows the new clause on sets and collections (containers).
    Terminological Entry Grouping Guidelines
    • The re-sequencing and reorganization of entries is based on natural groupings, which build logically from one to the next. Generally (but not always) this permits introduction of terminological entries before they are referenced by other entries.
    • List verb concepts near the general concepts and roles they refer to.
    • List synonyms and antonyms near each other.
    • List 2 concepts that exhibit an interesting difference near each other.
    • Sub-clauses have been kept as small as possible, and based on tightly-related concepts. In turn, this permits small, focused diagrams to illustrate them.
    Unchanged Clauses
    • No changes were made to existing Clauses 1 and 3-6, except for clause reference numbers.
    • The following existing Clauses have not been re-sequenced or reorganized. They have been placed (and renumbered) after all business vocabulary and business rules level-1 clauses, as well as the new clauses devoted to sets and collections (“containers”) and adoption.
    .1. Clause 9 “Logical Formulation of Semantics Vocabulary”.
    .2. Clause 10 “Providing Semantic and Logical Foundations for Business Vocabulary and Rules”.
    .3. Clause 13 “SBVR’s Use of MOF and XMI”.
    .4. Clause 15 “Supporting Documents”.
    • The existing Clause 14 “Index of Vocabulary Entries (Informative)” will be regenerated from terminological entry headings.

    2. Align SBVR Clause 2 Conformance with Simplified UML Conformance and the SBVR Restructured Table of Contents
    The three objectives required to accomplish this alignment are to:
    • Add the equivalent of the two Simplified UML Types of Compliance that are relevant to SBVR.
    • Remove all references to specific compliance points except for the overall compliance with the SBVR specification.
    • Clean up language to use terms agreed for SBVR v1.2 and simplify wording for clarity.
    In the revised Clause 2 Conformance, Sub-clause 2.2 follows the pattern of Simplified UML where a parallel exists:

    Simplified UML SBVR v1.3
    Abstract syntax conformance Abstract syntax conformance
    Concrete syntax conformance (not applicable – no normative SBVR syntax)
    Model interchange conformance Terminological Dictionary and/or Rulebook interchange conformance
    Diagram interchange conformance (not applicable – no normative SBVR syntax)
    Semantic conformance Semantics conformance

    Sub-clause 2.2 provides the specifics for “support for SBVR concepts that are defined in Clauses 8-21 of this specification and implemented in the SBVR XMI Metamodel as specified in Clause 23”
    Sub-clause 2.4 provides the specifics for “Terminological Dictionary and/or Rulebook interchange conformance”.

    3. Spin-off SBVR Issue 19439 for regrouping of concepts in SBVR Diagram Figures based on the Restructured SBVR Table of Contents and make fixes to narrative text resulting from Items 1. and 2. above.

    Note: Except for Clause 2 Conformance, Clause 13 SBVR’s Use of MOF and XMI, and the four Vocabulary Container Headers, references in narrative text to the removed vocabularies are updated in this Spin-off Issue.

  • Updated: Tue, 14 Apr 2015 17:27 GMT

New SBVR issue - Re-sequencing Clause 8

  • Key: SBVR12-94
  • Legacy Issue Number: 17452
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

    All, The re-sequencing of Clause 11 has initially proven quite worthwhile, so I have been encouraged to do similar work on Clause 8. As before, I made no changes to the entries themselves whatsoever. (If I did, it was purely an error and should be corrected. Also, my work should be double-checked for any entries inadvertently omitted.) I used a Word version kindly supplied by Linda Heaton, which I believe is from the latest convenience document. (It does have some styling problems, which I have noted.) I hope we can move forward with this revision expeditiously. By the way, I found this re-sequencing much harder than Clause 11, which I am much more familiar with.

    Ron

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

    Problem Statement: SBVR adheres to ISO 1087 as much as possible. Clearly evident in the structure of ISO 1087 is that no definition should appear until all terms within it have been defined (as needed). This best practice (rule) results in a logical, easy-to-follow presentation. Clause 8 of SBVR is clearly broken in this regard. The result is significant lack of clarity, making detection of errors unnecessarily difficult. The possibility of misinterpretation (or non-comprehension) by software engineers and other readers is high.

    Resolution: Apply the ISO 1087 rule about sequencing vocabulary entries rigorously. This re-sequencing requires no changes in the entries themselves (but does suggest some). Two files containing all Clause 11 entries are attached. One file is unchanged except that entries are numbered. The other file is re-sequenced. The entry numbers reappear in the re-sequenced file indicating the original location of each entry. New subheadings are suggested.

  • Reported: SBVR 1.1 — Wed, 27 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Merger with Issue 18377

  • Updated: Tue, 14 Apr 2015 17:27 GMT

SBVR issue - Re-sequencing Clause 11

  • Key: SBVR12-93
  • Legacy Issue Number: 17097
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Problem: SBVR adheres to ISO 1087 as much as possible. Clearly evident in the structure of ISO 1087 is that no definition should appear until all terms within it have been defined (as needed). This best practice (rule) results in a logical, easy-to-follow presentation. Clause 11 of SBVR is clearly broken in this regard. The result is significant lack of clarity, making detection of errors unnecessarily difficult. The possibility of misinterpretation (or non-comprehension) by software engineers and other readers is high.

    Aside: Personally I think this solution amounts to simple editing because anyone could apply the ISO 1087 rule without understanding a thing about the content. However, since some might see new headings or groupings as somehow conveying meaning – never the case in SBVR – I have nonetheless requested an issue. There are also a few choices about optimizing placement.

    Note: *This issue can be resolved without using any meeting time.*

    Resolution: Apply the ISO 1087 rule about sequencing vocabulary entries rigorously. This re-sequencing requires no changes in the entries themselves.

    Attachments: Two files containing all Clause 11 entries are attached. One file is unchanged except that entries are numbered. The other file is re-sequenced. The entry numbers reappear in the re-sequenced file indicating the original location of each entry. Unfortunately, this working version does not use the latest version of SBVR … I did not have the source file for that. However, since no changes to the entries themselves are covered by this issue, the version used is largely immaterial to illustrate the proposed resolution. The lay-out simply needs to be re-done for the newer material.

  • Reported: SBVR 1.1 — Sun, 5 Feb 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Merger with Issue 18377

  • Updated: Tue, 14 Apr 2015 17:27 GMT

Definition of Vocabulary

  • Key: SBVR11-141
  • Legacy Issue Number: 15314
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

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

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

    DISCUSSION:

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

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

    (a) ISO says (1087):

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

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

    (b) MWUD says:

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

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

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

    PROPOSED RESOLUTION:

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

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

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

    ADDITIONAL DISCUSSION

    Re: "terminological dictionary"

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

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

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

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

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

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

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

    Ron,

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

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

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

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

    All,

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

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

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

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

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

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

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

    An ABC would not include ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Possible objections:

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

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

    "verbal model" or "verbalization model" -

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

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

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

    "structured business vocabulary" -

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

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

    The current definition of "vocabulary" in SBVR is:

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

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

  • Reported: SBVR 1.0 — Wed, 30 Jun 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

  • Updated: Sun, 8 Mar 2015 17:59 GMT

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

  • Key: SBVR_-60
  • Legacy Issue Number: 10803
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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

Two SBVR Normative Definitions Use Deontic Logic in Error

  • Key: SBVR_-57
  • Legacy Issue Number: 10798
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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

Definition of 'fact type'

  • Key: SBVR_-59
  • Legacy Issue Number: 10801
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

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 ( Mr. Donald R. 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: Google ( 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: Trisotech ( Ms. Keri Anderson 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: Trisotech ( Ms. Keri Anderson 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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

SBVR Issue - Restrictions on Variables

  • Key: SBVR_-46
  • Legacy Issue Number: 10596
  • Status: closed  
  • Source: Google ( 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

Align Annex E with the normative text

  • Key: SBVR_-49
  • Legacy Issue Number: 10628
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Donald R. 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

Section: 12.1.1

  • Key: SBVR_-45
  • Legacy Issue Number: 10580
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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

‘expression’ as a bindable target

  • Key: SBVR_-37
  • Legacy Issue Number: 10570
  • Status: closed  
  • Source: Google ( 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

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

  • Key: SBVR_-39
  • Legacy Issue Number: 10572
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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 ( Mr. Donald R. 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

Simple Fixes - editorial issues

  • Key: SBVR_-36
  • Legacy Issue Number: 10569
  • Status: closed  
  • Source: Google ( 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: Google ( 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: Google ( 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: Trisotech ( Mr. 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: Trisotech ( Mr. 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: Google ( 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

Exceptions

  • Key: SBVR_-27
  • Legacy Issue Number: 10506
  • Status: closed  
  • Source: Trisotech ( Mr. 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

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: Trisotech ( Mr. 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

Universal AND

  • Key: SBVR_-26
  • Legacy Issue Number: 10505
  • Status: closed  
  • Source: Trisotech ( Mr. 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: Trisotech ( Mr. 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: Trisotech ( Mr. 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: Trisotech ( Ms. Keri Anderson 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

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: Google ( 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

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

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: Google ( 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 ( Mr. Edward J. 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

SBVR 1.2] 'level of enforcement' editorial correction

  • Key: SBVR12-90
  • Legacy Issue Number: 18658
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    In Clause 12.1.3 the preferred term for enforcement of a behavioral (operative) business rule is 'level of enforcement'. This concept is used only in examples in the specification - SBVR itself contains no behavioral business rules. In some examples (including the one in Clause 12.1.3) the older term 'Enforcement Level' is used. 'Enforcement Level' is not defined as a synonym for 'level of enforcement'.

    An editorial correction is needed to replace each occurrence of 'Enforcement Level' with 'level of enforcement'.

  • Reported: SBVR 1.1 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Since “level of enforcement” is used nowhere else in the SBVR specification and “enforcement level” is the preferred term for this concept in the Business Motivation Model, replace “level of enforcement” with "enforcement level" as the preferred term and add “level of enforement’ as a synonym.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

SBVR 1.1 typos - p. 100 (logics modality table)

  • Key: SBVR12-89
  • Legacy Issue Number: 18524
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    I spotted some typos in the logics table on p. 100 (PDF p. 114) of the SBVR 1.1 Convenience draft. Attached is an annotated screenshot of the errors.

    To summarize, the errors are in column 3 of the deontic section:

    the bold, capital letters need to be in italics (to match the legend on the following page, as well as the other places where these symbols appear).

    the small 'p' needs to be in italics (to match the legend on the following page, as well as the other places where this symbol appears).

  • Reported: SBVR 1.1 — Fri, 1 Mar 2013 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Make the edit corrections as identified in Issue Summary

  • Updated: Fri, 6 Mar 2015 23:16 GMT

New issue: Individual Verb Concept

  • Key: SBVR12-88
  • Legacy Issue Number: 17451
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    OMG Issue No: 17451
    Title: Fix the anomaly in the subcategory structure of ‘concept’ to include ‘individual verb concept’ in SBVR
    Source:
    RuleML Initiative, John Hall, (john.hall@modelsystems.co.uk)
    Summary:
    SBVR handles noun concepts and verb concepts asymmetrically:
    • ‘concept’ generalizes ‘noun concept’ and ‘verb concept’
    • ‘noun concept’ generalizes ‘general concept’ and ‘individual concept’ – i.e. ‘general concept’ means ‘general noun concept’ and ‘individual concept’ means ‘individual noun concept’
    There are no equivalents for ‘verb concept’. SBVR does not explicitly define ‘individual verb concept’, so cannot say:
    • ‘individual concept’ generalizes ‘individual noun concept’ and ‘individual verb concept’ (inheriting from: ‘concept’ generalizes ‘noun concept’ and ‘verb concept’)
    • ‘verb concept’ generalizes ‘general verb concept’ and ‘individual verb concept’ (paralleling: ‘noun concept’ generalizes ‘general noun concept’ and ‘individual noun concept’)
    If it did, this structural inconsistency would be removed.
    It would also be helpful in using SBVR. Individual noun concepts, such as “EU-Rent” and “Luxembourg”, are useful in defining bodies of shared meanings in SBVR. If SBVR included ‘individual verb concept’, an SBVR body of shared meanings could include individual verb concepts such as “EU-Rent is incorporated in Luxembourg”.
    Resolution:
    1. Change the preferred term that is currently ‘individual concept’ to ‘individual noun concept’ to clarify that it applies to noun concepts only
    2. Add the concept ‘individual verb concept’ for a proposition that is a Clause 8 verb concept with all its roles quantified (closed) by individual (noun) concepts to fix the anomaly in the subcategory structure of ‘concept’.

    Revised Text:
    On printed page 22 in Clause 8.1.1
    REPLACE the current term heading “individual concept” WITH “individual noun concept”

    And REPLACE “concept”, the first term in the definition, WITH “noun concept”

    On printed page 27 in Clause 8.1.2 at the end of the clause ADD this entry for ‘individual verb concept’:

    individual verb concept

    Definition: proposition that is based on exactly one verb concept in which each verb concept role is filled by an individual noun concept
    Note: … some explanatory comments
    Example: … some illustrative examples

    REPLACE the signifier “individual concept” WITH “individual noun concept” in the following places (but not in the “Source” subentry reference to ISO 1087-1 in entry for the concept current termed “individual concept’)

    • … to be identified and added

    REPLACE the following diagrams WITH diagrams that repolace the signifier “individual concept” with “individual noun concept”:

    • Figure 8.1
    • Figure 9.3
    • Figure 11.2

    … plus fixes for any additional side effects:

  • Reported: SBVR 1.1 — Thu, 21 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    withdrawn by submitter, duplicate of issue 17439

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Mysteries & miscellany

  • Key: SBVR-126
  • Legacy Issue Number: 11300
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson 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: Trisotech ( Ms. Keri Anderson 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

One global change too far

  • Key: SBVR-122
  • Legacy Issue Number: 11295
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson 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: Trisotech ( Ms. Keri Anderson 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

Corrected Fig. 11.6

  • Key: SBVR-124
  • Legacy Issue Number: 11298
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson 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: Trisotech ( Ms. Keri Anderson 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

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: Google ( 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

Correct styling in characteristic

  • Key: SBVR-120
  • Legacy Issue Number: 11293
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson 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: Trisotech ( Ms. Keri Anderson 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

Sjir Nijssen Revisions to Clause 10

  • Key: SBVR-113
  • Legacy Issue Number: 11264
  • Status: closed  
  • Source: Trisotech ( Mr. 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: Trisotech ( Mr. 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

Section 9.3 editorial

  • Key: SBVR-116
  • Legacy Issue Number: 11289
  • Status: closed  
  • Source: Google ( 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: Google ( 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: Google ( 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

"Definition of Category"

  • Key: SBVR-111
  • Legacy Issue Number: 11153
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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

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

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

Definition of proposition

  • Key: SBVR11-137
  • Legacy Issue Number: 16526
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Wed, 31 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"Quantification" Needs to Be Renamed

  • Key: SBVR11-136
  • Legacy Issue Number: 16525
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

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

    Resolution:

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

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

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

  • Reported: SBVR 1.0 — Fri, 26 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Simplification of presentation of Annex E

  • Key: SBVR11-140
  • Legacy Issue Number: 17068
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 27 Jan 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Actuality demonstrates Proposition

  • Key: SBVR11-139
  • Legacy Issue Number: 16630
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Wed, 19 Oct 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

'Variable' should be renamed as 'formulaic variable' or its meaning clarified

  • Key: SBVR11-138
  • Legacy Issue Number: 16555
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Sat, 17 Sep 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"Objectification" Needs to Be Renamed

  • Key: SBVR11-132
  • Legacy Issue Number: 16491
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

    Resolution:

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

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

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

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

  • Reported: SBVR 1.0 — Fri, 12 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Issue - Relationships between States of Affairs

  • Key: SBVR11-131
  • Legacy Issue Number: 16486
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 5 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

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

    Revised Text:
    No Change

    Disposition: No Change

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

"Projection" Needs to Be Renamed

  • Key: SBVR11-135
  • Legacy Issue Number: 16524
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

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

    Resolution:

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

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

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

  • Reported: SBVR 1.0 — Fri, 26 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"Aggregation Formulation" Needs to Be Adjusted

  • Key: SBVR11-134
  • Legacy Issue Number: 16523
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

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

    Resolution:

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

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

  • Reported: SBVR 1.0 — Fri, 26 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"Nominalization" Needs to Be Renamed

  • Key: SBVR11-133
  • Legacy Issue Number: 16522
  • Status: closed  
  • Source: Business Rules Group ( Ronald Ross)
  • Summary:

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

    Resolution:

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

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

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

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

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

  • Reported: SBVR 1.0 — Fri, 26 Aug 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Placeholder concepts model SBVR Structured English syntax

  • Key: SBVR11-109
  • Legacy Issue Number: 15635
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced"

  • Key: SBVR11-108
  • Legacy Issue Number: 15623
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The concept in SBVR Clause 8.1.1 defined as:

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

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

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

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

    Recommended Resolution:

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

  • Reported: SBVR 1.0 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

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

[SBVR] fact type role designation

  • Key: SBVR11-107
  • Legacy Issue Number: 15450
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Wed, 8 Sep 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Set requires distinguished things

  • Key: SBVR11-106
  • Legacy Issue Number: 15404
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

'quantity' and 'number' are not formal logic concepts

  • Key: SBVR11-105
  • Legacy Issue Number: 15403
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

No normative reference to ISO 6093

  • Key: SBVR11-104
  • Legacy Issue Number: 15402
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

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

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

  • Reported: SBVR 1.0 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR - change to Definition of 'fact type'

  • Key: SBVR11-103
  • Legacy Issue Number: 15250
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Sat, 1 May 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

New SBVR Issue: "Template" & "Templating

  • Key: SBVR11-102
  • Legacy Issue Number: 15153
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    11.1.5.1 Kinds of Fact Type

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

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

    Note

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

  • Reported: SBVR 1.0 — Thu, 25 Mar 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Resolved by the Resolution of Issue 13716.

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

SBVR editorial issue

  • Key: SBVR11-111
  • Legacy Issue Number: 15805
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Problem:

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

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

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

    Proposed Resolution:

    Update the diagram on page 192 as follows:

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

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

    Make these changes to the example XML on page 193:

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

  • Reported: SBVR 1.0 — Fri, 5 Nov 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR recognizes the notion of "property" in Clause 11.1.5 in "is-property-of", but never defines the concept directly

  • Key: SBVR11-110
  • Legacy Issue Number: 15684
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

    Resolution:

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

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

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

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

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

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

  • Reported: SBVR 1.0 — Tue, 5 Oct 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Error in Example for "noun concept nominalization"

  • Key: SBVR11-112
  • Legacy Issue Number: 15837
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Thu, 18 Nov 2010 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

inappropriate definitions of burinsss rule, rule statement

  • Key: SBVR11-118
  • Legacy Issue Number: 15950
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

assortment fact types

  • Key: SBVR11-117
  • Legacy Issue Number: 15949
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Inconsistency in is-role-of and is-category-of fact types

  • Key: SBVR11-115
  • Legacy Issue Number: 15947
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Editorial Issue - closed projection defines noun concept

  • Key: SBVR11-114
  • Legacy Issue Number: 15841
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Summary:

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

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

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

    Suggested Resolution:

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

  • Reported: SBVR 1.0 — Tue, 23 Nov 2010 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR - Error in MeaningAndRepresentation-Model.xml

  • Key: SBVR11-113
  • Legacy Issue Number: 15840
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

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

    Proposed resolution:

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

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

  • Reported: SBVR 1.0 — Tue, 23 Nov 2010 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Correct the XML file to match the normative text

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

is-property-of fact types

  • Key: SBVR11-116
  • Legacy Issue Number: 15948
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Issue: What is a fact type form

  • Key: SBVR11-86
  • Legacy Issue Number: 13802
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

    Summary:

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

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

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

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

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

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

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

  • Reported: SBVR 1.0 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Definitions in subsection 11.1.5

  • Key: SBVR11-85
  • Legacy Issue Number: 13716
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540)

  • Key: SBVR11-84
  • Legacy Issue Number: 13138
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Please see attached Word document for Issue details.

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

    • the proposed resolution of this spin-off Issue which will be posted when it has a number;
    • the proposed resolution to Issue 12540; and
    • the proposed resolution of the 11296-1a / 11303-b spin-off Issue which will be posted when it has a number.
  • Reported: SBVR 1.0 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

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

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

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

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

SBVR Issue: can a role range over multiple object types

  • Key: SBVR11-83
  • Legacy Issue Number: 13135
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Note for individual concept does not follow from the Definition

  • Key: SBVR11-82
  • Legacy Issue Number: 12956
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 8.1.1

    Concept: individual concept

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

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

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

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

  • Reported: SBVR 1.0 — Tue, 21 Oct 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Change the definition to match the note

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

fact type 'fact type form incorporates fact symbol' needs additional captio

  • Key: SBVR11-81
  • Legacy Issue Number: 12849
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

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

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

    Synonymous Form: fact type form demonstrates designation

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

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

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

  • Reported: SBVR 1.0 — Thu, 11 Sep 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR typos

  • Key: SBVR11-80
  • Legacy Issue Number: 12614
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

    attached is a dcument containing SBVR typos

  • Reported: SBVR 1.0 — Tue, 29 Jul 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

terminological dictionary

  • Key: SBVR11-77
  • Legacy Issue Number: 12542
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

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

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

editorial issue -- example is missing a line

  • Key: SBVR11-76
  • Legacy Issue Number: 12531
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Mon, 16 Jun 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

"characteristic type" should be a "category type"

  • Key: SBVR11-79
  • Legacy Issue Number: 12589
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

A rulebook should have a URI

  • Key: SBVR11-78
  • Legacy Issue Number: 12543
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

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

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Add “rulebook has URI” in clause 11.2.2.4.

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

URGENT SBVR.xsd issue

  • Key: SBVR11-75
  • Legacy Issue Number: 12165
  • Status: closed  
  • Source: Chronolytics ( David Carlson)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 9 Jan 2008 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

mismatch between diagram

  • Key: SBVR11-74
  • Legacy Issue Number: 11647
  • Status: closed  
  • Source: KDM Analytics ( Spencer Cheng)
  • Summary:

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

  • Reported: SBVR 1.0 — Mon, 12 Nov 2007 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

new SBVR issue - relationship of 'vocabulary' and 'rulebook'

  • Key: SBVR11-101
  • Legacy Issue Number: 15151
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Thu, 25 Mar 2010 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Use of "denotes" in note for "state of affairs"

  • Key: SBVR11-100
  • Legacy Issue Number: 15008
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The note under "state of affairs" reads:

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

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

    Proposed resolution:

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

  • Reported: SBVR 1.0 — Fri, 29 Jan 2010 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Note for Is-Facet-of Fact (Type)

  • Key: SBVR11-90
  • Legacy Issue Number: 13836
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 25 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Use of the Signifier "Fact Model"

  • Key: SBVR11-89
  • Legacy Issue Number: 13835
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 25 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Issue: Model expression structure

  • Key: SBVR11-88
  • Legacy Issue Number: 13804
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

    Summary:

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

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

    Recommendation:

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

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

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

  • Reported: SBVR 1.0 — Thu, 19 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Issue: Definition of signifier

  • Key: SBVR11-87
  • Legacy Issue Number: 13803
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

    Summary:

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

    Recommendation:

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

  • Reported: SBVR 1.0 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Instances of Clause 8 fact type should be states of affairs

  • Key: SBVR11-99
  • Legacy Issue Number: 14849
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 9 Dec 2009 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

Coexistence approach to SBVR

  • Key: SBVR11-96
  • Legacy Issue Number: 14241
  • Status: closed  
  • Source: PNA Group ( Dr. Sjir Nijssen)
  • Summary:

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

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

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

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

  • Reported: SBVR 1.0 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

    Disposition: Resolved with NO CHANGE

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

SBVR Fig 12-1 tweak

  • Key: SBVR11-95
  • Legacy Issue Number: 13996
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

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

  • Reported: SBVR 1.0 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR Issue : Inconsistent use/definition of keyword 'or'

  • Key: SBVR11-94
  • Legacy Issue Number: 13865
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

    Summary:

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

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

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

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

  • Reported: SBVR 1.0 — Mon, 13 Apr 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Clarify the example at the end of C.3.2.1

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

Move the Definitions in Subclause 8.5 to Clause 13

  • Key: SBVR11-98
  • Legacy Issue Number: 14844
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 9 Dec 2009 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

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

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

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

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

Concepts-centric Model and Fact Model are different

  • Key: SBVR11-97
  • Legacy Issue Number: 14843
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

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

  • Reported: SBVR 1.0 — Wed, 9 Dec 2009 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

The segmentation 'Thing in Context' is inconsistent with the definitions of 'role' and 'facet'

  • Key: SBVR11-92
  • Legacy Issue Number: 13850
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR did not pick up the ISO synonym "Part-Whole Relation

  • Key: SBVR11-91
  • Legacy Issue Number: 13849
  • Status: closed  
  • Source: NIST ( Ron S. Ross, Ph.D.)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Definition of Is-Property-Of Fact Type

  • Key: SBVR11-93
  • Legacy Issue Number: 13851
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Explicitness of Representation

  • Key: SBVR11-124
  • Legacy Issue Number: 16101
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

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

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

  • Reported: SBVR 1.0 — Mon, 28 Mar 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Governed Community & Adoption of Business Rules

  • Key: SBVR11-123
  • Legacy Issue Number: 16059
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

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

    Title: Governed Community & Adoption of Business Rules

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

    Summary:

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

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

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

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

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

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

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

    Resolution:

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

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

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

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

    Examples: societies, chartered organizations, businesses, government bodies

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

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

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

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

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

    Revised Text:

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

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

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

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

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

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

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

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

    [2] business rule

    Definition: rule that is under business jurisdiction

    General Concept: rule, element of guidance

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

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

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

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

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

    [3] advice of contingency

    Definition: advice of possibility that is a claim of contingency

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

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

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

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

    [4] advice of optionality

    Definition: advice of permission that is a claim of optionality

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

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

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

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

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

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

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

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

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

  • Reported: SBVR 1.0 — Fri, 11 Mar 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Individual Concept and Change

  • Key: SBVR11-122
  • Legacy Issue Number: 16020
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Sat, 12 Feb 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Example of quantity vs. quantification

  • Key: SBVR11-121
  • Legacy Issue Number: 15972
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

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

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

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

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

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

  • Reported: SBVR 1.0 — Wed, 19 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Adoption of Concepts

  • Key: SBVR11-130
  • Legacy Issue Number: 16375
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Clarify Objectification

  • Key: SBVR11-129
  • Legacy Issue Number: 16309
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 3 Jun 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

A statement may express no proposition

  • Key: SBVR11-128
  • Legacy Issue Number: 16258
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

    Suggested resolution:

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

  • Reported: SBVR 1.0 — Fri, 20 May 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

    Suggested resolution:

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

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

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

Clarify difference between EXISTS and OCCURS

  • Key: SBVR11-127
  • Legacy Issue Number: 16172
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

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

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

  • Reported: SBVR 1.0 — Sat, 7 May 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

SBVR typo - p. 26

  • Key: SBVR11-126
  • Legacy Issue Number: 16171
  • Status: closed  
  • Source: Trisotech ( Ms. Keri Anderson Healy)
  • Summary:

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

  • Reported: SBVR 1.0 — Thu, 5 May 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

Conflation of the signifier “rulebook” with the concept/definition for Speech Community Representations

  • Key: SBVR11-125
  • Legacy Issue Number: 16103
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

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

    Clause: 11.2.2.3

    Printer Page: 155

    Issue Statement:

    The concept (definition) in Clause 11.2.2.3 defined as:

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

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

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

    Proposed Solution:

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

  • Reported: SBVR 1.0 — Wed, 30 Mar 2011 04:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

example elementary fact

  • Key: SBVR11-120
  • Legacy Issue Number: 15952
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

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

example definitions (of "Australian")

  • Key: SBVR11-119
  • Legacy Issue Number: 15951
  • Status: closed  
  • Source: Ajilon ( Graham Witt)
  • Summary:

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.1
  • Disposition Summary:

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

  • 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: Google ( 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

Binding to Individual Concepts

  • Key: SBVR-49
  • Legacy Issue Number: 9586
  • Status: closed  
  • Source: Google ( 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

Mapping SBVR logical formulation terms to formal logic terms

  • Key: SBVR-56
  • Legacy Issue Number: 9623
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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: Trisotech ( Ms. Keri Anderson 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 ( Mr. Donald R. 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

Body of Shared Meanings

  • Key: SBVR-50
  • Legacy Issue Number: 9607
  • Status: closed  
  • Source: Google ( 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

A fact is not a logical formulation

  • Key: SBVR-52
  • Legacy Issue Number: 9609
  • Status: closed  
  • Source: Google ( 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: Google ( 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

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

wrong proposition in 8.1.2 and modal formulation

  • Key: SBVR-78
  • Legacy Issue Number: 9753
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

Section: 8.3, + 11.2

  • Key: SBVR-92
  • Legacy Issue Number: 9941
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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: Google ( 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: Google ( 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

Define ‘true’ and ‘false’

  • Key: SBVR-82
  • Legacy Issue Number: 9882
  • Status: closed  
  • Source: Google ( 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

Complete support for question nominalization

  • Key: SBVR-76
  • Legacy Issue Number: 9733
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

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: Google ( 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

SBVR Issue - Is a representation an actuality?

  • Key: SBVR-86
  • Legacy Issue Number: 9932
  • Status: closed  
  • Source: Google ( 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: Google ( 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

SBVR Issue - Concept Expression versus Meaning Expression

  • Key: SBVR-87
  • Legacy Issue Number: 9934
  • Status: closed  
  • Source: Google ( 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 - 'role has role binding'

  • Key: SBVR-89
  • Legacy Issue Number: 9938
  • Status: closed  
  • Source: Google ( 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: Google ( 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: What is concept1?

  • Key: SBVR-80
  • Legacy Issue Number: 9835
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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: Google ( 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

Section: Annex C

  • Key: SBVR-99
  • Legacy Issue Number: 9950
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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 ( Mr. 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

Section: 11.1.1 page 112

  • Key: SBVR-102
  • Legacy Issue Number: 9955
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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: Clause 10 pages 71 - 108

  • Key: SBVR-106
  • Legacy Issue Number: 9959
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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

SBVR Issue - Projection Diagram - Variable Maps to Role

  • Key: SBVR-96
  • Legacy Issue Number: 9947
  • Status: closed  
  • Source: Google ( 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 ( Mr. Donald R. 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 ( Mr. Donald R. 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

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

Definitions of 'projection'

  • Key: SBVR-61
  • Legacy Issue Number: 9712
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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: Google ( 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

Quantification definitions

  • Key: SBVR-66
  • Legacy Issue Number: 9723
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

True/False meaning of logical formulations must be specified

  • Key: SBVR-72
  • Legacy Issue Number: 9729
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

Meaning of objectification is unclear

  • Key: SBVR-68
  • Legacy Issue Number: 9725
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

SBVR Issue - Circular definition of logical operator and logical operand

  • Key: SBVR-59
  • Legacy Issue Number: 9709
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

Meaning of fact-type formulation and fact type projection

  • Key: SBVR-74
  • Legacy Issue Number: 9731
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

What is an aggregation formulation?

  • Key: SBVR-70
  • Legacy Issue Number: 9727
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

Use of 'modality' in 8.1.2

  • Key: SBVR-63
  • Legacy Issue Number: 9714
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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

Definition of 'proposition'

  • Key: SBVR-64
  • Legacy Issue Number: 9715
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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

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

Implicit Passive Forms

  • Key: SBVR-37
  • Legacy Issue Number: 9467
  • Status: closed  
  • Source: Google ( 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: Google ( 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

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: Google ( 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

Unnecessary Grammatical Structure

  • Key: SBVR-29
  • Legacy Issue Number: 9453
  • Status: closed  
  • Source: Google ( 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: Google ( 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: Google ( 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

Synonymous Statement

  • Key: SBVR-35
  • Legacy Issue Number: 9459
  • Status: closed  
  • Source: Google ( 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: Google ( 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

Fact Type Templating Diagram Error

  • Key: SBVR-31
  • Legacy Issue Number: 9455
  • Status: closed  
  • Source: Google ( 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: Google ( 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

XMI Names for ESBVR

  • Key: SBVR-33
  • Legacy Issue Number: 9457
  • Status: closed  
  • Source: Google ( 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: Google ( 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

Clarify Purpose and Scope of SBVR, the Authority for SBVR Vocabulary Content, and SBVR Vocabularies

  • Key: SBVR12-77
  • Legacy Issue Number: 17414
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Title: Clarify the Purpose and Scope of SBVR, the Authority for SBVR Vocabulary Content, and SBVR Vocabularies Do Not Include Business Instance Data
    Source:
    Business Semantics Ltd, Donald Chapin, (Donald.Chapin@btinternet.com)
    Summary:
    Since SBVR v1.0 was published in January 2008 there has been widespread misinterpretation and misrepresentation of SBVR as a data modeling specification that is not easy to refute with finality because Clause 1 “Scope’ does not make it clear that the authority for the content of an SBVR Vocabulary is the usage of terms and other designations in a corpus of business documentation.
    Further contributing to the problem is the fact that the Subclause 10.1 formal semantics for SBVR is one that is based on a fact-oriented data modeling paradigm. Even though the formal interpretation is meant to be specified only in terms of formal logic there is wide reference to “facts”. Since the representations of facts are what data is, without statements to the contrary this can be used as a basis for incorrectly interpret the SBVR vocabularies in Clause 7, 8, 9, 1 & 12 as a collection of vocabularies for fact-oriented data modeling rather than documentation of the business language used by business people.
    Resolution:
    1. Clarify the Scope of SBVR in Clause 1 to be explicit that SBVR does not include business instance data; and make it clear that the content of an SBVR vocabulary documents the meaning of terms that business authors intend when they use them in their business communications, as evidenced in their written documentation, especially governance documentation.
    2. Add a list of purposes / uses of SBVR
    3. Explain that “Semantic Anchors” are the best way to relate SBVR vocabularies to data models and models for reasoning over data.
    4. Make it clear that SBVR vocabularies are different from all forms of data models models for and reasoning over data..
    5. Make fact an abstract concept in Clause 13.2.2 as instances of business facts (instance data) and fact statements do not go into an SBVR Vocabularies or Rulebooks.
    6. Clean up miscellaneous uses of the word “fact”.
    Revised Text:
    … to follow

  • Reported: SBVR 1.1 — Fri, 8 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1. Clarify the Scope of SBVR in Clause 1 to be explicit that SBVR does not include business instance data; and make it clear that the content of an SBVR vocabulary documents the meaning of terms that business authors intend when they use them in their business communications, as evidenced in their written documentation, especially governance documentation.
    2. Add a list of purposes / uses of SBVR
    3. Make it clear that SBVR vocabularies are different from all forms of data models and models designed for reasoning over instance data.
    4. Make fact an abstract concept in Clause 13.2.2 as instances of business facts (instance data) and fact statements do not go into an SBVR Vocabularies or Rulebooks.
    5. Clean up miscellaneous uses of the word “fact”.

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

"Three Editing Instructions Overlooked in Issue 17017 Resolution

  • Key: SBVR12-76
  • Legacy Issue Number: 17098
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Problem: The Revised Text of 17017 makes no mention of clause 13.2.2.

    In clause 13.2.2, the first paragraph contains the sentence: "The signifier of each synonym of the designation is an alias for the class." Nothing is said in 13.2.2 about how to encode the "alias", but the diagram in 13.2.2 shows an "element import". The revised text does not, but should, delete this drawing element as well.

    Further, under the Rationale subhead in 13.2.2, the first sentence

    reads: "Use of aliasing, though not common in MOF-based metamodels, keeps a strong alignment of the SBVR Metamodel with the SBVR vocabulary." Presumably, that will no longer be the case if the element imports are deleted.

    I suggest it should rather read:

    "In general, MOF does not provide a mechanism for declaring synonyms.

    Therefore, the Synonym elements of the SBVR vocabularies do not have counterparts in the SBVR MOF metamodel. They are, however, captured in SBVR vocabularies that are instances of the SBVR MOF metamodel."

  • Reported: SBVR 1.1 — Wed, 1 Feb 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Add the three overlooked editing instuctions to complete those in Issue 17017 resolution.

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

SBVR makes use of ElementImports to give additional aliases to some elements in the same package

  • Key: SBVR12-75
  • Legacy Issue Number: 17017
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SBVR makes use of ElementImports to give additional aliases to some elements in the same package. This is invalid use of ElementImport: the UML/MOF specs clearly state that ElementImports are only for elements “in another package”. I recently confirmed my understanding with the UML team that “another” does mean literally that (confirmed by OCL elsewhere in the spec) and it cannot be interpreted to mean “the same package”.

    Even were the ElementImport to be permitted, it would not have the intended meaning which I believe is to add additional synonyms to elements. In contrast the alias in an ElementImport “Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement.”

    This issue is urgent since it affects the production of correct normative artifacts for SBVR 1.1.

  • Reported: SBVR 1.1 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Drop the use of elementImport to include aliases in the SBVR Metamodel file as it is an invalid use of elementImport.

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

Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2)

  • Key: SBVR12-74
  • Legacy Issue Number: 16913
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 13.2.5 is based on a misunderstanding and misuse of MOF:

    a) the phrase “In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. “ is in ignorance of the fact that in MOF2 and UML 2 that “attributes” and “association ends” are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements.

    b) attempting to use MOF Tags to link two properties. In fact MOF Tags are “Simple string name-value pairs”.

    This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string.

  • Reported: SBVR 1.1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    1. Item a) in Issue statement:

    As per SBVR Clause 13, the class attribute element in the sameRole MOF Tag represents a different Property from the Property referenced by the association end element in the sameRole MOF Tag – not the same Property as asserted in the Issue statement. The semantics of using the two different properties is different in that one is used to identify a complete (closed-world) extension of a verb concept role with respect to a given subject, but the other is used to identify individual instances of the role with an open-world assumption.

    There is no change required for this part of the Issue statement.
    2. Item b) in Issue statement.

    The resolution to this part of the Issue statement is to drop the sameRole MOF Tags from the SBVR Metamodel file as they are an invalid use of MOF Tags.
    3. Paragraph 2 of the Issue Statement

    Dropping the sameRole MOF Tags from the SBVR Metamodel file resolves the points in this paragraph of the Issue statement.

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

Scope of an SBVR Body of Shared Concepts

  • Key: SBVR12-83
  • Legacy Issue Number: 17819
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    SBVR is intended for development of semantic models of businesses (and enterprises run on similar lines, such as public sector bodies and not-for-profit organizations). Its scope says “This specification defines the vocabulary and rules for documenting the semantics of business vocabularies, business facts, and business rules”.
    A lot of SBVR RTF email and teleconference discussion seems to be taken up with examples that are at best tenuously related to business, and often not at all related to business. There is, of course, no reason that people should not use SBVR as SVR – Semantics of Vocabulary and Rules – for any universe of discourse, whether business-related or not. But it is important to keep focus on what SBVR is intended for.
    Dependencies with other Issue Resolutions:
    None
    Discussion:
    There are two aspects of keeping SBVR’s focus on business:
    1. The context of an SBVR model of a business – a body of shared concepts, represented as one or more terminological dictionaries and rulebooks – is the actual world in which the business operates.
    2. The content of an SBVR model of a business is the meanings of the definitions of relevant things, relationships and guidance in the business.
    The universe of discourse is the part of the business selected by the business owners to be within scope. For example, in EU-Rent (as used in the SBVR specification) it is car rentals as opposed to finance, car purchasing and sales, premises management, HR, etc.
    This issue is about a matter of SBVR practice and can be addressed with notes (or perhaps in more general editorial).
    Resolution:
    Add notes under the entry for ‘body of shared meanings’:
    • To describe the universe of discourse modeled by the body of shared meanings
    • To emphasize that the body of shared meanings comprises only meanings

    Revised Text:
    In 11.1.1.2, under the entry for body of shared meanings, add the following notes:
    Note: When modelling a business (such as EU-Rent), the universe of discourse is bounded by what the business owners decide is in scope. That would be the actual world of some part of EU-Rent’s business (e.g. rentals, as opposed to, say, premises management, purchase/sales of cars, or HR) and some possible worlds that are reachable from the actual world. If the EU-Rent owners say that they are considering renting RVs or starting up in China, then possible worlds that include these kinds of business are in the universe of discourse.
    If EU-Rent is not considering renting construction equipment or camping gear, then possible worlds that include these kinds of business are not in the universe of discourse – and neither are possible worlds that include impossibilities. Whether ‘Kinnell Construction rented backhoe 123 on 2012-08-28’ or ‘John rode into work on a unicorn’ correspond to states of affairs or not, are not relevant to EU-Rent. They are out of scope.
    In-scope propositions may have to be constrained by necessities to ensure that they are not impossible. e.g. ‘Necessity: Each rental car is stored at at most one branch [at any given time].’
    Note: A body of shared meanings contains meanings of:
    • noun concepts that define kinds of thing in the universe of discourse
    • verb concepts that define relationships between kinds of thing in the universe of discourse
    • elements of guidance that constrain or govern the things and relationships defined by the concepts.
    It does not contain ground facts or facts derived from ground facts (other than as illustrative examples), or things in the universe of discourse, or information system artifacts that model things in the universe of discourse – although it may provide vocabulary to refer to them.

  • Reported: SBVR 1.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Add notes under the entry for ‘body of shared meanings’:
    • To describe the universe of discourse modeled by the body of shared meanings
    • To emphasize that the body of shared meanings comprises only meanings

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

Clause 10.1.2 Vocabulary Clarifications

  • Key: SBVR12-82
  • Legacy Issue Number: 17792
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    There are four small but inportant wording additions need to clarify three entries in the Clause 10.1.2:
    • In “possible world” and “universe of discourse” the word “object” has the signifier “thing” in sBVR
    • Make it clear that the “at some point in time” is the “present time of the possible word” as set forth in SBVr Clause 10.1.1.
    • The referents of “corresponding propositions or states of affairs” at the of the definition for ‘state of affairs’ is not clear.
    Resolution:
    Make the clarifications as identifed in Issue Summary.
    Revised Text:
    ADD in the second sentence in the Note in the entry for “possible world” in Clause 10.1.2 on printed page 117 after the phrase “any given set of objects”:

    [things]

    ADD to the end of the last sentence in the Note in the entry for “possible world” in Clause 10.1.2 on printed page 117:

    Thus, in the context of a static constraint declared for a given business domain, a “possible world” would correspond to (but not be identical to) a state of the domain’s fact model that could exist at some point in time.

    the following text:

    , which is the “present time” of the possible world.“

    ADD the word “respectively” at the end of the Definition in the entry for “state of affairs” in Clause 10.1.2 on printed page 119 after the phrase “set of objects”:

    ADD at the beginning of the Definition in the entry for “universe of discourse” in Clause 10.1.2 on printed page 120 after the phrase “set of objects”:

    [things]

  • Reported: SBVR 1.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Make the clarifications as identifed in Issue Summary

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

Align Definitions of Modal Entries in Clauses 8, 9 & 10

  • Key: SBVR12-81
  • Legacy Issue Number: 17599
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The definitions in most of the model entries in Clause 8.1.2 do not align with Clause 9 and Clause 10 modal definitions.
    Resolution:
    Align the definitions in Clause 8, 9 & 10 by changing the definitions in Clause 8; adding an intermediate concept to make the definition of “proposition is permitted to be true” intelligible to business people; and adding a definition for “actual world” to Clause 10.
    Revised Text:
    REPLACE the Definition in the entry for “proposition is necessarily true” in Clause 8.1.2 on printer page 26:

    Definition: the proposition always corresponds to an actuality

    WITH:

    Definition: the proposition corresponds to an actuality in all possible worlds

    REPLACE the Definition in the entry for “proposition is possibly true” in Clause 8.1.2 on printer page 26:

    Definition: it is possible that the proposition corresponds to an actuality

    WITH:

    Definition: the proposition corresponds to an actuality in some possible world

    Add a new Entry after the entry for “proposition is obligated to be true” in Clause 8.1.2 on printer page 26:

    proposition is obligated to be false
    Definition: the proposition does not correspond to an actuality in any acceptable world

    REPLACE the Definition in the entry for “proposition is permitted to be true” in Clause 8.1.2 on printer page 27:

    Definition: the proposition corresponds to an actuality in at least one acceptable world.

    WITH:

    Definition: the proposition is not obligated to be false

    REPLACE the Definition in the entry for “permissibility formulation” in Clause 9.2.4 on printer page 57:

    Definition: modal formulation that formulates that the meaning of its embedded logical formulation is true in some acceptable world

    WITH:

    Definition: modal formulation that formulates that the meaning of its embedded logical formulation is permitted to be true

    ADD immediately after the entry for “acceptable world” in Clause 10.1.2 on printed page 111 the following new entry:

    actual world
    Definition: the possible world that is taken to be actual for some purpose, in particular, for the conduct of business and the application of business rules
    Note: the actual world is a set of things, situations and facts about them that some person or organization takes to be true for some purpose. In most cases, it is the best estimate of the actual state of the world that is of interest at a particular time.

  • Reported: SBVR 1.1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Align the definitions in Clause 8, 9 & 10 by changing the definitions in Clause 8; adding an intermediate concept to make the definition of “proposition is permitted to be true” intelligible to business people; and adding a definition for “actual world” to Clause 10.

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

Eliminate Ambiguity from Two Interpretations for the Definition of Proposition

  • Key: SBVR12-80
  • Legacy Issue Number: 17544
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Source:
    Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
    Summary:
    In a recent SBVR RTF telecon it was discovered that that are two possible interpretations of the definition of ‘proposition’:
    meaning that has a logical structure involving concepts and that corresponds to a state of affairs and that is either true or false based on whether that state of affairs is actual or not
    The intended interpretation was that, to be a proposition, it must always in all possible worlds be able to be determined whether is it true or false, but that the assertion of that truth value is separate from the proposition, which SBVR defined to be a meaning.
    The second interpretation is that the truth value is part of the proposition.
    This ambiguity needs to be removed.
    Resolution:
    Clarify the entry for ‘proposition’ to remove the ambiguity. Part of the exisitng definition, “and that corresponds to a state of affairs”, is included as the entry, ‘proposition corresponds to a state of affairs, with its own definition in the resolution to Issue 10803.
    Revised Text:
    REPLACE the current definition of ‘proposition’ in Clause 8.1.2 on printed page 26:
    Definition: meaning that has a logical structure involving concepts and that corresponds to a state of affairs and that is either true or false based on whether that state of affairs is actual or not
    WITH:
    Definition: meaning of a declarative sentence that is not a paradoxical and that is invariant through all the paraphrases and translations of the sentence
    Note: A wff is a special case of statement in which there are no free occurrences of any variable, i.e. either it has constants in place of variables, or its variables are bound, or both

    ADD the following Source after the Definition in the entry for ‘proposition’ in Clause 8.1.2 on printed page 26:
    Source: [SubeGFOL]: proposition (2 & 3), Wff, Closed Wff

    ADD the following Necessity after the newly added Source in the entry for ‘proposition’ in Clause 8.1.2 on printed page 26:
    Necessity: It is necessary that each proposition that is created by quantifying all the verb concept roles of a given verb concept means what the definition of the verb concept defines it to mean.
    ADD the following Note after the last existing Note in the entry for ‘proposition’ in Clause 8.1.2 on printed page 26:
    Note: The truth-value of the proposition is separate from the proposition (i.e. the meaning of the statement). The proposition means the same thing regardless of the possible world that is referenced to determine the truth-value. Documenting the truth-value of a proposition is out of scope for SBVR and belongs to the domain of data management or rules enforcement.

  • Reported: SBVR 1.1 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Clarify the entry for ‘proposition’ to remove the ambiguity. Part of the exisitng definition, “and that corresponds to a state of affairs”, is included as the entry, ‘proposition corresponds to a state of affairs, with its own definition in the resolution to Issue 10803.

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

Correct ambiguities in signifiers and definitions of noun concepts

  • Key: SBVR12-79
  • Legacy Issue Number: 17527
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    There are two minor ambiguities in definitions of types of noun concept:
    1. ‘unitary concept’ is defined as ‘individual concept or general concept that always has at most one instance’ .
    This is ambiguous because it is not clear whether ‘that always has at most one instance’ applies to both ‘individual concept’ and ‘general concept’ or only to ‘general concept’.
    2. ‘individual concept’ is defined as ‘concept that corresponds to only one object [thing]’ (adopted from ISO 1087-1)
    This is ambiguous because it is not clear whether ‘only’ means ‘exactly one’ or ‘at most one’. The second note in the entry says “While each referring individual concept has at most one and the same instance …” suggesting that ‘only’ means ‘at most one’.
    Also, terms used for types of noun concept do not match their definitions. In SBVR, ‘concept’ includes both ‘noun concept’ and ‘verb concept’, but some terms use ‘concept’ for ‘noun concept’. For example, the definition for ‘general concept’ is for a specialization of ‘noun concept’.
    Discussion:
    The terms for types of noun concept became a concern after ‘fact type’ was replaced by ‘verb concept’ in Clause 8.
    Resolution:
    Update the definitions of ‘unitary concept’ and ‘individual concept’ to remove the ambiguities.
    Throughout the specification, replace the terms ‘general concept’, ‘unitary concept’ and ‘individual concept’ with, respectively, ‘general noun concept’, ‘unitary noun concept’ and ‘individual noun concept’
    Revised Text:
    On printed page 21 in Clause 8.1.1

    REPLACE
    unitary concept
    Definition: individual concept or general concept that always has at most one instance
    General Concept: noun concept

    WITH
    unitary noun concept
    Definition: general noun concept that always has at most one instance or individual noun concept

    On printed page 22 in Clause 8.1.1

    REPLACE
    individual concept FL
    Source: ISO 1087-1 (English) (3.2.2) [‘individual concept’]
    Definition: concept that corresponds to only one object [thing]
    General Concept: unitary concept
    Concept Type: concept type
    Necessity: No individual concept is a general concept.
    Necessity: No individual concept is a verb concept role.

    WITH
    individual noun concept FL
    Source: based on ISO 1087-1 (English) (3.2.2) [‘individual concept’]
    Definition: noun concept that corresponds to at most one thing
    General Concept: unitary noun concept
    Concept Type: concept type
    Necessity: No individual noun concept is a general noun concept.
    Necessity: No individual noun concept is a verb concept role.

    UPDATE NOUN CONCEPT TERMS:

    REPLACE the signifier “general concept” WITH “general noun concept”
    … list of replacement locations to be provided

    REPLACE the signifier “unitary concept” WITH “unitary noun concept” everywhere
    REPLACE the signifier “individual concept” WITH “individual noun concept” everywhere except for the “Source” subentry reference to ISO 1087-1 in the entry for the concept currently termed “individual concept’

    UPDATE DIAGRAMS:

    REPLACE the following diagrams WITH diagrams that replace the signifiers “general concept”, “unitary concept” and “individual concept” with, respectively, “general noun concept”, “unitary noun concept” and “individual noun concept”:

    • Figure 8.1
    • Figure 9.3
    • Figure 11.2
    • Diagram in Clause 13.4 on printed page 198

  • Reported: SBVR 1.1 — Fri, 20 Jul 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Add a synonym ‘general noun concept’ to ‘general concept’.
    Update the definitions of ‘unitary concept’ and ‘individual concept’ to remove the ambiguities.

    Throughout the specification, replace the terms ‘unitary concept’ and ‘individual concept’ with, respectively, ‘unitary noun concept’ and ‘individual noun concept’

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

Individual Verb Concept

  • Key: SBVR12-78
  • Legacy Issue Number: 17439
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Title: Fix the anomaly in the subcategory structure of ‘concept’ to include ‘individual verb concept’ in SBVR
    Source:
    RuleML Initiative, John Hall, (john.hall@modelsystems.co.uk)
    Summary:
    SBVR handles noun concepts and verb concepts asymmetrically:
    • ‘concept’ generalizes ‘noun concept’ and ‘verb concept’
    • ‘noun concept’ generalizes ‘general concept’ and ‘individual concept’ – i.e. ‘general concept’ means ‘general noun concept’ and ‘individual concept’ means ‘individual noun concept’
    There are no equivalents for ‘verb concept’. SBVR does not explicitly define ‘individual verb concept’, so cannot say:
    • ‘individual concept’ generalizes ‘individual noun concept’ and ‘individual verb concept’ (inheriting from: ‘concept’ generalizes ‘noun concept’ and ‘verb concept’)
    • ‘verb concept’ generalizes ‘general verb concept’ and ‘individual verb concept’ (paralleling: ‘noun concept’ generalizes ‘general noun concept’ and ‘individual noun concept’)
    If it did, this structural inconsistency would be removed.
    It would also be helpful in using SBVR. Individual noun concepts, such as “EU-Rent” and “Luxembourg”, are useful in defining bodies of shared meanings in SBVR. If SBVR included ‘individual verb concept’, an SBVR body of shared meanings could include individual verb concepts such as “EU-Rent is incorporated in Luxembourg”.
    Resolution:
    1. Change the preferred term that is currently ‘individual concept’ to ‘individual noun concept’ to clarify that it applies to noun concepts only
    2. Add the concept ‘individual verb concept’ for a proposition that is a Clause 8 verb concept with all its roles quantified (closed) by individual (noun) concepts to fix the anomaly in the subcategory structure of ‘concept’.

    Revised Text:
    On printed page 22 in Clause 8.1.1
    REPLACE the current term heading “individual concept” WITH “individual noun concept”

    And REPLACE “concept”, the first term in the definition, WITH “noun concept”

    On printed page 27 in Clause 8.1.2 at the end of the clause ADD this entry for ‘individual verb concept’:

    individual verb concept

    Definition: proposition that is based on exactly one verb concept in which each verb concept role is filled by an individual noun concept
    Note: … some explanatory comments
    Example: … some illustrative examples

    REPLACE the signifier “individual concept” WITH “individual noun concept” in the following places (but not in the “Source” subentry reference to ISO 1087-1 in entry for the concept current termed “individual concept’)

    • … to be identified and added

    REPLACE the following diagrams WITH diagrams that repolace the signifier “individual concept” with “individual noun concept”:

    • Figure 8.1
    • Figure 9.3
    • Figure 11.2

    … plus fixes for any additional side effects:

  • Reported: SBVR 1.1 — Fri, 29 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Add to Clause 8:
    • unitary verb concept: a general verb concept that has one instance (which can change over time) in its extension
    • individual verb concept: a proposition that is derived from a general verb concept by closing each of its roles with an individual noun concept, so that it has one instance (which cannot change over time) in its extension
    • general verb concept: to complete the segmentation of verb concept and distinguish this kind of verb concept from the other two.

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

Clarifications and Fixes for State of Affairs Related Entries

  • Key: SBVR12-86
  • Legacy Issue Number: 18317
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
    Summary:
    During recent in-depth SBVR RTF discussion on the topic of state of affairs a number of clarifications and fixes were identified as needed:
    1. Add a missing Reference Scheme for ‘state of affairs’.
    2. Add a Necessity to unambiguously distinguish states of sffairs from propostions.
    3. Add a Note to clarify how the representations of the meanings in the reference schemes of state of affairs serve as definite descriptions of the state of affairs.
    4. Clarify the relationship between 'is actual' and 'exists', and the relationship between actualities and potential states of affairs.
    Resolution:
    Makr the the fixes and add the clarifications as identified as being needed in the Issue Summary list above.
    Revised Text:

    ADD the following Reference Scheme, Necessity and Note to the “state of affairs” entry in Clause 8.5 on printed page 40:

    Reference Scheme: an individual noun concept that corresponds to the state of affairs
    Necessity: No state of affairs is a proposition.
    Note: Any representation of a proposition may be used to denote the state(s) of affairs that it corresponds to. A proposition statement serves as a definite description for the state of affairs that the proposition coressponds to.

    In the entry for “state of affairs is actual” in Clause 8.5 on printed page 40, REPLACE the Note and the Example:

    Note: The meaning of ‘is actual’should not be confused with ‘exists,’ meaning existential quantification. A state of affairs can exist and thereby be involved in relationships to other things (e.g., plans, desires, fears, expectations, and perceptions) even if it is not actual, even if it never happens.
    Example: “The EU-Rent London-Heathrow Branch wants to be profitable”. Even when that branch is unprofitable, the previous statement can correspond to an actuality that involves the state of affairs that the EU-Rent London-Heathrow Branch is profitable. The state of affairs exists as an object of desire and planning regardless of whether it is ever actual. The state of affairs is actual only when the branch is profitable, but it exists and is involved in an actuality (an instance of the verb concept ‘company wants state of affairs’) even when the branch is unprofitable.

    WITH:
    Note: The meaning of ‘is actual’should not be confused with logical existence, which just means being a thing in the possible world that is of interest. A potential state of affairs can 'exist' as a 'thing' in the possible world and thereby be involved in relationships to other things (e.g., plans, desires, fears, expectations, and perceptions) even if it is not actual, even if it never happens.
    Example: “The EU-Rent London-Heathrow Branch wants to be profitable”. Even when that branch is unprofitable, the previous statement can correspond to an actuality that involves the desired state of affairs that the EU-Rent London-Heathrow Branch is profitable. The desired state of affairs exists as an object of desire and planning regardless of whether there is ever an actual state of profitability. It exists and is involved in an actuality (an instance of the verb concept ‘company wants state of affairs’) even when the branch is unprofitable. The nature of the desired state of affairs is that it is a 'desired state of affairs' – conceived, not perceived.
    The actual state of affairs that the EU-Rent London-Heathrow Branch is profitable exists only when the branch is profitable. The nature of the actual state of affairs, if it exists, is that it is a happening in the world. It is perceived, not conceived.

    In the list of Necessities” in Clause 8.5.2 on printed page 41, REPLACE:

    Necessity: Each proposition corresponds to at most one state of affairs.

    WITH:

    Necessity: Each proposition corresponds to exactly one state of affairs.

  • Reported: SBVR 1.1 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Make the fixes and add the clarifications as identified as being needed in the Issue Summary list above

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

Add Generic Occurrence to SBVR to Support Other Specifications for Occurrence in Time, Space or Other Dimensions

  • Key: SBVR12-85
  • Legacy Issue Number: 18172
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    The DTV RTF has pointed out the value of adding to SBVR a very generic concept for all kinds of occurrences so that all specifications that define a particular kind of occurrence, e.g. occurrence in time, occurrence in space, can be consistent if they adopt and specialize the SBVR generic occurrence concept. This approach also provides the ability of specifications that deal with occurrence to constrain the generic concepts adopted from SBVR to fit their specification.
    Resolution:
    1. Incorporate that a state of affairs is not a meaning in its definition.
    2. Add a generic, overarching ‘occurrence’ noun concept.
    3. Add a “what happens” noun concept that is a role of ‘state of affairs’.
    4. Add a verb concept that defines the multiple relationship between “what happens’ and ‘occurrence’.
    5. Fix the definiiton of ‘state of affairs is actual’
    6. Clarify the Note for ‘actuality’.
    7. Remove confusing and unnecessary wording in the entry for ‘situation’.

    Revised Text:
    REPLACE Figure 8.8 in Clause 8.5 on printed page 40 WITH:

    In clause 8.5, in the entry for 'state of affairs', REPLACE the Definition:
    Definition: event, activity, situation, or circumstance
    with
    Definition: res that is an event, activity, situation, or circumstance
    In clause 8.5, immediately before the entry for 'state of affairs is actual', INSERT three new entries:
    occurrence
    Definition: state of affairs that is the happening of another state of affairs for a given time interval and/or at a given location and/or in some other dimension
    what-happens state of affairs
    Definition: state of affairs that can happen for a given time interval and/or at a given location and/or in some other dimension
    what-happens state of affairs has occurrence
    Definition: the occurrence is the realization of the state of affairs
    In clause 8.5, in the entry for 'state of affairs is actual', REPLACE the existing Definition:
    Definition: the state of affairs happens (i.e., takes place, obtains)
    with:
    Definition: the state of affairs is happening (i.e., takes place, obtains)

    In clause 8.5, in the entry for 'actuality', REPLACE the Note:
    Note: Actualities are states of affairs that actually happen, as distinct from states of affairs that don’t happen but nevertheless exist as subjects of discourse and can be imagined or planned.
    with:
    Note: Actualities are states of affairs that are actually happening, as distinct from states of affairs that are not happening but nevertheless exist as subjects of discourse and can be imagined or planned.

    In clause 11.1.5.2, in the entry for 'situation' on printed page 154, REMOVE
    • The phrase “that provides the context from which roles played may be understood or assessed” at the end of the Definition as it is about purpose and not essential meaning.
    • the words “a state of affairs” at the end of the first Dictionary Basis.

    ADD two noun concepts, ‘occurrence’ and ‘what-happens state of affairs’, to the following line in the paragraph beginning with “The classes in the metamodel that mirror …” in 13.2.2 “MOF Classes for SBVR Noun Concepts”:

    Clause 8: meaning, concept, expression, state of affairs, actuality, thing, set

    ADD two noun concepts, ‘property’ and ‘viewpoint’, to the following line in the paragraph beginning with “The classes in the metamodel that mirror …” in 13.2.2 “MOF Classes for SBVR Noun Concepts”:

    Clause 11: community, situation, res

  • Reported: SBVR 1.1 — Mon, 15 Oct 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    After lengthy and diligent RTF discussion, it turned out not to be possible to reach consensus on the definition of ‘occurrence’. The concerns on which consensus could not be reached were primarily:
    • Limiting ‘occurrences’ to only those that have actually happened, If this were done, it would remove the ability of SBVR to support talking about occurrences that have yet to happen.
    • Including instances in the universe of discourse (the real things in the universe of the business) in SBVR Business Vocabularies. These are not meanings and are therefore out of scope for SBVR.
    As a result, this resolution requires no changes.

    Revised Text:
    None

    Disposition: No Change

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

individual verb concept’ in SBVR

  • Key: SBVR12-84
  • Legacy Issue Number: 18166
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Title: Fix the anomaly in the subcategory structure of ‘concept’ to include ‘individual verb concept’ in SBVR
    Source:
    RuleML Initiative, John Hall, (john.hall@modelsystems.co.uk)
    Summary:
    SBVR handles noun concepts and verb concepts asymmetrically:
    • ‘concept’ generalizes ‘noun concept’ and ‘verb concept’
    • ‘noun concept’ generalizes ‘general concept’ and ‘individual concept’ – i.e. ‘general concept’ means ‘general noun concept’ and ‘individual concept’ means ‘individual noun concept’
    There are no equivalents for ‘verb concept’. SBVR does not explicitly define ‘individual verb concept’, so cannot say:
    • ‘individual concept’ generalizes ‘individual noun concept’ and ‘individual verb concept’ (inheriting from: ‘concept’ generalizes ‘noun concept’ and ‘verb concept’)
    • ‘verb concept’ generalizes ‘general verb concept’ and ‘individual verb concept’ (paralleling: ‘noun concept’ generalizes ‘general noun concept’ and ‘individual noun concept’)
    If it did, this structural inconsistency would be removed.
    It would also be helpful in using SBVR. Individual noun concepts, such as “EU-Rent” and “Luxembourg”, are useful in defining bodies of shared meanings in SBVR. If SBVR included ‘individual verb concept’, an SBVR body of shared meanings could include individual verb concepts such as “EU-Rent is incorporated in Luxembourg”.
    Resolution:
    1. Change the preferred term that is currently ‘individual concept’ to ‘individual noun concept’ to clarify that it applies to noun concepts only
    2. Add the concept ‘individual verb concept’ for a proposition that is a Clause 8 verb concept with all its roles quantified (closed) by individual (noun) concepts to fix the anomaly in the subcategory structure of ‘concept’.

    Revised Text:
    On printed page 22 in Clause 8.1.1
    REPLACE the current term heading “individual concept” WITH “individual noun concept”

    And REPLACE “concept”, the first term in the definition, WITH “noun concept”

    On printed page 27 in Clause 8.1.2 at the end of the clause ADD this entry for ‘individual verb concept’:

    individual verb concept

    Definition: Definition to be replaced
    proposition that is based on exactly one verb concept in which each verb concept role is filled by an individual noun concept
    … some explanatory comments
    Example: … some illustrative examples

    REPLACE the signifier “individual concept” WITH “individual noun concept” in the following places (but not in the “Source” subentry reference to ISO 1087-1 in entry for the concept current termed “individual concept’)

    • … to be identified and added

    REPLACE the following diagrams WITH diagrams that repolace the signifier “individual concept” with “individual noun concept”:

    • Figure 8.1
    • Figure 9.3
    • Figure 11.2

    … plus fixes for any additional side effects

  • Reported: SBVR 1.1 — Thu, 21 Jun 2012 04:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    Merger with Issue 17439.
    Revised Text:
    None.
    Disposition: Merged

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

The SBVR document is far larger than optimal. It needs to be reduced in size

  • Key: SBVR12-87
  • Legacy Issue Number: 18367
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    The SBVR document is far larger than optimal. It needs to be reduced in size. Many of the Annexes do not contribute directly to core content.

    Resolution

    Delete Annexes that are not essential to the SBVR specification. Evaluation of the Annexes:

    Annexes essential to the correct interpretation of the normative specification and that must be kept:
    Annex C - SBVR Structured English
    Annex E - EU-Rent Example
    Annex H - Use of UML Notation in a Business Context to Represent SBVR-Style Vocabularies
    Annex M - Additional References
    Annexes that are not essential and can be deleted. Their owners can choose whether to publish them independently:
    Annex F - The RuleSpeak® Business Rule Notation*
    Annex G - Concept Diagram Graphic Notation
    Annex I - The ORM Notation for Verbalizing Facts and Business Rules*
    Annex J - ORM Examples Related to the Logical Foundations for SBVR
    Annex L - A Conceptual Overview of SBVR and the NIAM2007 Procedure to Specify a Conceptual Schema
    The SBVR RTF should decide on a case by case basis whether the following Annexes are essential to the correct interpretation of the normative clauses or can be deleted:
    Annex A - Overview of the Approach
    Annex B - The Business Rules Approach
    Annex D - SBVR Structured English Patterns
    Annex K - Mappings and Relationships to Other Initiatives
    *To be discussed by the RTF: Since (a) SBVR-SE is not normative, and (b) RuleSpeak and ORM (Norma) served as reference notations in creating the specification, it might be useful to illustrate parts or all of Annexes C and/or E, and/or examples given in the specification itself, in these other two notations. Annexes F and I already did something like this, but (a) are much too large, (b) not well-focused on complementing SBVR, and (c) may need to be revised.

  • Reported: SBVR 1.1 — Wed, 9 Jan 2013 05:00 GMT
  • Disposition: Resolved — SBVR 1.2
  • Disposition Summary:

    No Data Available

  • 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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

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

Fact-types and templates (and subscripts)

  • Key: SBVR-16
  • Legacy Issue Number: 9257
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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

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