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 9477: The current notion of "actionable" falls short in several regards
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 9933: SBVR Issue - Context for understanding representations
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 9943: Section: 8.7
Issue 9944: Section: 11.2.1.3
Issue 9945: “Admonition” and “Affirmation” are the same concept
Issue 9946: Section: 8.3
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 9951: Section: Clauses 8, 9, 11, 12
Issue 9952: Section: 8.3.5, 11.1.1, 11.2.1
Issue 9953: Section: 8.1.1
Issue 9954: Page: 13-14 ++
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 10528: SBVR Issue: MOF/XMI Vocabulary and Rules Cleanup
Issue 10560: Vocabulary Adoption vs. Inclusion
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 10576: Section: 9.3
Issue 10577: Distinguish Between Concepts
Issue 10578: Section: 11.1.1.1
Issue 10579: Section: 8.7
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 10621: Definition of 'question'
Issue 10622: Closed logical formulation formalizes statement
Issue 10628: Align Annex E with the normative text
Issue 10629: URI is not a role
Issue 10630: Rule-Set is not a defined concept
Issue 10631: owned definition and adopted definition are roles
Issue 10632: definition of 'prohibited symbol'
Issue 10633: The unary fact type/characteristic "category is inactive"
Issue 10639: implicit passive form for partitive fact type that uses the verb "includes"
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 10803: 'state of affairs' is an individual concept, not a thing
Issue 10958: Entry for "categorization scheme", p. 147, Definition. and Example
Issue 11153: "Definition of Category"
Issue 11263: NIAM Annex
Issue 11264: Sjir Nijssen Revisions to Clause 10
Issue 11283: SBVR Issue: OMG URLs
Issue 11285: Gap that Needs to be Filled by Concept Role Playing of Thing in Occurrence
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 11296: Additional Improvements to Clause 10
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 11301: The Notion of “Involvement” has not been Adequately Specified with in SBVR
Issue 11303: SBVR Metamodel Fixes Related to a Formal Logics Interpretation
Issue 11328: Clarify and Strengthen Note at Beginning of Clause 10 Formal Logic Interpre
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.)
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.
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.
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.
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.
More basic Issues had to be resolved first, and we ran out of time
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.
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'.
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
Introduce "quantity" as a defined concept. Introduce "number" as a category of "quantity". Define "integer" as a category of "number".
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.
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.
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.
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.
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.
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 ruleAdd 3 synonyms to 3 existing SBVR vocabulary entries; reflect the synonyms on the diagram
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').
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: 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 …."
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]
More basic Issues had to be resolved first, and we ran out of time
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).