Semantics Of Business Vocabulary And Rules Avatar
  1. OMG Specification

Semantics Of Business Vocabulary And Rules — Open Issues

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

Issues Descriptions

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

  • Key: SBVR15-96
  • Legacy Issue Number: 19884
  • Status: open  
  • Source: Business Rule Solutions, LLC ( 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
  • Updated: Tue, 31 Jan 2017 12:01 GMT

Not all closed logical formulations formulate propositions

  • Key: SBVR15-95
  • Legacy Issue Number: 19822
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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, 31 Jan 2017 12:01 GMT

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

  • Key: SBVR15-90
  • Legacy Issue Number: 19807
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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
  • Updated: Tue, 31 Jan 2017 12:01 GMT

SBVR Issue: Erroneous normative requirements for SBVR XML

  • Key: SBVR15-91
  • Legacy Issue Number: 19830
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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, 31 Jan 2017 12:01 GMT

SBVR Issue: Definitions should be tagged by language

  • Key: SBVR15-92
  • Legacy Issue Number: 19829
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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
  • Updated: Tue, 31 Jan 2017 12:01 GMT

Use of SBVR markup in specifications

  • Key: SBVR15-94
  • Legacy Issue Number: 19828
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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
  • Updated: Tue, 31 Jan 2017 12:01 GMT

Problems with denotation

  • Key: SBVR15-89
  • Legacy Issue Number: 19837
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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
  • Updated: Tue, 31 Jan 2017 12:01 GMT

SBVR Issue: 'denotes' is too narrowly defined

  • Key: SBVR15-93
  • Legacy Issue Number: 19883
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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, 31 Jan 2017 12:01 GMT

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

  • Key: SBVR15-88
  • Legacy Issue Number: 19891
  • Status: open  
  • Source: Business Rule Solutions, LLC ( 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, 31 Jan 2017 11:37 GMT

Add 2 Statement Examples

  • Key: SBVR15-85
  • Legacy Issue Number: 19893
  • Status: open  
  • Source: Business Rule Solutions, LLC ( Keri 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
  • Updated: Tue, 3 Jan 2017 21:30 GMT

Add Example for Definitional Rule

  • Key: SBVR15-84
  • Legacy Issue Number: 19895
  • Status: open  
  • Source: NIST ( Ron Ross)
  • 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
  • Updated: Tue, 3 Jan 2017 21:29 GMT

Definition of Practicable re Concepts

  • Key: SBVR15-83
  • Legacy Issue Number: 19896
  • Status: open  
  • Source: NIST ( Ron Ross)
  • 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
  • Updated: Tue, 3 Jan 2017 21:29 GMT

Formalize the 'quantity' entry

  • Key: SBVR15-60
  • 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, 3 Jan 2017 13:19 GMT

ANNEX G COLOR-CODED CONCEPT NOT DECLARED

  • Key: SBVR15-26
  • Legacy Issue Number: 19520
  • Status: open  
  • 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
  • Updated: Tue, 3 Jan 2017 13:19 GMT

'categorization scheme' and 'categorization type' are related

  • Key: SBVR15-25
  • 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 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
  • Updated: Tue, 3 Jan 2017 13:19 GMT

ANNEX B BAD REFERENCES TO DIAGRAMMING CONVENTIONS

  • Key: SBVR15-20
  • Legacy Issue Number: 19518
  • Status: open  
  • 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
  • Updated: Tue, 3 Jan 2017 13:19 GMT

ROLE: RANGES OVER VS. SPECIALIZES, GENERALIZES

  • Key: SBVR15-11
  • Legacy Issue Number: 19519
  • Status: open  
  • 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
  • Updated: Tue, 3 Jan 2017 13:19 GMT

omission of the word 'if'

  • Key: SBVR15-12
  • Legacy Issue Number: 19671
  • Status: open  
  • 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
  • Updated: Tue, 3 Jan 2017 13:19 GMT