Issues for Mailing list of the Semantics of Business Vocabulary & Business Rules Finalization Task Force

To comment on any of these issues, send email to sbvr-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 9226: Making Annex A Normative
Issue 9227: Location of and Notation for Formal Logic Grounding Examples
Issue 9228: Making Annex A Normative -- No Connection with SBVR Definitions
Issue 9257: Fact-types and templates (and subscripts)
Issue 9258: Logical formulations are fact-types
Issue 9344: define 'is less than' on 'quantity'
Issue 9366: description of the type theory of SBVR needs to be included in 10.1.1
Issue 9368: Issue: Improve linkage to Rule/Business Rule in 10.1.1 Narrative
Issue 9399: Section: Section F.2.1.2 (RuleSpeak Annex)
Issue 9444: Chapter 12 page 139: Add Synonyms
Issue 9446: Add 'Synonym: aspect' caption
Issue 9447: Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept
Issue 9448: Add (and explain) styling for 90 days where it appears in formal statement
Issue 9449: SBVR-FTF Issue: 10 Example Rules material
Issue 9450: 10 Examples - applying a standard pattern in the "10 Examples"
Issue 9451: Individual Concept Not Necessarily a Noun Concept
Issue 9452: Reference Scheme’s Reference Scheme is Incomplete
Issue 9453: Unnecessary Grammatical Structure
Issue 9454: Tie Category and More General Concept to a Fact Type
Issue 9455: Fact Type Templating Diagram Error
Issue 9456: Symbolization Diagram Error
Issue 9457: XMI Names for ESBVR
Issue 9458: Bad Example of Extensional Definition
Issue 9459: Synonymous Statement
Issue 9462: Use Plural Rather than “Set of Each”
Issue 9467: Implicit Passive Forms
Issue 9468: XML Schema and Namespace URIs
Issue 9470: specification does not address the mapping of rules to MOF and XMI
Issue 9471: supporting documents
Issue 9472: XMI in bei/05-08-02 and representing many vocabulary and rules aspects
Issue 9473: XMI has some internal inconsistencies
Issue 9474: SBVR vocabularies
Issue 9475: missing definitions
Issue 9476: Interchange issue
Issue 9579: "Logic Rule" issue
Issue 9580: Page: 296
Issue 9586: Binding to Individual Concepts
Issue 9607: Body of Shared Meanings
Issue 9608: Clarification Remnants
Issue 9609: A fact is not a logical formulation
Issue 9613: Chapters 8,9,11,12
Issue 9614: dictionary basis
Issue 9621: Annex E/EU-Rent vocabulary's 'characteristic' entries
Issue 9623: Mapping SBVR logical formulation terms to formal logic terms
Issue 9707: What is the "business vocabulary" in 10.3
Issue 9708: business jurisdiction
Issue 9709: SBVR Issue - Circular definition of logical operator and logical operand
Issue 9711: Definition of Body of Shared Guidance
Issue 9712: Definitions of 'projection'
Issue 9713: Projection position and reference scheme for variables
Issue 9714: Use of 'modality' in 8.1.2
Issue 9715: Definition of 'proposition'
Issue 9721: SBVR Issue - wrong proposition in 8.1.2 and modal formulation
Issue 9723: Quantification definitions
Issue 9724: quantifications based on cardinality
Issue 9725: Meaning of objectification is unclear
Issue 9726: What is a projecting formulation?
Issue 9727: What is an aggregation formulation?
Issue 9728: Meaning of noun concept formulation
Issue 9729: True/False meaning of logical formulations must be specified
Issue 9730: bindable target should be 'constant' not 'text'
Issue 9731: Meaning of fact-type formulation and fact type projection
Issue 9732: Correct glossary entry for proposition nominalization
Issue 9733: Complete support for question nominalization
Issue 9734: Correct specification of question and answer nominalization
Issue 9753: wrong proposition in 8.1.2 and modal formulation
Issue 9832: Thing’ Defined Tentatively
Issue 9835: SBVR Issue: What is concept1?
Issue 9874: Annex E - editorial issues
Issue 9882: Define ‘true’ and ‘false’
Issue 9929: Note and Example for “text is for placeholder”
Issue 9930: Section 1 - modeling based on MOF does not have all of the capabilities
Issue 9931: SBVR Issue - 'meaning has representation'
Issue 9932: SBVR Issue - Is a representation an actuality?
Issue 9934: SBVR Issue - Concept Expression versus Meaning Expression
Issue 9935: SBVR Issue - Bug in Namespaces Diagram
Issue 9938: SBVR Issue - 'role has role binding'
Issue 9939: ‘vocabulary has URI’
Issue 9940: SBVR Issue - Logical Formulation Kinds of Quantifications
Issue 9941: Section: 8.3, + 11.2
Issue 9942: Section: 8
Issue 9944: Section: 11.2.1.3
Issue 9945: “Admonition” and “Affirmation” are the same concept
Issue 9947: SBVR Issue - Projection Diagram - Variable Maps to Role
Issue 9948: Section 2.2.1.1.1 Fac Type: "concept1 specializes concept2"
Issue 9949: Section: F.2.2
Issue 9950: Section: Annex C
Issue 9952: Section: 8.3.5, 11.1.1, 11.2.1
Issue 9953: Section: 8.1.1
Issue 9955: Section: 11.1.1 page 112
Issue 9956: Section: 11.1.1 pages 110 - 113
Issue 9957: Section: Clause 2
Issue 9958: Section: 8.3.4
Issue 9959: Section: Clause 10 pages 71 - 108
Issue 9960: Association Names in UML Diagrams
Issue 10099: use of 'designation', definition of 'term'
Issue 10377: clarification needed for 'reference scheme uses characteristic'
Issue 10422: H.4.3 (Term for a Role in a Form of Expression), page 323-324
Issue 10423: Clean Up based on resolution of issue 9467, 9258, 9934, 9882
Issue 10442: Examples in the normative part of spec should use SBVR Structured English
Issue 10443: SBVR Issue - Annex C.1.1.3 "only if"
Issue 10444: Error in sentence on double negation
Issue 10470: Section: 10 & 12 Section: 9, 16, C
Issue 10504: SBVR Issue on Authorizations / Dark World Assumptions
Issue 10505: Universal AND
Issue 10506: Exceptions
Issue 10508: Authorizations & Support for "Dark World" Assumptions Section: 17.4.2
Issue 10523: Logical Formulation of Restricted Permission and Possibility Statements
Issue 10525: SBVR Issue -- Relationship between "Business Policy" and "Advice"
Issue 10562: Under-the-Covers SBVR Support for ‘Dark’ Rules
Issue 10563: Scope of Rules & Advices – Body of Shared Guidance Section: 8.7.2
Issue 10567: Relating Vocabularies to Namespaces
Issue 10568: Number Namespace
Issue 10569: Simple Fixes - editorial issues
Issue 10570: ‘expression’ as a bindable target
Issue 10571: "'Concept' incorporates 'characteristic'" is ambiguous
Issue 10572: SBVR Does Not Adopt ISO 1087 "Essential Charactertic" Fully and Correctly
Issue 10573: Section: 8.1.1
Issue 10574: Section: 8.1.1 (02)
Issue 10575: Major Disconnect Between Structural Rule and a Concept's Characteristics
Issue 10578: Section: 11.1.1.1
Issue 10580: Section: 12.1.1
Issue 10596: SBVR Issue - Restrictions on Variables
Issue 10620: Section: 12.1.2 & 12.2.1 Definition of 'question'
Issue 10622: Closed logical formulation formalizes statement
Issue 10629: URI is not a role
Issue 10632: definition of 'prohibited symbol'
Issue 10633: The unary fact type/characteristic "category is inactive"
Issue 10779: SBVR Issue - "is" vs. "equals"
Issue 10790: No Way to Specify What the Instance of an Individual Concept Is
Issue 10798: Two SBVR Normative Definitions Use Deontic Logic in Error
Issue 10800: Vocabulary should be mandatory
Issue 10801: Definition of 'fact type'
Issue 11153: "Definition of Category"
Issue 11263: NIAM Annex
Issue 11264: Sjir Nijssen Revisions to Clause 10
Issue 11283: SBVR Issue: OMG URLs
Issue 11288: Section 9.2.5
Issue 11289: Section 9.3 editorial
Issue 11290: In 8.7 in the definition of “cardinality”, remove the word “distinct”
Issue 11291: SBVR Annex E minor corrections
Issue 11292: 1. swap the sequence of two entries
Issue 11293: Correct styling in characteristic
Issue 11294: Correct the leading term of definition
Issue 11295: One global change too far
Issue 11297: corrected Figure 11.2
Issue 11298: Corrected Fig. 11.6
Issue 11299: Unnecessary Necessities
Issue 11300: Mysteries & miscellany The Notion of “Involvement” has not been Adequately Specified with in SBVR

Issue 9226: Making Annex A Normative (sbvr-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew@omg.org)
Nature: Revision
Severity: Critical
Summary:

AB SBVR ISSUE: Making Annex A Normative -- Incorporation into Clause 10 with ORM Tutorial Material Remaining in Annex All ORM tutorial material that does not not assert the formal logic grounding needs to be separated out and remain in the Annex and the formal logic grounding material moved to become Clause 10.1 in the normative section of the bei/05-08-01 (or whereever that section ends up in the FAS). Formal logic grounding examples need to be clearly labelled as such independent of the notation used to express them. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would be preferable.)

Resolution: see above
Revised Text: Replace Annex J in the SBVR Final Adopted Specification with the contents of file dtc/2006-09-02 Insert the contents of file dtc/2006-09-01 into Clause 10.1.1 of the SBVR Final Adopted Specification.
Actions taken:
December 19, 2005: received issue
April 25, 2006: closed issue

Discussion:

All ORM notation and verbalization examples for the formal logic grounding of SBVR are to remain in the informative Annex J as per file dtc/2006-09-02.
The statement of the formal logic grounding of SBVR that was in the informative Annex J is moved to the normative Clause 10.1.1 with revisions and new ORM-neutral examples as agreed and documented in file dtc/2006-09-01.

Issue 9227: Location of and Notation for Formal Logic Grounding Examples (sbvr-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew@omg.org)
Nature: Revision
Severity: Critical
Summary:

AB SBVR ISSUE: Making Annex A Normative -- Location of and Notation for Formal Logic Grounding Examples Including a SBVR Structured English version of the formal logic grounding examples in the formal logic grounding content may be desirable: either in addition to the ORM examples, or in place of them. A decision is required regarding the location of the formal grounding examples: either embedded in the formal logic grounding text where they are referenced, or separated out into an different Annex. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would otherwise be preferable.)

All ORM notation and verbalization examples for the formal logic grounding of SBVR are to remain in the informative Annex J as per file dtc/2006-09-02.
The statement of the formal logic grounding of SBVR that was in the informative Annex J is moved to the normative Clause 10.1.1 with revisions and new ORM-neutral examples as agreed and documented in file dtc/2006-09-01.

Issue 9228: Making Annex A Normative -- No Connection with SBVR Definitions (sbvr-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew@omg.org)
Nature: Revision
Severity: Critical
Summary:

AB SBVR ISSUE: Making Annex A Normative -- No Connection with SBVR Definitions There is nothing in Annex A that ties the formal logic grounding into normative SBVR concepts. A chart is needed cross-referencing current ORM concepts with SBVR concepts. If the FTF decides to require Annex A examples to be expressed in SBVR Structured English (see separate issue), a translation of the examples from ORM notation to SBVR Structured English is required. (This issue was raised as result of the AB review of the submission on Monday 12th September, and AB recommendation for adoption was made conditonal on its application. It is therefore being filed early, against the Submission, rather than waiting for the Final Adopted Specification, as would otherwise be preferable.)

All ORM notation and verbalization examples for the formal logic grounding of SBVR are to remain in the informative Annex J as per file dtc/2006-09-02.
The statement of the formal logic grounding of SBVR that was in the informative Annex J is moved to the normative Clause 10.1.1 with revisions and new ORM-neutral examples as agreed and documented in file dtc/2006-09-01.

Issue 9257: Fact-types and templates (and subscripts) (sbvr-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark@nist.gov edward.barkmeyer@nist.gov)
Nature: Clarification
Severity: Significant
Summary:

In SBVR clause 8, subscripts occur in fact-type term entries. In clause 14, those subscripts are omitted from the fact-type term entries. This is inconsistent, apparently because the entries in clause 8 are doing double duty: as fact-type definitions and as SBVR Structured English templates.

Subscripts occurring in fact-type definitions (Glossary Fact Type entries) are not part of the entry for the fact-type. They are an accidental part of definition of the template for the corresponding form-of-expression.
A fact type is an abstract concept, and the glossary item apparently defines both the fact-type and a form-of-expression for the fact-type. That form of expression belongs to "SBVR Structured English", and there may well be other forms of expression for the selfsame fact-type in other languages. So the specification has to make this distinction *very* clear.
But the subscripts are not in fact a part of that form of expression, either. They are not keywords in the template itself. They are rather a lexical mechanism used to distinguish two *roles* in the template (and in the fact type) that happen to require the same underlying concept type. That is, in "concept#1 specializes concept#2"
SBVR defines the fact-type
"concept specializes concept",
and at the same time, defines the fact-type *template*:
"concept#1 specializes concept#2"
where "concept#1" designates a "concept" and "concept#2" designates a "concept". That is, "concept#1" is just a template parameter that lexically represents one role in the fact-type "concept specializes concept". For the template, "concept#1" could just as well have been called "parameter#1" or "x". "concept#1" is neither a "term" nor a "keyword"; it is a template parameter -- a lexical stand-in that is to be uniformly replaced by one actual "term" or "name" in all uses of the template and in all occurrences in the corresponding definition. The current notation makes this confusing.
Note that this situation is not really different from "concept incorporates characteristic". The fact-type is "concept incorporates characteristic" and the template is "concept#1 incorporates characteristic#2", but we didn't happen to need the parameter-subscripts to distinguish the roles in this case, *only because* the concepts playing the roles are distinct.
Given the role of this standard, this notation is confusing, and marking the subscripts as keywords is technically wrong. SBVR can continue to use this notation only if it is very clear about the distinction between the fact-type
"concept specializes concept"
and the template
parameter#1 (concept) specializes (concept) parameter#2

* Proposed solution:

Clarification is needed. How to do it is not clear.

Resolution: Clarify the meaning of subscripts used with placeholders. Expand the reference scheme for placeholders to support textual placeholders whose expressions use delimiting characters, subscripts and/or other marks. Make the use of a designation by a placeholder optional. Clarify how fact type forms are distinguishable within a namespace.
Revised Text: On page 24 replace Figure 8.4 with this: On page 26 in 8.3.4 remove the last Necessity under "placeholder" (the one that says "Each placeholder uses exactly one designation". On page 26 in 8.3.4 in the Reference Scheme under "placeholder" replace "designation that is used for the placeholder" with "expression of the placeholder". Add the following Note after the Reference Scheme. Note: The expression of a placeholder often consists of the signifier of a designation used by the placeholder, but it can include other things such as delimiting characters (as in '[proposition] is true') or a subscript (as in 'proposition1 is true') by which the placeholder can be distinguished within the fact type form that has it. A placeholder need not use a designation (as in '… is true'). On page 26 in 8.3.4 under "placeholder is at starting character position" add the following (before the Synonymous Form): Definition: the expression of the placeholder is textual and occurs within a textual expression of a fact type form starting at the starting character position On page 26 in 8.3.4 after the Definition of "placeholder uses designation" remove the synonymous form and add the following: Definition: the expression of the placeholder incorporates the signifier of the designation thereby indicating that any use of the fact type form having the placeholder substitutes for the placeholder an expression understood to denote instances of the concept represented by the designation Note: The means by which a placeholder incorporates a designation depends on convention. SBVR does not require a particular convention, but it uses one described in Annex C, SBVR Structured English. Example: The 'proposition' placeholder in the fact type form 'proposition is true' uses the designation 'proposition'. The statement, "A fact is true", is understood to use that fact type form because a fact is a proposition, but "A line is true" is not recognized as using that fact type form because a line is not a proposition. Example: Consider two fact type forms for the same fact type: 'rental is returned on date' and 'rental has return date'. The second placeholders of the two forms represent the same role, but they use different designations ('date' and 'return date'). If "Rental 876" denotes a rental, then the statement, "Rental 876 is returned on 30 June 2006", is understood to use the first fact type form because "30 June 2006" is understood to denote a date, but the statement, "Rental 879 has 30 June 2006", is not understood to use the second fact type form because "30 June 2006" is not understood to denote a return date (only a date). "Rental 879 has the return date 30 June 2006" uses the second fact type form. Example: In the fact type form 'rental car1 replaces rental car2', both placeholders ('rental car1' and 'rental car2') use the same designation, 'rental car'. On page 27 add the following at the end of the entry for "fact type form is in namespace" (formerly "form of expression is in namespace"): Note: The distinguishability of a fact type form from others within a namespace is based on how a use of the fact type form is recognized. Distinguishability considers positions of placeholders, meanings of designations used by placeholders and the expression of the fact type form excluding expressions of placeholders. Example: The fact type form 'proposition is true' (with placeholder 'proposition') is indistinguishable from '[proposition] is true' (with placeholder '[proposition]') because both placeholders use a designation of the same concept ('proposition'), but those two forms are distinguishable from 'line is true' (with placeholder 'line') because 'proposition' and 'line' designate different concepts. On page 205, in the second of three paragraphs in C.3.1, replace the second and final sentence with this (including the example that follows): The expression of a placeholder is generally the underlined signifier of a designation used by the placeholder to indicate that expressions substituted for the placeholder are understood to denote instances of the designated concept. In the unusual fact type form where multiple placeholders use the same designation, the expression of a placeholder can include a subscript to make the expressions of placeholders distinct within the fact type form. Subscripts also help to correlate placeholders across synonymous forms as shown in the example below. concept1 specializes concept2 Definition: the concept1 incorporates each characteristic incorporated into the concept2 plus at least one differentiator Synonymous Form: concept2 generalizes concept1 Synonymous Form: concept1 has more general concept2 Synonymous Form: concept2 has category1 Throughout clause 14 (the Index of Vocabulary Entries) omit all subscripts from the entries.
Actions taken:
January 23, 2006: received issue
January 15, 2008: closed issue

Discussion:

More basic Issues had to be resolved first, and we ran out of time

Issue 9258: Logical formulations are fact-types (sbvr-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark@nist.gov edward.barkmeyer@nist.gov)
Nature: Revision
Severity: Significant
Summary:

In SBVR clause 9.1.1.6 (or 9.2.6 in later editions?), a "logical operator" is defined to be a (subtype of) logical formulation. The definition of logical-formulation says it is the *interpretation* of a logical formula. So logical formulation has to assign a semantic fact-type to a formula. But what is modeled in 9.2.6 is the logical *formula*, not the interpretation. What is modeled is "operator has operands", which is a grammatical notion, or perhaps a computational notion (Boolean expression). But the logical formulation is the interpretation of the operator and its operands as a fact-type.

Example 1: The logical formulation that underlies the terms "equivalence", "condition_1" and "condition_2", which appear in 9.1.1.5, and the formula fact-types "equivalence has condition_1" and "equivalence has condition_2", which appear in 9.1.1.6, is the fact-type
"logical-formulation is-equivalent-to logical-formulation"
This fact-type expresses the interpretation of a formula involving an equivalence operation and two 'condition' operands. The corresponding fact-type template might be
"condition_1 is-equivalent-to condition_2",
where condition_1 and _2 are roles fulfilled by logical formulations.

Example 2: The logical formulation that underlies the terms "conjunction", conjunct_1 and conjunct_2, and the formula fact-types "conjunction has conjunct_1" and "conjunction has conjunct_2" is the fact-type
"Both logical-formulation (#1) and logical-formulation (#2) hold."
This fact-type expresses the interpretation of the formula involving a conjunction symbol and two 'conjunct' operands (conjugends). The term "conjunction" is a 'name' for this fact-type.

The failure to define the logical formulations properly in 9.1.1.6 causes the roles in those fact-types to become 'terms with subscripts' in clause 9.1.1.5 (or 9.2.5 in later editions?). As indicated in the 'Fact types and templates' issue, the SBVR notation for a fact-type role is a 'local name' for a parameter to the fact-type template. In clause 9.1.1.5, this notational convention has been elevated to a concept term! In most (but not all) cases, this error is recognizable by the fact that the "concept term" is *subscripted*. In what speech community would 'condition_1' be a term?

Roles, in this sense, are only meaningful with respect to a given fact-type -- they are NOT self-standing terms that go in the glossary. Every logical operand "term" in clause 9.1.1.5 is just a role in a logical fact type that should be, but isn't, actually defined as a fact-type in 9.1.1.6.

If the logical operators are recast as fact-types, condition#1 would be the name of a template parameter, and the definitions would resemble those in Clause 8. The only difference between the logical formulations in Clause 9 and the fact-types in clause 8 is that, in clause 9, the roles are named something different from the participating concept (term).

Note, however, that some of these "role names" really are terms in mathematical logic. In particular, the roles "antecedent" and "consequent" are important to the discussion of "implication", because the roles are importantly different. These terms should be introduced as 'glossary terms'.

Conversely, the 'conjunct' roles in a conjunction and the 'condition' roles in an equivalence are not actually distinct -- all conjugends have the same behavior in a conjunction. And this is true of all subscripted role names in 9.1.1.5. These terms convey nothing more interesting than 'operand', but they can be defined, if desired, as 'terms' in 9.1.1.5. If they are defined, they should be defined without the subscripts, because the subscripts are nothing more than elements of the templates -- they don't distinguish behavior.

* Proposed solution:

9.1.1.6 needs to be restructured as logical fact types, and ALL the roles in 9.1.1.5 should be defined in those fact-type definitions. In most cases, the logical operator can become the 'Name:' of the fact-type. The relationship between these fact-types and their template definitions is the subject of another Issue.

Some or all of the role names with distinct behaviors (no subscripts) that are currently in 9.1.1.5 should be defined as 'terms' in 9.1.1.6. It does not seem appropriate to move them to a different section from the one that defines their semantics as roles in the logical formulations of the operations.

Resolution: see above
Revised Text: Replace Figure 9.7 on page 51 with this diagram: In 9.1.1.6, pgs. 52-54, remove the following fact type entries: conjunction has conjunct 1 conjunction has conjunct 2 disjunction has disjunct 1 disjunction has disjunct 2 equivalence has condition 1 equivalence has condition 2 exclusive disjunction has exclusive disjunct 1 exclusive disjunction has exclusive disjunct 2 logical negation has negand nand formulation has logical operand 1 nand formulation has logical operand 2 nor formulation has logical operand 1 nor formulation has logical operand 2 Move the 'logical operand' entry from 9.1.1.5 on page 48 to 9.1.1.6, putting it after the entry for 'logical operation'. In the Definition change "a" to "a given" so that the definition looks like this: Definition: logical formulation upon which a given logical operation operates Move the entries for 'logical operand 1' and 'logical operand 2' from 9.1.1.5 on page 49 to 9.1.1.6, putting them in front of the entry for 'conjunction'. Move the 'antecedent' and 'consequent' entries from 9.1.1.5 on page 49 to 9.1.1.6, putting them after the entry for 'implication'. Move the 'inconsequent' entry from 9.1.1.5 on page 50 to 9.1.1.6, putting it after the entry for 'whether-or-not formulation'. Completely remove the remainder of section 9.1.1.5 Logical Operands (pages 48 - 50). In 9.1.1.6, pg. 52, add the following entry after the entry for 'logical operation has logical operand', but in front of the entry for 'logical operand 1': binary logical operation Definition: logical operation that operates on two logical operands Necessity: Each binary logical operation has exactly one logical operand 1. Necessity: Each binary logical operation has exactly one logical operand 2. Note: Distinct roles are defined for the two operands of a binary logical operation even though in there is no significant difference between the roles for some operations, such as for conjunction. The one distinction that remains, however, is that the roles are distinct from each other, and this distinction is important where an operation has the same logical formulation filling both roles, such as in 'p and p' or 'p if and only if p'. In 9.1.1.6, pg. 52, add the following after the entry for 'logical operand 2'. binary logical operation has logical operand 1 Definition: the binary logical operation operates on the logical operand 1 binary logical operation has logical operand 2 Definition: the binary logical operation operates on the logical operand 2 In 9.1.1.6, pg. 52, replace the details under 'conjunction' with this: Definition: binary logical operation that formulates that the meaning of each of its logical operands is true In 9.1.1.6, pg. 52, remove the two Necessity statements under 'conjunction'. In 9.1.1.6, pg. 52, in the Reference Scheme under 'conjunction', replace each occurrence of 'conjunct' with 'logical operand' so that it looks like this: Reference Scheme: the logical operand 1 of the conjunction and the logical operand 2 of the conjunction In 9.1.1.6, pg. 52, replace the definition of 'disjunction' with this: Definition: binary logical operation that formulates that the meaning of at least one of its logical operands is true In 9.1.1.6, pg. 52, remove the two Necessity statements under 'disjunction'. In 9.1.1.6, pg. 52, in the Reference Scheme under 'disjunction', replace each occurrence of 'disjunct' with 'logical operand' so that it looks like this: Reference Scheme: the logical operand 1 of the disjunction and the logical operand 2 of the disjunction In 9.1.1.6, pg. 52, replace the definition of 'equivalence' with this: Definition: binary logical operation that formulates that the meanings of its logical operands are either all true or all false In 9.1.1.6, pg. 52, remove the two Necessity statements under 'equivalence'. In 9.1.1.6, pg. 52, in the Reference Scheme under 'equivalence', replace each occurrence of 'condition' with 'logical operand' so that it looks like this: Reference Scheme: the logical operand 1 of the equivalence and the logical operand 2 of the equivalence In 9.1.1.6, pg. 53, replace the definition of 'exclusive disjunction' with this: Definition: binary logical operation that formulates that the meaning of one logical operand is true and the meaning of the other logical operand is false In 9.1.1.6, pg. 53, remove the two Necessity statements under 'exclusive disjunction'. In 9.1.1.6, pg. 53, in the Reference Scheme under 'exclusive disjunction', replace each occurrence of 'exclusive disjunct' with 'logical operand' so that it looks like this: Reference Scheme: the logical operand 1 of the exclusive disjunction and the logical operand 2 of the exclusive disjunction In 9.1.1.6, pg. 53, replace the definition of 'implication' with this: Definition: binary logical operation that operates on an antecedent and a consequent and that formulates that the meaning of the consequent is true if the meaning of the antecedent, is true In 9.1.1.6, pg. 53, in the entry for 'implication has antecedent', remove the Synonymous Form and replace the Definition with this: Definition: the antecedent is the logical operand 1 of the implication In 9.1.1.6, pg. 53, in the entry for 'implication has consequent', remove the Synonymous Form and replace the Definition with this: Definition: the consequent is the logical operand 2 of the implication In 9.1.1.6, pg. 54, replace the definition of 'logical negation' with this: Definition: logical operation that has exactly one logical operand and that formulates that the meaning of the logical operand is false In 9.1.1.6, pg. 54, in the Necessity and in the Reference Scheme under 'logical negation', replace each occurrence of 'negand' with 'logical operand'. In 9.1.1.6, pg. 54, replace the definition of 'nand formulation' with this: Definition: binary logical operation that formulates that the meaning of at least one of its logical operands is false In 9.1.1.6, pg. 54, remove the two Necessity statements under 'nand formulation'. In 9.1.1.6, pg. 54, replace the definition of 'nor formulation' with this: Definition: binary logical operation that formulates that the meaning of each of its logical operands is false In 9.1.1.6, pg. 54, remove the two Necessity statements under 'nor formulation'. In 9.1.1.6, pg. 54, replace the definition of 'whether-or-not formulation' with this: Definition: binary logical operation that has a consequent and an inconsequent and that formulates that the meaning the consequent is true regardless of the meaning the inconsequent In 9.1.1.6, pg. 54, in the entry for 'whether-or-not formulation has consequent', remove the Synonymous Form and replace the Definition with this: Definition: the consequent is the logical operand 1 of the whether-or-not formulation In 9.1.1.6, pg. 54, in the entry for 'whether-or-not formulation has inconsequent', remove the Synonymous Form and replace the Definition with this: Definition: the inconsequent is the logical operand 2 of the whether-or-not formulation In 10.3.2.1 on page 103, replace the word "negand" with "logical operand". In 10.3.3.3 on page 105 add a row to the table with "binary logical operation" in column 1 and "logical formulation" in column 2. In 10.3.3.1 on pages 105 - 106, remove the following table entries: conjunct 1 conjunct 2 disjunct 1 disjunct 2 condition 1 condition 2 exclusive disjunct 1 exclusive disjunct 2 negand In C.3.6, page 205 replace the two occurrences of "negand" with "logical operand" and replace the definition that was given under what was "negand" (and is now "logical operand") with this: Definition: logical formulation upon which a given logical operation operates Disposition: Resolved
Actions taken:
January 23, 2006: received issue
January 15, 2008: closed issue

Discussion:

Give definitions to the categories of 'logical operation' that directly explain the meanings rather than referring to formal logic operators.  Remove unnecessary operand roles such as 'conjunct 1', etc.  Add 'binary logical operation' and explain the distinction between the roles 'logical operand 1' and 'logical operand 2'.

Issue 9344: define 'is less than' on 'quantity' (sbvr-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark@nist.gov edward.barkmeyer@nist.gov)
Nature:
Severity: Minor
Summary:

Problem Description:

Clause 8.7 defines 'integer' as "a number with no fractional part". But the concept 'number' to which this definition appeals is not defined, and the entry does not cite a source for the definition. 'number' should be defined as well.

SBVR clause 8.7 defines the fact-type 'integer is-less-than integer'.
This is a narrow definition of the 'less-than' concept, which applies, with the same semantics, to 'numbers' and to arbitrary quantities. 'Quantity' is the general concept on which comparison for less and greater is defined for business purposes. It is the concept for which is-less-than should be defined in 8.7.

In Annex D, 'is less than' is used as a fact-type for prices and durations in several places, but it is never defined. This usage requires a wider definition of the is-less-than fact-type that is defined in 8.7, namely a definition on 'quantity'. D.2.3.3 defines 'duration' as "a quantity of time", but the term 'quantity' is not a vocabulary entry in either 8.7 or Annex D. And D.2.3.3 defines the fact-type 'duration is-at-most duration', but it has the same semantics as quantity is-less-than (or equal to) quantity. It is clear that this example is a model for the definition of "measurement" vocabularies, and 8.7 should provide the base term 'quantity' to support that.

* Proposed solution:

(1) define the term 'quantity' in SBVR, e.g.,
Definition: a determinate or estimated amount [of a thing]
Definition: the aspect in which a thing is measurable in terms of greater, less or equal
Source: MW
Note: The concept quantity can be elaborated into mathematical systems, such as integer and real numbers, and into systems of measures. This specification elaborates only the concepts for integer, because they are commonly used in structural rules (See x.x). For measurement systems and units of measure there are accepted vocabularies and perhaps standard ontologies, but the specification of such a vocabulary is beyond the scope of this specification.

(2) replace the the fact-type 'integer is-less-than integer' with the fact-type 'quantity is-less-than quantity'.

(3) add the concept 'number'
Definition: a [quantity] belonging to an abstract mathematical system and subject to laws of succession, addition and multiplication
Source: MW

(4) make integer a subtype of number, and number a subtype of quantity.

(5) correct the "term" style for 'number' in the definition of integer in 8.7, and for 'quantity' in the definition of duration in D.2.3.3.

(6) In D.2.3.3, add to the definition of duration is at most duration:
Synonymous form: duration is less than or equal to duration

Resolution:
Revised Text: 1) In section 8.7, add the following three entries before the entry for "integer": quantity FL Definition: the aspect in which a thing is measurable in terms of greater, less or equal [MWU] General Concept: noun concept Note: The concept quantity can be elaborated into mathematical systems, such as integers and real numbers, and into systems of measures. This specification elaborates only the concepts for integer, because they are commonly used in structural rules. For measurement systems and units of measure there are accepted vocabularies and perhaps standard ontologies, but the specification of such a vocabulary is beyond the scope of this specification. quantity1 is less than quantity2 FL Definition: the quantity1 is mathematically less than the quantity2 Synonymous Form: quantity1 < quantity2 Synonymous Form: quantity2 is greater than quantity1 Synonymous Form: quantity2 > quantity1 number FL Definition: quantity belonging to an abstract mathematical system and subject to laws of succession, addition and multiplication Dictionary Basis: An arithmetical value, expressed by a word, symbol, or figure, representing a particular quantity and used in counting and making calculations [ODE: "number",1] 2) In section 8.7, change the definition of "integer" as shown below. Definition: number that has no fractional part 3) In section 8.7, delete the entry for "integer1 is less than integer2". 4) In E.2.3.3, add to the entry for "duration1 is at most duration2": Synonymous Form: duration1 is less than or equal to duration2 5) Replace figure 8.9 with this updated diagram:
Actions taken:
January 31, 2006: received issue
January 15, 2008: closed issue

Discussion:

Introduce "quantity" as a defined concept.
Introduce "number" as a category of "quantity".
Define "integer" as a category of "number".

Issue 9366: description of the type theory of SBVR needs to be included in 10.1.1 (sbvr-ftf)

Click here for this issue's archive.
Source: Hendryx & Associates (Mr. Stan Hendryx, stan@hendryxassoc.com)
Nature: Uncategorized Issue
Severity:
Summary:

This sentence appears near the end of 10.1.1: "We do not adopt a type theory such as Russell’s type theory, where each set may belong only to a set of a higher type." This is about all that is said in section 10 about the theory of types in SBVR. When I asked about the failure to include a description of SBVR's type theory, Tony said that the reason there was no description of SBVR's type theory was that there is no type theory in SBVR, or something to that effect. While it may be true that SBVR does not allow a hierarchy of degrees of types like that of Russel, and does not admit statements about whether or not sets can be members of themselves, it is not true that SBVR has no theory of concepts, which correspond to types. SBVR contains several asserted or implied general conditions on relationships among concepts. Should these be pointed out and tied to formal logic in section 10? The interpretation of a conceptual model that is described in terms of SBVR's vocabularies is crucially dependent on how SBVR formally regards the notions of consistency and unification of the concepts in the conceptual model, as a set of types.

Here are some questions that such a logical grounding of SBVR concepts might be expected to answer: How is the logical consistency of concepts to be determined? What is the most general concept? Under what conditions can new concepts be admitted into a conceptual schema or into a possible world? How are these rules affected by open/closed world assumptions? How is it determined if a set of concepts is well formed?

Some entries whose definitions, notes, and necessities bear on these questions are 'thing', 'concept', 'concept type', 'concept generalizes concept', 'intensional definition', 'delimiting characteristic', 'concept is closed in conceptual schema', 'fact type is internally closed in conceptual schema', and others.

Resolution: closed, no change
Revised Text:
Actions taken:
February 16, 2006: received issue
January 15, 2008: closed issue

Discussion:

As this issue raised about SBVR's "type theory" was precipitated by a statement Terry made in the former "logics appendix" (viz., "We do not adopt a type theory such as Russell's type theory, where each set may belong only to a set of a higher type"), I spoke with Terry about this issue, and would like to relate what I found out. Let me start, however, with two connected, pertinent observations about the issue:
1) The issue appears to arise from a misunderstanding of the technical sense in which Terry was using this term "type theory" (if you want a reasonably clear discussion of which, you might try http://planetmath.org/encyclopedia/AxiomOfReducibility.html);
2) The issue arose at a time when there was some enthusiasm for introducing a generous portion of upper-ontology stuff into SBVR, but on which SBVR, or at least the formal-grounding part of it, has no need to offer a commitment or make a statement.
In light of these two observations, I would recommend this issue be simply thrown out, as a misunderstanding of the formal-logics issue and an unnecessary expansion of SBVR into ontological issues.
For this issue, and the questions raised with it, are not at all formal-logics issues, says Terry. Certainly "type theory" in the sense that Terry was using it is; but even there, he says, the purpose of his statement in the "logics appendix" was precisely NOT to force any user of SBVR to adopt any particular type theory. (Indeed, Terry and Pat Hayes did not even discuss "type theory" when they were agreeing on what was to go in the "logics appendix"; Pat simply agreed implicitly to Terry's above statement.) So, while there are indeed options a user has with regard to "type theory" (cf. the above URL's article), SBVR does not adopt any specific one.

Issue 9368: Issue: Improve linkage to Rule/Business Rule in 10.1.1 Narrative (sbvr-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 Problem Description:


The narrative in 10.1.1 created artificial terminology ('logical rule',
'logic rule') as an interim step, but this left the material unconnected
with the SBVR senses of 'rule'.  The connection between the sense of 'rule'
-- as used in 10.1.1 and in the normative vocabularies of SBVR -- needs to
be made.


* Proposed solution:


Mark-up provided that:
 
(1) cites the SBVR definitions of the terms 'rule' and 'business rule'


(2) removes the interim language of 'logical rule' and 'logic rule',
replacing these terms with 'rule' or 'business rule' (incl. 'statements of
...'), as appropriate.

Resolution: see above
Revised Text: On pg. 71: In the first paragraph of 10.1.1.1, replace Formal rules may with Formal statements of rules may In the first paragraph of 10.1.1.1, replace into a logical formulation that is used with into logical formulations that are used In the first paragraph of 10.1.1.1, replace Informal rules may be with Informal statements of rules may be In the first paragraph of 10.1.1.1, replace confined to formal business rules. with confined to formal statements of business rules. On pg. 72: In the 3rd paragraph of 10.1.1.2, replace logical rules with rules In the 3rd paragraph of 10.1.1.2, remove (typically constraints or derivation rules) In the 4th paragraph of 10.1.1.2, replace Logical rules, with The terms 'rule' and 'business rule', In the 4th paragraph of 10.1.1.2, replace in the sense with in the senses In the 4th paragraph of 10.1.1.2, replace are regulations or principles governing conduct, procedure, etc. with are defined in Clause 12.1.2. In the 4th paragraph of 10.1.1.2, replace Logical rules with Rules On pg. 73: In the 1st paragraph after the 2nd boxed example, replace either a logical rule with either a rule In the 2nd paragraph after the 2nd boxed example, replace the logical rules with the rules On pg. 75: In the last paragraph, replace and logical rules with and business rules On pg. 76: In the 2nd paragraph, replace the logical rule with the rule On pg. 77: In the paragraph before the 1st boxed example, replace those logical rules with those business rules In the paragraph after the 1st boxed example, replace the logical rule with the rule On pg. 83: In the 1st paragraph, replace the logical rules with the rules On pg. 84: In the paragraph after the 1st boxed example, replace The logical rule with The rule In the paragraph after the 1st boxed example, replace the logical rule with the rule In the paragraph after the Table, replace these logical rules with these rules On pg. 85: In the paragraph after the 2nd boxed example, replace for logical rule verbalization, with for rule verbalization, In the 3rd boxed example, replace this logical rule with this rule In the 3rd boxed example, replace the logical rule with the rule In the paragraph after the 3rd boxed example, replace most logical rules with most statements of business rules In the paragraph after the 3rd boxed example, replace the whole logical rule expression. with the whole rule statement. In the paragraph after the 3rd boxed example, replace the logical rule with the rule On pg. 86: In the 1st boxed example, replace logical rule C1 with rule C1 In the 1st boxed example, replace this logical rule with this rule formulation In the 1st boxed example, replace the logical rule with the rule In the 2nd boxed example, replace logical rule C2 with rule C2 In the 2nd boxed example, replace the logical rule into with the rule formulation into In the paragraph after the 2nd boxed example, replace logical rule examples with rule examples In the paragraph after the 2nd boxed example, replace tagging a logical rule with tagging a rule In the paragraph after the 2nd boxed example, replace logical rule enforcement with rule enforcement In the paragraph after the 2nd boxed example, replace obligation rule condition with obligation rule In the paragraph after the 2nd boxed example, replace out of scope for the proposal (logical rule enforcement and logical rule management are to be addressed in separate proposals). with out of scope. In the paragraph after the 2nd boxed example, replace refining the logical rule with refining the rule In the 1st paragraph of 10.1.1.5, replace Logic rule formulations with Rule formulations In the 3rd boxed example, replace the logical rule is understood with the rule is understood In the 3rd boxed example, replace the logical rule is revoked with the rule is revoked On pg. 87: In the 2nd paragraph, replace tag the logical rule with tag the rule In the 3rd paragraph, replace explicit logical rule formulation with explicit rule formulation In the 3rd paragraph, replace front of the logical rule. with front of the rule formulation. In the 3rd paragraph, replace elsewhere in the logical rule, with elsewhere in the rule formulation, In the 2nd paragraph after the boxed example, replace single logical rule with single rule formulation In the 3rd paragraph after the boxed example, replace static logical rule with static rule In the 3rd paragraph after the boxed example, replace logical rule formulation and with rule formulation and In the 2nd paragraph of 10.1.1.6, replace logical rule includes with rule formulation includes In the 2nd paragraph of 10.1.1.6, replace then the logical rule with then the rule In the 2nd paragraph of 10.1.1.6, replace the logical rule's condition is violated with the rule is violated In the 2nd paragraph of 10.1.1.6, remove the entire last sentence, i.e., the sentence that begins with: A later submission On pg. 88: In the boxed example, replace logical rule body with rule body In the boxed example, replace tagging the logical rule as with tagging the rule body as In the 2nd paragraph after the boxed example, replace logical rule formulation, with rule formulation, In the 2nd paragraph after the boxed example, replace transformation logical rules with transformation rules In the 3rd paragraph after the boxed example, replace static logical rule with static rule In the 3rd paragraph after the boxed example, replace express the logical rule with express the rule In the 3rd paragraph after the boxed example, replace these logical rules with these rules On pg. 89: In the 1st paragraph, replace tagging a logical rule with tagging a rule body In the boxed example, replace the following logical rule: with the following rule: On pg. 90: In the last paragraph, replace to cater for logical rules with to cater for rules In the last paragraph, replace such logical rules. with such rules. On pg. 91: In the boxed example, replace following logical rule: with following business rule: In the boxed example, replace adopts a logical rule with adopts a rule In the boxed example, replace Objectify Department adopts Logical rule as LogicRuleAdoption, with Objectify Department adopts Rule as RuleAdoption, In the boxed example, replace LogicRuleAdoption is forbidden; with RuleAdoption is forbidden; In the boxed example, replace LogicRule obligates the with Rule obligates the In the boxed example, replace LogicRuleAdoption is forbidden is forbidden with RuleAdoption is forbidden is forbidden In the boxed example, replace LogicRuleAdoption is by a Department with RuleAdoption is by a Department In the boxed example, replace of a LogicRule with of a Rule In the 1st paragraph after the boxed example, replace structure of the logical rule with structure of the rule In the 1st paragraph after the boxed example, replace treat the logical rule with treat the rule On pg. 92: In the 1st paragraph, replace problematic logical rules. with problematic rules. In the 1st paragraph of 10.1.1.7, replace supports logical rules with supports rules In the 1st paragraph of 10.1.1.7, replace or 'if'-rules for with or 'if' for On pg. 93: In the boxed example, replace invoice logical rule with invoice rule In the 1st paragraph after the boxed example, replace what logical rules did with what transformation rules did In the 1st paragraph after the boxed example, replace the logical rule? with the rule? In the 1st paragraph after the boxed example, replace a logical rule formulation with a rule formulation In the 2nd paragraph after the boxed example, replace the logical rule. with the rule. In the 2nd paragraph after the boxed example, replace this logical rule with this rule
Actions taken:
February 22, 2006: received issue
January 15, 2008: closed issue

Discussion:

Revise narrative such that it:
(1) cites the SBVR definitions of the terms 'rule' and 'business rule'
(2) removes the interim language of 'logical rule' and 'logic rule', replacing these terms with 'rule' or 'business rule' (incl. 'statements of ...', etc.), as appropriate.

Issue 9399: Section: Section F.2.1.2 (RuleSpeak Annex) (sbvr-ftf)

Click here for this issue's archive.
Source: Business Rules Group (Mr. Ronald G. Ross, rross@BRSolutions.com rross@brsolutions.com)
Nature: Revision
Severity: Significant
Summary:

Based on the Feb. 23 FTF meeting, I retracted a correction that I had sent in for the RuleSpeak Annex, as below. It was pointed out that my correction was improperly worded (especially regarding "represented"), and that the phrase did not convey my actual intent. *** Replace "if all roles for" with: *** "If all noun concepts represented by roles for" The correct phrasing may need to reference "fundamental concepts". In any event, the correct wording involves a larger issue than simply RuleSpeak, or the specific point I was making here.

Resolution: Provide clear wording of the appropriate criteria
Revised Text: In F.2.1.2, in the 2nd bullet under "Comments", replace: "If all noun concepts represented by roles for a fact type are well-defined, a definition for the fact type itself generally adds very little." with: "When the meaning of a fact type is the dictionary meaning for the verb phrase in the context of well-defined noun concepts for the things that play the roles, a definition for the fact type itself generally adds very little."
Actions taken:
February 25, 2006: received issue
January 15, 2008: closed issue

Issue 9444: Chapter 12 page 139: Add Synonyms (sbvr-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Add Synonyms for the following 3 entries:
    
   CURRENT ENTRY                SYNONYM (to be added)
   ==============       ================
   structural rule                    definitional rule
   structural business rule       definitional business rule
   operative business rule       behavioral business rule

Resolution: see above
Revised Text: In 12.1.2 (pg. 139): 1. To the entry for "structural rule", add the following after its "Necessity"-captioned item: Synonym: definitional rule 2. Add a new entry immediately after the "structural rule" entry, as follows: definitional rule See: structural rule 3. To the entry for "structural business rule", add the following after its "Definition"-captioned item: Synonym: definitional business rule 4. Add a new entry immediately after the "structural business rule" entry, as follows: definitional business rule See: structural business rule 5. To the entry for "operative business rule", add the following after its final "Necessity"-captioned item: Synonym: behavioral business rule 6. Add a new entry immediately after the "operative business rule" entry, as follows: behavioral business rule See: operative business rule Revised Figure: 7. See final version of Fig. 12.1 (pg. 137) under Issue 9477
Actions taken:
March 15, 2006: received issue
January 15, 2008: closed issue

Discussion:

Add 3 synonyms to 3 existing SBVR vocabulary entries; reflect the synonyms on the diagram

Issue 9446: Add 'Synonym: aspect' caption (sbvr-ftf)

Click here for this issue's archive.
Source: ARCorp (Keri Anderson Healy, )
Nature: Uncategorized Issue
Severity:
Summary:

Add 'Synonym: aspect' caption that is currently missing under the entry for
'facet'
    
There is an entry for 'aspect', which is a secondary term for the concept
termed 'facet'.  However, the entry for 'facet' is missing the corresponding
'Synonym:' caption referring to  'aspect'.


Action:  Add the following caption under the entry for 'facet':
   Synonym:  aspect
(using the paragraph style for 'synonym' with 'term' character styling
applied to the word 'aspect').

Resolution: Correct the inconsistency.
Revised Text: In 11.1.5.2 (pg. 125): 8. To the entry for "facet", add the following after its "Necessity"-captioned item: Synonym: aspect Revised Figure: None needed. (The figure already correctly-reflects the ssynonym.)
Actions taken:
March 15, 2006: received issue
January 15, 2008: closed issue

Issue 9447: Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept (sbvr-ftf)

Click here for this issue's archive.
Source: ARCorp (Keri Anderson Healy, )
Nature: Clarification
Severity: Significant
Summary:

Integrate use of 'fact model' terminology in 10.1.1 with SBVR term/concept


p. 32, entry for 'conceptual model':
  add caption:  Synonym:  fact model  ==>[with 'fact model' styled term]


p. 32, add entry for 'fact model':
fact model    ==> [styled as appropriate for an entry]
  See:  conceptual model    ==>[styled appropriately]
    
p. 72, final paragraph:  after "is a fact model, not a process model." to
read:
"is a fact model (in SBVR, termed 'conceptual model'), not a process model."

Resolution: see above
Revised Text: Resolution: 1. Add "fact model" to Meaning and Representation Vocabulary (for the meaning now given to "conceptual model"). 2. Make "fact model" the preferred term, making "conceptual model" a synonym. 3. "A fact model is specified as a conceptual model …" on page 73 (10.1.1.2) must be changed to "A fact model is a conceptual model …." Revised Text: Note: In making the changes that follow, all singular/plural forms, and all fonts, are to be preserved as they currently appear in the document. Instruction 1. pp. 31--32 ... in the Definition for "fact type is internally closed in conceptual schema" ... Change "conceptual model" to "fact model" in each of the 3 instances below. Definition: in each conceptual model based on the conceptual schema, for each instance of the fact type, the conceptual model includes a corresponding fact if, for each thing filling any of the fact types roles in the instance, the conceptual model also includes a fact of the existence of that thing Instruction 2. In the diagram at the top of p. 31 ... Change "conceptual model" to "fact model" in each of the 2 instances below. a.) In the box that is currently labeled "conceptual model". b.) In the fact type (at the bottom of the diagram) that currently reads: "[fact type] has [fact] in [conceptual model]". Instruction 3. pp. 32 ... In the Note at the top of the page ... Change "conceptual model" to "fact model" in the 1 appearance below. Open world semantics are assumed by default, but closure may be explicitly asserted for any fact type, on an individual basis, to declare that each conceptual model population agrees with that of the fact types extension in the actual business domain. Semi-closure is with respect to the domain model population of the noun concepts playing a role in the fact type. In other words, if the things participating in a fact are known within a model, then the fact is also known within that model. Instruction 4. p. 32 ... In the Definition for "concept is closed in conceptual schema" ... Change "conceptual model" to "fact model" in each of the 2 instances below. Definition: in each conceptual model based on the conceptual schema, the entire extension of the concept is given in the facts included in the conceptual model Instruction 5. p. 32 ... Change the entry currently called "conceptual model" to "fact model". Instruction 6. p. 32 ... After the Definition for the entry currently called "conceptual model" (now to be called "fact model"), add the following captioned line: Synonym conceptual model Instruction 7. pp. 32 ... In the Note after the Definition for conceptual model (now "fact model") ... Change "conceptual model" to "fact model" in the 1 appearance below. Each necessity of the conceptual schema is satisfied by a conceptual model, but obligations are not necessarily satisfied. Instruction 8. p. 32 ... Change the entry currently called "conceptual model is based on conceptual schema" to "fact model is based on conceptual schema". Instruction 9. p. 32 ... In the Definition for "conceptual model is based on conceptual schema" (now to be called "fact model is based on conceptual schema"), change "conceptual model" to "fact model" in the 1 appearance below. the conceptual schema provides the concepts and modal facts of the conceptual model Instruction 10. pp. 32 ... In the Synonymous Form given after the Definition for "conceptual model is based on conceptual schema" (now to be called "fact model is based on conceptual schema"), change "conceptual model" to "fact model" in the 1 appearance below. Synonymous Form: conceptual schema underlies conceptual model Instruction 11. p. 32 ... Change the entry currently called "conceptual model includes fact" to "fact model includes fact". Instruction 12. p. 32 ... In the Definition for "conceptual model includes fact" (now to be called "fact model includes fact"), change "conceptual model" to "fact model" in the 1 appearance below. Definition: the fact corresponds to an actuality in the possible world modeled by the conceptual model Instruction 13. pp. 32 ... In the Synonymous Form given after the Definition for "conceptual model includes fact" (now to be called "fact model includes fact"), change "conceptual model" to "fact model" in the 1 appearance below Synonymous Form: fact is in conceptual model Instruction 14. p. 32 ... Change the entry currently called "fact type has fact in conceptual model" to "fact type has fact in fact model". Instruction 15. p. 32 ... In the Definition for "fact type has fact in conceptual model" (now to be called "fact type has fact in fact model"), change "conceptual model" to "fact model" in the 1 appearance below. the fact is in the conceptual model and the fact corresponds to an instance of the fact type Instruction 16. p. 34 In the introductory text for 8.6.2 Necessities Governing Extension, change "conceptual model" to "fact model" in the 1 appearance below. The following statements of necessity apply to the relationships between a meaning and its extension. Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of conceptual schemas and their representations. But the following necessities concern each conceptual model in relation to the conceptual schema that underlies it. Instruction 17. p. 71 In the 2nd paragraph, change "conceptual model" to "fact model" in the 7 appearances below. A conceptual model includes both a conceptual schema and a population of facts that conform to the schema. A conceptual model may cover any desired time span, and contain facts concerning the past, present or future. This notion is distinct from changes made to a conceptual model. Any change to a conceptual model, including any change to any fact in the fact population, creates a different conceptual model. Each conceptual model is distinct and independent, although there may be relationships between conceptual models that share the same conceptual schema. Instruction 18. p. 71 In the 4th paragraph, change "conceptual model" to "fact model" in the 2 appearances below. SBVR makes no distinction about how facts are known: for example, whether they are asserted as 'ground facts' or obtained by inference. Inferences can only be performed at one time within a particular conceptual model. SBVR does not define any kind of inference that can be made between conceptual models. Instruction 19. p. 71 In the 5th paragraph, change "conceptual model" to "fact model" in the 1 appearance below. Control over the order in which inferences can be made is a common feature in the automation of inference, as found, for example, in rules engines. SBVR deals with declarative rules expressed from a business perspective. Transitions between conceptual models and the mechanization of those rules in an automated system are outside the scope of SBVR. Instruction 20. p. 73 In the next to last paragraph, first sentence (replicated below), change A fact model is specified as a conceptual model to A fact model is a conceptual model . A fact model is specified as a conceptual model of the business domain, using a suitable high level vocabulary and language that is readily understood by the business domain experts. Instruction 21. p. 102 ... 10.3.2.1 Mapping to Formal Logic, change " "conceptual model" to "fact model" in the 6th row of the table. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Actions taken:
March 15, 2006: received issue
January 15, 2008: closed issue

Discussion:

Resolution:
1.	Add "fact model" to Meaning and Representation Vocabulary (for the meaning now given to "conceptual model").
2.	Make "fact model" the preferred term, making "conceptual model" a synonym.
3.	"A fact model is specified as a conceptual model …" on page 73 (10.1.1.2) must be changed to "A fact model is a conceptual model …."

Issue 9448: Add (and explain) styling for 90 days where it appears in formal statement (sbvr-ftf)

Click here for this issue's archive.
Source: ARCorp (Keri Anderson Healy, )
Nature: Clarification
Severity: Critical
Summary:

Add (and explain) styling for "90 days" where it appears in a formal
statement
    
In the 10 Example Rules (several places throughout the Annexes), "90 days"
appears unstyled in a rule statement.


Actions needed:


1) Add styling to "90 days"  [pages: 223, 282, 293 (2 places), 306 (2
places)] where it appears in a formally-styled rule statement (i..e., this
does not apply to its use in Notes, etc.)


2) Add an explanatory section to Annex C, using this as an example,
describing in general how an individual that involves the representation of
some 'quantity' is represented in a formal (fully-styled) SBVR expression.
Make reference to other standards/words, as appropriate.
[ref. earlier discussion thread on SBVR-FTF]

Resolution: 1. Correct rule statement Example 2 to read "... is at most 90 rental days." -- i.e., to use the name 'rental days' which is defined in the EU-Rent vocabulary as one of the valid instances of RTU. Style "90 rental days" to apply Name style. 2. Correct this Example's Supporting fact type to cite "rental has rental duration". 3. Add "Supporting fact types" as a way of explanation. Note: There is no generalized treatment for quantities and measurement that has been agreed. There are no changes needed in the Annex for SBVR Structured English, which does not try to address the grammatical patterns used for quantities and measurement. 4. Add a Note to the entry for the rule in the EU-Rent ruleset, explaining that this illustrates one possible way to do this.
Revised Text: In E.1.4 (pg. 227): 1. To Example 2, change the statement to read: It is obligatory that the duration of each rental is at most 90 rental days. 2. Change the first fact type cited in the "Supporting fact type" to: rental has rental duration to correspond to the entry in the EU-Rent Vocabulary (see p. 253). 3. Add the following "Related facts" items to the end of Example 2: Related facts: The noun concept 'rental duration' is a role of the noun concept 'duration'. rental duration is measured in rental time unit [aka RTU] The individual concept 'rental day' is an instance of the noun concept 'rental time unit'. In E.2.2.2.7 (pg. 286): 1. In the 2nd rule statement, change (& correct) the statement to read: It is obligatory that the duration of each rental is at most 90 rental days. Note: the "at most" in this statement needs to be corrected from Keyword style to Verb style. 2. Change the fact type cited in the "Supporting fact type" to: rental has rental duration to correspond to the entry in the EU-Rent Vocabulary (see p. 253). 3. Add the following Note after the Description clause and before the Enforcement Level: Note: There are other legitimate ways to define what a duration is. Standards organizations, including ISO, are working on standards for measurement, including measurement of time. When there is a clear consensus on such standards, SBVR will adopt them as defaults. In the interim, individual enterprises will define for themselves consistent ways to represent measurements within their own vocabularies. EU-Rent has elected to style duration as a name denoting an instance of duration. But, being aware that other organizations might have taken a different approach to defining these kinds of measurements, EU-Rent will be watchful that, in an interchange that involves measurements, there may be things needing adjustment. In Annex F (pg. 297): 1. To Example 2 (first statement), change the statement to read: It is obligatory that the duration of each rental is at most 90 rental days. 2. To Example 2 (RuleSpeak version), change the statement to read: The duration of a rental must not be more than 90 rental days. In Annex F.3.6 (pg. 309): 1. In the 3rd rule statement, change the statement to read: It is obligatory that the duration of each rental is at most 90 rental days. Note: the "at most" in this statement needs to be corrected from Keyword style to Verb style. 2. In the 3rd rule statement (the 'boxed' RuleSpeak version), change the statement to read: The duration of a rental must be at most 90 rental days. Note: the "at most" in this statement needs to be corrected from Keyword style to Verb style.
Actions taken:
March 15, 2006: received issue
January 15, 2008: closed issue

Discussion:

More basic Issues had to be resolved first, and we ran out of time

Issue 9449: SBVR-FTF Issue: 10 Example Rules material (sbvr-ftf)

Click here for this issue's archive.
Source: ARCorp (Keri Anderson Healy, )
Nature: Enhancement
Severity: Significant
Summary:

The "10 Example Rules" material is a useful reference in training and other
explanatory applications.  However, its current presentation makes that
difficult -- it is:  redundantly presented (leading to some inconsistencies,
and extra work as updates are made), is incomplete (does not reflect the ORM
expression style), and needs other minor updates.


Actions needed:


1) Move and consolidate the presentation of the "10 Example Rules" from
Annexes E and F into a new Annex.


2) Correct inconsistencies, as needed.


3) Add the expression of each of the 10 rules in ORM notation.


4) Correct the supporting (based on) fact types to match the entries in the
EU-Rent vocabulary (Annex E).

Resolution: 1) It was decided that, rather than consolidate into a single Annex, the material would be kept in individual Annexes (the current EU-Rent Annex E and the RuleSpeak Annex F) and that the 10 Examples in ORM would be added into Annex I. 2) Corrections to the 10 Examples are given below. 3) The ORM version of the 10 Examples replaces the current section "I.3 Some EU-Rent Rule Examples", as provided below. 4) Corrections to the EU-Rent vocabulary for the 'supporting fact types' and 'related facts' used in the 10 Examples are given below.
Revised Text: Changes to Annex E.1.4 Introductory Examples REMOVE from Clause E.1.4 (pg. 227, Example 2): that the duration of each rental and REPLACE with: that the rental duration of each rental REMOVE from Clause E.1.4 (pg. 227, Example 2): rental has duration and REPLACE with: rental has rental duration ADD to Clause E.1.4 (pg. 227, Example 2), immediately following the "Supporting fact type" list: Related facts: The noun concept 'rental duration' is a role of the noun concept 'duration'. rental duration is measured in rental time unit The individual concept 'Rental Day' is an instance of the noun concept 'rental time unit' REMOVE from Clause E.1.4 (pg. 227, Example 3): driver of a rental is a qualified driver. and REPLACE with: driver of a rental is qualified. ADD to Clause E.1.4 (pg. 227, Example 3), to the end of the "Supporting fact type" list: driver is qualified REMOVE from Clause E.1.4 (pg. 227, Example 3) the "Related fact": and REPLACE with: The noun concept 'driver' is a facet of the noun concept 'person'. REMOVE from Clause E.1.4 (pg. 227, Example 4): and REPLACE with: It is obligatory that the rental incurs a location penalty charge if the drop-off location of a rental is not the EU-Rent site that is base for the return branch of the rental. DELETE from Clause E.1.4 (pg. 227, Example 4), from the "Supporting fact type" list: branch is located at EU-Rent site ADD to Clause E.1.4 (pg. 227, Example 4), to the end of the "Supporting fact type" list: EU Rent site is base for rental organization unit ADD to Clause E.1.4 (pg. 227, Example 4), immediately following the "Supporting fact type" list: Related facts: The noun concept 'return branch' is a role of the noun concept 'branch'. The noun concept 'branch' is a category of the noun concept 'rental organization unit'. The noun concept 'EU-Rent site' is a role of the noun concept 'location'. The noun concept 'drop-off location' is a role of the noun concept 'location'. REMOVE from Clause E.1.4 (pg. 228, Example 6): charged to the credit card of the renter of the rental. and REPLACE with: charged to a credit card of the renter that is responsible for the rental. REMOVE from Clause E.1.4 (pg. 228, Example 6, in the "Supporting fact type" list): rental has estimated rental charge and REPLACE with: rental has rental charge REMOVE from Clause E.1.4 (pg. 228, Example 6, in the "Supporting fact type" list): rental has renter and REPLACE with: rental has driver REMOVE from Clause E.1.4 (pg. 228, Example 6, in the "Supporting fact type" list): rental is open and REPLACE with: rental is open ADD to Clause E.1.4 (pg. 228, Example 6), to the end of the "Supporting fact types" list: renter is responsible for rental REMOVE from Clause E.1.4 (pg. 228, Example 6, from the "Related facts" list): and REPLACE with: The noun concept 'estimated rental charge' is a category of the noun concept 'rental charge'. The noun concept 'renter' is a role of the noun concept 'person'. The noun concept 'driver' is a facet of the noun concept 'person'. REMOVE from Clause E.1.4 (pg. 228, Example 7): and REPLACE with: It is obligatory that the local area that includes the return branch of an in-country rental or international inward rental owns the rented car of the rental at the actual return date/time of the rental. ADD to Clause E.1.4 (pg. 228, Example 7), to the end of the "Supporting fact types" list: rental has rented car REMOVE from Clause E.1.4 (pg. 228, Example 7, in the "Related facts" list): The noun concept 'international rental' is a category of the noun concept 'rental'. and REPLACE with: The noun concept 'international rental' is a category of the noun concept 'one-way rental'. The noun concept 'one-way rental' is a category of the noun concept 'rental'. REMOVE from Clause E.1.4 (pg. 229, Example 8): that at the actual start date/time of each rental and REPLACE with: that at the actual pick-up date/time of each rental REMOVE from Clause E.1.4 (pg. 229, Example 8, in the "Supporting fact types" list): rental has actual start date/time and REPLACE with: rental has actual pick-up date/time ADD to Clause E.1.4 (pg. 229, Example 8), to the end of the "Related facts" list: The noun concept 'actual pick-up date/time' is a role of the noun concept 'date/time'. Changes to EU-Rent Vocabulary REMOVE from Annex E.2.2.1.1, p. 234, for the entry "car movement has movement-id", in the Necessity (first term), each and REPLACE with: Each REMOVE from Annex E.2.2.1.1, p. 234, for the entry "car movement has receiving branch", in the Necessity (first term), each and REPLACE with: Each REMOVE from Annex E.2.2.1.1, p. 234, for the entry "car movement has sending branch", in the Necessity (first term), each and REPLACE with: Each ADD to Annex E.2.2.1.1, p. 235, for the entry "car movement specifies car group", before the Necessity: Synonymous Form: car group is specified in car movement REMOVE from Annex E.2.2.1.1, p. 235, for the entry "car movement specifies car group", in the Necessity (first term), each and REPLACE with: Each REMOVE from Annex E.2.2.1.1, p. 236, for the entry "rental car is assigned to car movement", in the 2nd Necessity: car movement is of the car group specified by the car movement and REPLACE with: car movement is of the car model that is included in the car group that is specified in the car movement ADD to Annex E.2.2.1.3, p. 241, for the entry "branch is included in local area", after the Concept Type and before the Necessity: Synonymous Form: local area includes branch REMOVE from Annex E.2.2.1.3, p. 242, for the entry "EU-Rent operating company", in the Definition, operating company of and REPLACE with (unstyled): operating company of ADD to Annex E.2.2.1.3, p. 242, for the entry "EU-Rent operating company", after the Definition and before the first Note: Synonym: operating company DELETE from Annex E.2.2.1.3, p. 242, for the entry "EU-Rent operating company operates in operating country", the Necessity that is shown under it. ADD to Annex E.2.2.1.3, p. 242, for the entry "EU-Rent operating company operates in operating country" immediately under the entry concept's primary representation: Synonymous Form: operating company has operating country ADD to Annex E.2.2.1.3, p. 243, after the entry for "EU-Rent site is base for rental organization unit", the new entry: EU-Rent site is located in operating country Synonymous Form: operating country includes EU-Rent site Necessity: Each EU-Rent site is located in exactly one operating country. REMOVE from Annex E.2.2.1.3, p. 243, for the entry "local area", in the Definition, area management responsibility and REPLACE with: area responsibility DELETE from Annex E.2.2.1.3, p. 243, the entire entry "local area includes branch". ADD to Annex E.2.2.1.3, p. 243, for the entry "local area is included in operating company" after the Concept Type and before the Necessity: Synonymous Form: operating company includes local area ADD to Annex E.2.2.1.3, p. 243, for the entry "operating country", after the Definition: Necessity: Each operating country has exactly one currency. REMOVE from Annex E.2.2.1.4, p. 247, for the entry "car group", in the Necessity, car model of a car group and REPLACE with: car model that is included in a car group REMOVE from Annex E.2.2.1.4, p. 247, for the entry "car group", in the Necessity, is charged at the rental rates of and REPLACE with (unstyled): is charged at the rental rates of ADD to Annex E.2.2.1.4, p. 248, for the entry "car model is included in car group", immediately before the Necessity: Synonymous Form: car group includes car model REMOVE from Annex E.2.2.1.5, p. 252, for the entry "actual pick-up date/time", in the Definition, when and REPLACE with (using the standard font properties for unstyled Definition text): when REMOVE from Annex E.2.2.1.5, p. 252, for the entry "actual pick-up date/time", in the Definition, is picked up and REPLACE with (unstyled): is picked up REMOVE from Annex E.2.2.1.5, p. 252, for the entry "actual pick-up date/time", in the Definition, the renter and REPLACE with: the renter REMOVE from Annex E.2.2.1.5, p. 252, for the entry "actual return date/time", in the Definition, when and REPLACE with (using the standard font properties for unstyled Definition text): when REMOVE from Annex E.2.2.1.5, p. 252, for the entry "actual return date/time", in the Definition, is returned and REPLACE with (unstyled): is returned ADD to Annex E.2.2.1.5, p. 252, for the entry "pick-up branch", before the Necessity caption: Concept Type: role General Concept: branch REMOVE from Annex E.2.2.1.5, p. 252, for the entry "rental", Definition: contract with renter specifying use of a car of a car group for a rental period and a car movement and REPLACE with: Definition: contract with a renter specifying use of a car of a car group for a rental period and a car movement REMOVE from Annex E.2.2.1.5, p. 252, for the entry "rental duration", in the Definition, used to calculate and REPLACE with (unstyled): used to calculate ADD to Annex E.2.2.1.5, p. 253, for the entry "rental includes car movement", after the Concept Type caption: Synonymous Form: car movement is included in rental ADD to Annex E.2.2.1.5, p. 254, for the entry "rental includes rental period", after the Concept Type and before the Necessity: Synonymous Form: rental period is included in rental ADD to Annex E.2.2.1.5, p. 254, for the entry "rented car is assigned to rental", immediately before the Necessity: Synonymous Form: rental has rented car REMOVE from Annex E.2.2.1.5, p. 254, for the entry "rented car is assigned to rental", in the Necessity, is included in_ and REPLACE with (no 'underline' of the trailing space): is included in ADD to Annex E.2.2.1.5, p. 254, for the entry "renter has possession of rented car" after the Definition: Synonymous Form: rented car is in the possession of renter REMOVE from Annex E.2.2.1.5, p. 254, for the entry "return branch", in the Note, does not return the car to this branch, and REPLACE with: does not return the car to the location of this branch, ADD to Annex E.2.2.1.6, p. 257, after the entry for "in-country one-way rental", the new entry: in-country rental General Concept: rental ADD to Annex E.2.2.1.6, p. 258, after the entry for "local one-way rental", the new entry: one-way rental Definition: rental that includes a one-way car movement REMOVE from Annex E.2.2.1.6, p. 259, for the entry "rental being open" rental being open Concept Type: rental state Definition: rental having a rented car that is in possession of the renter and the end date/time of the grace period of the rental is in the future and REPLACE with: rental is open Concept Type: rental state Definition: the rental has a rented car that is in the possession of the renter and the end date/time of the grace period of the rental is in the future DELETE from Annex E.2.2.1.7, p. 260, Fig. E.9, the 3-ary fact type "[rental charge] is calculated in [business currency] of [rental]". REMOVE from Annex E.2.2.1.7, p. 260, Fig. E.9, the two 'has' fact types from 'rental' to 'estimated rental charge' and 'actual rental charge' and REPLACE with: a single 'has' fact type from 'rental' to 'rental charge'. REMOVE from Annex E.2.2.1.7, p. 262, for the entry "estimated rental charge" in the Definition, _estimated at start of rental and REPLACE with (unstyled and no underlined leading space): estimated at start of rental ADD to Annex E.2.2.1.7, p. 264, after the entry "rental has business currency", the new entry: rental has rental charge ADD to Annex E.2.2.1.8, p. 266, after the entry "corporate rental agreement has applicable rental rate", the new entry: country has currency REMOVE from Annex E.2.2.1.9, p. 268, for the entry "bad experience", in the Definition, an undesirable occurrence and REPLACE with: undesirable occurrence REMOVE from Annex E.2.2.1.9, p. 269, for the entry "drop-off branch", in the Possibility, may be returned to a branch other than and REPLACE with: may be returned to a location other than REMOVE from Annex E.2.2.1.9, p. 269, for the entry "drop-off location", in the Definition, is dropped off and REPLACE with (unstyled): is dropped off ADD to Annex E.2.2.1.9, p. 269, after the entry "bad experience is fault of driver", the new entry: bad experience occurs during rental REMOVE from Annex E.2.2.1.9, p. 271, the entry rental uses drop-off location and REPLACE with: rental has drop-off location REMOVE from Annex E.2.2.1.11, p. 277, for the entry "driver", in the Definition: who can drive the rented car of a rental and REPLACE with: who can drive the rented car of a rental REMOVE from Annex E.2.2.1.11, p. 277, for the entry "driver being qualified" driver being qualified Definition: driver being over 21 years old and having a valid driver's license and not being under any pending legal action that could adversely affect his driver's license or insurability. and REPLACE with: driver is qualified Definition: the driver is over 21 years old and has a valid driver license and is not under any pending legal action that could adversely affect his driver's license or insurability ADD to Annex E.2.2.1.11, p. 278, for the entry "renter is responsible for rental", after the Concept Type and before the Necessity: Synonymous Form: rental has renter Necessity: Each rental has exactly one renter. Changes to EU-Rent Rule Sets REMOVE from Clause E.2.2.2.2 (pg. 279, paragraph 1): driver of a rental is a qualified driver. and REPLACE with: driver of a rental is qualified. REMOVE from Clause E.2.2.2.2 (pg. 279, paragraph 1): must be a qualified driver. and REPLACE with: must be qualified. REMOVE from Clause E.2.2.2.2 (pg. 280, 1st Rule): rental has exactly one rental period. and REPLACE with: rental includes exactly one rental period. REMOVE from Clause E.2.2.2.3 (pg. 280, 1st Rule): charged to the credit card of the renter of the rental. and REPLACE with: charged to a credit card of the renter that is responsible for the rental. REMOVE from Clause E.2.2.2.3 (pg. 280, 1st Rule), in the "Supporting fact types" list: rental has estimated rental charge and REPLACE with: rental has rental charge REMOVE from Clause E.2.2.2.3 (pg. 280, 1st Rule), in the "Supporting fact types" list: rental has renter and REPLACE with: rental has driver ADD to Clause E.2.2.2.3 (pg. 280, 1st Rule), to the end of the "Supporting fact types" list: rental is open renter is responsible for rental REMOVE from Clause E.2.2.2.3 (pg. 280, 1st Rule), from the "Related facts" list: and REPLACE with: The noun concept 'estimated rental charge' is a category of the noun concept 'rental charge'. The noun concept 'renter' is a role of the noun concept 'person'. The noun concept 'driver' is a facet of the noun concept 'person'. REMOVE from Clause E.2.2.2.3 (pg. 281, 4th Rule): the car group or rental duration of a rental and REPLACE with: the requested car group or rental duration of a rental REMOVE from Clause E.2.2.2.3 (pg. 281, list of Supporting fact types below the 5th Rule): rental has car group and REPLACE with: rental has requested car group REMOVE from Clause E.2.2.2.4 (pg. 282, 2nd Rule): driver of a rental is a qualified driver. and REPLACE with: driver of a rental is qualified. ADD to Clause E.2.2.2.4 (pg. 282, 2nd Rule), to the end of the "Supporting fact type" list: driver is qualified DELETE from Clause E.2.2.2.4 (pg. 282, 2nd Rule), the first item in the "Related facts" list: REMOVE from Clause E.2.2.2.5 (pg. 284, 2nd Rule): the EU-Rent site of the return branch and REPLACE with: the EU-Rent site that is base for the return branch ADD to Clause E.2.2.2.5 (pg. 284, 2nd Rule), to the end of the "Supporting fact type" list: EU Rent site is base for rental organization unit ADD to Clause E.2.2.2.5 (pg. 284, 2nd Rule), immediately following the "Supporting fact type" list: Related facts: The noun concept 'return branch' is a role of the noun concept 'branch'. The noun concept 'branch' is a category of the noun concept 'rental organization unit'. The noun concept 'EU-Rent site' is a role of the noun concept 'location'. The noun concept 'drop-off location' is a role of the noun concept 'location'. REMOVE from Clause E.2.2.2.5 (pg. 285, 1st Rule): the actual start date/time of each rental and REPLACE with: the actual pick-up date/time of each rental REMOVE from Clause E.2.2.2.5 (pg. 285, 1st Rule), in the "Supporting fact types" list: rental has start date/time and REPLACE with: rental has actual pick-up date/time ADD to Clause E.2.2.2.5 (pg. 285, 1st Rule), to the end of the "Related facts" list: The noun concept 'actual pick-up date/time' is a role of the noun concept 'date/time'. REMOVE from Clause E.2.2.2.7 (pg. 286, 2nd Rule): that the duration of each rental and REPLACE with: that the rental duration of each rental REMOVE from Clause E.2.2.2.7 (pg. 286, 2nd Rule, Supporting fact type): rental has duration and REPLACE with: rental has rental duration REMOVE from Clause E.2.2.2.11.2 (pg. 291, 1st Rule): charged to the credit card of the renter and REPLACE with: charged to a credit card of the renter Changes to EU-Rent Common Vocabulary DELETE from Annex E.2.3.3, p. 293, for the entry "duration", the (empty) Concept Type caption that is shown under it. DELETE from Annex E.2.3.3, p. 293, for the entry "period", the (empty) Concept Type caption that is shown under it. REMOVE from Annex E.2.3.3, p. 294, for the entry "date/time", the first caption: Source: and REPLACE with: Dictionary Basis: REMOVE from Annex E.2.3.3, p. 294, for the entry "date/time", the 2nd caption: Source: and REPLACE with: Dictionary Basis: ADD to Annex E.2.3.3, p. 294, to the entry "duration1 is at most duration2", immediately under the entry concept's primary representation: Synonymous Form: duration2 is more than duration1 Changes to Annex F -- Examples in Introduction REMOVE from Annex F (pg. 297, Example 2): that the duration of each rental and REPLACE with: that the rental duration of each rental REMOVE from Annex F (pg. 297, Example 2): The duration of a rental and REPLACE with: The rental duration of a rental REMOVE from Annex F (pg. 297, Example 3): driver of a rental is a qualified driver. and REPLACE with: driver of a rental is qualified. REMOVE from Annex F (pg. 297, Example 3): driver of a rental must be a qualified driver. and REPLACE with: driver of a rental must be qualified. REMOVE from Annex F (pg. 297, Example 4): and REPLACE with: It is obligatory that the rental incurs a location penalty charge if the drop-off location of a rental is not the EU-Rent site that is base for the return branch of the rental. REMOVE from Annex F (pg. 297, Example 4): A rental must incur a location penalty c