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

Semantics Of Business Vocabulary And Business Rules — Open Issues

  • Acronym: SBVR
  • Issues Count: 9
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Not all closed logical formulations formulate propositions

  • Key: SBVR16-58
  • Legacy Issue Number: 19822
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

Use of SBVR markup in specifications

  • Key: SBVR16-57
  • Legacy Issue Number: 19828
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR v1.3


    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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

SBVR Issue: 'denotes' is too narrowly defined

  • Key: SBVR16-56
  • Legacy Issue Number: 19883
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

SBVR Issue: Definitions should be tagged by language

  • Key: SBVR16-55
  • Legacy Issue Number: 19829
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification SBVR v1.3


    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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

SBVR Issue: Erroneous normative requirements for SBVR XML

  • Key: SBVR16-54
  • Legacy Issue Number: 19830
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

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

  • Key: SBVR16-53
  • Legacy Issue Number: 19807
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: SBVR v1.3

    Title: 'partitive verb concept' is ill-defined


    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


    Phone: +1 240-672-5800

  • Reported: SBVR 1.2 — Mon, 15 Jun 2015 04:00 GMT
  • Updated: Tue, 9 Jul 2019 14:49 GMT

SBVR issue - "behavioral business rule" vs. "behavioral

  • Key: SBVR16-52
  • Legacy Issue Number: 19891
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

Formalize the 'quantity' entry

  • Key: SBVR16-36
  • Legacy Issue Number: 19332
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT

'categorization scheme' and 'categorization type' are related

  • Key: SBVR16-16
  • Legacy Issue Number: 19549
  • Status: open  
  • 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, 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
  • Updated: Tue, 9 Jul 2019 14:49 GMT