Semantics Of Business Vocabulary And Rules Avatar
  1. OMG Specification

Semantics Of Business Vocabulary And Rules — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
SBVR15-77 SBVR Metamodel Fixes Related to a Formal Logics Interpretation SBVR 1.0b1 open
SBVR15-68 Distinguishing between Representation Expressions With and Without Embedded Markup SBVR 1.0 open
SBVR15-76 The Notion of “Involvement” has not been Adequately Specified with in SBVR SBVR 1.0b2 open
SBVR15-75 Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre SBVR 1.0b2 open
SBVR15-74 Additional Improvements to Clause 10 SBVR 1.0b2 open
SBVR15-67 Clean up and Complete Vocabulary for Clause 10.1.1 SBVR 1.0 open
SBVR15-65 SBVR issue - Need verb concept to support "local closure" SBVR 1.0 open
SBVR15-64 Inconsistent use of terminology when relating facts to fact types SBVR 1.0 open
SBVR15-62 Keyword "another" SBVR 1.0 open
SBVR15-56 Existential and Elementary SBVR 1.0 open
SBVR15-52 No relationship defined between clause 8 concepts and clause 11 concepts SBVR 1.0 open
SBVR15-51 Clause 8 does not include the concepts needed to represent itself SBVR 1.0 open
SBVR15-50 The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete SBVR 1.0 open
SBVR15-45 Move 'rulebook' to Clause 12 SBVR 1.0 open
SBVR15-44 Error message from XML Schema validator when trying a SVBR XSD SBVR 1.0 open
SBVR15-36 Precedence of operators SBVR 1.0 open
SBVR15-42 SBVR ISSUE - definite description SBVR 1.0 open
SBVR15-33 Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition SBVR 1.0 open
SBVR15-27 Issue "fact type role is in fact type" SBVR 1.0 open
SBVR15-18 'reality' and 'in-practice' models SBVR 1.0 open
SBVR15-17 Revise Modeling of Fact Model and Conceptual Schema SBVR 1.0 open
SBVR15-3 SBVR issue: Can there be multiple instances of a thing? SBVR 1.0 open

Issues Descriptions

SBVR Metamodel Fixes Related to a Formal Logics Interpretation

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

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

    a. A reference scheme is needed for individual concept.

    b. The entries in Clause 8.5 “Conceptual Schemas and Models” need to be corrected to agree with the first paragraphs of Clause 10.

    c. In Clause 8.6 “Extensions” and other sections of Clauses 8-12 the definition of “corresponds to” in “meaning corresponds to thing” and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of “proposition corresponds to state of affairs” and “ individual concept corresponds to thing” need to be clarified or added. How the relationship between concept and thing is different between the “use” and the “mention” of the concept needs to be made clear.

    d. Thee reference scheme for individual concept needs to be fixed to include the “mention” of object types, roles, fact types, propositions and subcategories of them.

    e. Definitions that cover all the uses of “individual” in Clauses 8-12 need to be added.

    f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.

  • Reported: SBVR 1.0b1 — Thu, 23 Aug 2007 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Distinguishing between Representation Expressions With and Without Embedded Markup

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

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

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

  • Reported: SBVR 1.0 — Fri, 6 May 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

    Issue Submitter’s Name: Donald Chapin

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

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

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

    Document No: dtc/06/03/01

    Document Revision Date: March 2006

    Document Version No: —

    Chapter/Section: 8.1.1

    Page No(s): 16

    Nature of Issue: Revision

    Severity of Issue: Major

    Issue Description:

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

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

  • Reported: SBVR 1.0b2 — Tue, 21 Aug 2007 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

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

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

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

    • the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force
  • Reported: SBVR 1.0b2 — Thu, 30 Aug 2007 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Additional Improvements to Clause 10

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

    Issue Description:

    1. Spin-off Issue for items not resolved In Issue 9959 because of lack of time:

    a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed

    b. Remove tutorial material from Clause 10.1.1

    c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO

  • Reported: SBVR 1.0b2 — Tue, 21 Aug 2007 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Clean up and Complete Vocabulary for Clause 10.1.1

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

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

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

    • the proposed resolution of this spin-off Issue which will be posted when it has a number;
    • the proposed resolution to Issue 12540; and
    • the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number.
  • Reported: SBVR 1.0 — Thu, 4 Dec 2008 05:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

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

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

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

    Example use cases for local closure include the following:

    Example 1

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

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

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

    Example 2

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

    employee
    Definition: person that works for the business

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

    Example 3

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

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

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

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

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

    Resolution:
    Revised Text:
    Disposition:

  • Reported: SBVR 1.0 — Mon, 17 Oct 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Inconsistent use of terminology when relating facts to fact types

  • Key: SBVR15-64
  • Legacy Issue Number: 15124
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Inconsistent use of terminology when relating facts to fact types

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

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

    Recommended changes:

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

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

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

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

    With this:

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

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

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

    REPLACE it with this:

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

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

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

    REPLACE it with this:

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

  • Reported: SBVR 1.0 — Tue, 9 Mar 2010 05:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Keyword "another"

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

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

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

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Existential and Elementary

  • Key: SBVR15-56
  • Legacy Issue Number: 15157
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

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

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

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

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

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

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

    Is it existential? I cannot see it that way.

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

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

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

    Employee number 777 is assigned.

    There exists an employee that has the employee number 777.

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

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

    Recommendation:

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

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

  • Reported: SBVR 1.0 — Fri, 2 Apr 2010 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

No relationship defined between clause 8 concepts and clause 11 concepts

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

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

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

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Clause 8 does not include the concepts needed to represent itself

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

    SBVR currently has multiple concepts for organizing vocabularies and rules:

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

    Some issues:

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

  • Reported: SBVR 1.0 — Fri, 20 Jun 2008 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

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

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

  • Reported: SBVR 1.0 — Wed, 19 Oct 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Move 'rulebook' to Clause 12

  • Key: SBVR15-45
  • Legacy Issue Number: 16062
  • Status: open  
  • Source: Business Rule Solutions, LLC ( Keri Healy)
  • Summary:

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

    Resolution: Move 'rulebook' to Clause 12.

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

  • Reported: SBVR 1.0 — Fri, 18 Mar 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Error message from XML Schema validator when trying a SVBR XSD

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

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

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

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

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

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

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

    Any ideas?

  • Reported: SBVR 1.0 — Thu, 11 Apr 2013 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Precedence of operators

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

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

  • Reported: SBVR 1.0 — Sat, 17 Mar 2012 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

SBVR ISSUE - definite description

  • Key: SBVR15-42
  • Legacy Issue Number: 16527
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Definite descriptions do not always define individual concepts

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

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

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

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

  • Reported: SBVR 1.0 — Tue, 6 Sep 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

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

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

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

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

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

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

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

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

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

  • Reported: SBVR 1.0 — Wed, 24 Jun 2009 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Issue "fact type role is in fact type"

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

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

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

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

  • Reported: SBVR 1.0 — Mon, 12 May 2008 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

'reality' and 'in-practice' models

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

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

  • Reported: SBVR 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

Revise Modeling of Fact Model and Conceptual Schema

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

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

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

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

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

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

    conceptual schema

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

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

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

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

    fact model1 includes fact model2

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

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

    fact model includes description

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

    thing has URI

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

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

  • Reported: SBVR 1.0 — Wed, 10 Dec 2008 05:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT

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

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

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

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

  • Reported: SBVR 1.0 — Mon, 6 Jun 2011 04:00 GMT
  • Updated: Tue, 3 Jan 2017 13:19 GMT