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

Semantics Of Business Vocabulary And Business Rules — Closed Issues

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

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-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-26 ANNEX G COLOR-CODED CONCEPT NOT DECLARED SBVR 1.2 SBVR 1.5 Closed; No Change closed
SBVR15-96 SBVR Issue - Stand-Alone 'Must' in a Necessity SBVR 1.2 SBVR 1.5 Closed; No Change 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-83 Definition of Practicable re Concepts SBVR 1.2 SBVR 1.5 Resolved closed
SBVR15-25 'categorization scheme' and 'categorization type' are related SBVR 1.2 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-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-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-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-11 ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-13 omission of the word 'if' SBVR 1.2 SBVR 1.4b2 Deferred closed
SBVR14-22 ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS SBVR 1.2 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-62 Formalize the 'quantity' entry SBVR 1.2 SBVR 1.4b2 Deferred 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:

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:

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:

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:

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:

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:

'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

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: 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

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

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

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

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

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

'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

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