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

a. A reference scheme is needed for individual concept.

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

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

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

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

a. A reference scheme is needed for individual concept.

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

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

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

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

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

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

a. A reference scheme is needed for individual concept.

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

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

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

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: "SBVR 'Thing' <-> 'Expression' Architecture" Needs Fixing 1. Form for Representation needs to be added between 'meaning' and 'representation' to include 'semantic formulations; forms of concept meaning (intensional, extensional,etc.); types of forms of expression. 2. 'Representation' should to tie to 'form of representaiton' instead to directly to meaning and add should only Speech Community considerations (language, Speech Community-specific terms, notations) to 'form of representation'. 3. 'Expression is in Language' needs to be added 4. Representations, at least designations, should be in canonical form 5. The relationship between 'representation' and 'expression' should allow for basic linguistic analysis e.g. multiple spellings, plurals, etc.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Bring the Specification of SBVR Which is in Terms of Itself to the the Full SBVR Metamodel Standard The current specification of SBVR in terms of itself (SBVR Structured Englich) is not completed or up to full integrity in that: 1. not all SBVR metamodel constructs are specific for each SBVR entry in Clauses 8, 9, 1, and 12 2. some entries are lower quality than they should be, e.g. some definiitions are not fully structured; some necessities are missing; etc. 3. Definitions and Necessities have not been fully tested by software to see that all supporting entries in in SBVR.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Use URI to Uniquely Identify and Assert the Existence of Every 'Thing' Represented in an SBVR Model to Support Multi-Classification of 'Things' Need to develop a URI pattern for all kinds of representations that can assert the existence of any 'thing' in an SBVR Model. These patterns need to take Speech Community and Symbol Context / Subejct Area into account. The appraoch chosen needs to support composite identifiers and identifiers with a narrow context scope. Topic Maps has an excellent approach for this and has done extensive work with the W3C to identifying the issues with URIs and the best ways to deal with them. For Topic Map / W3C References see: ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Subject%20Identifiers.doc Another benefit of this is that is laying the necessary foundation for mapping to RDF/ORL as well as the Rules Interchange Format

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Major Categories of 'Thing' Need to be Related and Made Clear Important in any case, but especially so with the inclusion of 'objects' as vocabulary entires, the major concepts that are subcategories of 'thing' such as 'state of affairs', 'actuality', 'expression', 'res', 'object', (as defined by the terminology community), etc. need to be related and clarified to such the major divisions of 'thing' that are significant in SBVR of SBVR. This will make the real world cornerstone of SVCR much clearer for new audiences.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Context for understanding representations

A definition given for a fact type commonly refers to the roles of the fact type using placeholders from a form of expression of the fact type. But the SBVR vocabulary provides no relationship between a definition and the form of expression for which the definition makes sense (the one having the placeholders used in the definition). A new fact type must be added to SBVR in order to capture this relationship. Otherwise there is insufficient context to interpret the definition. The problem occurs because there can be many forms of expression for a fact type, and these can uses different designations for placeholders.

A similar problem occurs where a note or example for a concept only makes sense in relation to a particular designation or form of expression, such as when the example or note refers to the designation or a placeholder of the form of expression. Similarly, the expression of a reference supporting a concept often does not include the designation used in a source document because the reference is given in relation to that particular designation for the concept. But if there are many designations for the concept, the reference cannot be adequately interpreted with respect to the source document.

Also, a note about a rule might make sense only in the context of a particular statement of the rule because the note refers to specific words used in the rule. But the same rule can be represented by many different statements.

Recommendation: Add a new fact type to the Meaning and Representation Vocabulary after ‘representation represents meaning’:

representation relates to representation

And explain that the first representation is understood in the context of the second representation.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Issue 10504 (Ballot 8) gave an instruction to add a Definition clause to an existing entry, but the Edit Instruction indicated the wrong Clause location of that existing entry. This resulted in duplicate fact types for "body of shared meanings includes body of shared guidance" in Clauses 11 and 12.

Correct this by removing the entry from Clause 11 and adding the Definition text (specified by Issue 10504's Resolution) to the intended, existing entry in Clause 12

When "nonverbal designation" was added into the taxonomy, the Necessities specifying its mutual exclusivity with 'term' and 'name' were provided. Since it is now a category of 'nonverbal designation', 'icon' no longer needs to specify this as well. On p. 184, delete the two Necessities shown under "icon".

Remove the two Necessities from the entry for "icon".

The "change all" of 'symbol' to 'designation' specified that 'fact symbol' was to be left unchanged. Revert the following two changes.

• On p. 184, change the entry now shown as "fact designation" back to "fact symbol".
• On p. 270, undo the strike-out of "fact symbols" (and its replacement with "designations").
  P One global change too far er Issue 9941: In clause 11 REPLACE each remaining occurrence of "symbol" with "designation" (including plural cases), keeping font and capitalization the same, EXCEPT RETAIN "fact symbol" unchanged, everywhere (including in its plural form "fact symbols").

withdrawn by submitter

On p. 184, in the entry for "icon", the leading term should be "nonverbal designation" (not simply "designation").
Per Issue 9941: In the definition of 'icon' (as updated in the resolution to Issue 9952) REPLACE 'designation' with 'nonverbal designation'.

withdrawn by submitter

Two text changes from the global change ('symbol' to 'designation') were made in the text (see p. 181) but missed in the corresponding fact types in the Figure. Replace Fig. 11.6 (p. 180) with this: (email to issue 11298

Replace Fig. 11.6 with one that reflects the correct wording of the two fact types (i.e., to match the text entries).

The entry for 'general concept' was removed from Clause 11; accordingly, the box for it should be shaded. Replace Fig. 11.2 (p. 164) with this: figure attached to issue 11297 email

Replace Fig. 11.2 with one showing a shaded box for 'general concept'.

In the final read through of Annex E (EU-Rent example) a few errors of content were noticed.
Corrections are given below.

Revised Text:
E.2.2.1.1: rental car is assigned to car movement
Necessity:
replace "…car movement is of the car model …"
with "…car movement is of some car model …"
E2.2.1.2: transfer drop-off branch
Definition:
replace "branch from which the transferred car of a car transfer is picked up"
with "branch at which the transferred car of a car transfer is dropped off"
E.2.2.1.5: pick-up branch
Necessity:
replace "The pick-up branch of a rental may not be changed."
with "The pick-up branch of a rental is not changed."
E.2.2.1.5: rental
Definition:
replace "… specifying use of a car of a car group…"
with "… specifying use of some car of a car group…"
E.2.2.1.9 drop-off branch
replace Necessity "A car may be returned to a location other than …"
with Note "A car may be returned to a branch other than …"
E.2.2.1.10 rental car is of car model
Insert new entry immediately following:
rental car is of car group
Concept Type: associative fact type
Necessity: A rental car is of a car group if and only if the rental car is of some car model that is included in the car group.
E.2.2.1.11 renter is responsible for rental
Necessity
Replace "The renter of a rental may not be changed"
With "The renter of a rental is not changed"
E.2.2.2.5 Page 380, second rule
Rule statement
Replace "If the actual pick-up date/time of each rental is after the end date/time …"
With "If the actual return date/time of a rental is after the end date/time …"
Supporting fact types
Replace "rental has actual pick-up date/time"
With "rental has actual return date/time"
Related facts
Delete "the noun concept 'actual pick-up date/time' is a role that ranges over the noun concept 'date/time'"
E.2.2.2.11.2 First rule
Rule statement
Replace "… is provisionally charged to a credit card …"
With "… is provisionally charged to some credit card …"

Repeated error in Necessity for inclusion in a segmentation
In several places the Necessity is incorrectly stated as
"aaa is included in Bbbbbbb" instead of
"The concept 'aaa' is included in Bbbbbbb".
For example, in E.2.2.1.3, city branch:
replace "city branch is included in Branches by Type."
with "The concept 'city branch' is included in Branches by Type."
The same change needs to be made for:
E.2.2.1.6 in-country one-way rental
E.2.2.1.6 in-country rental
E.2.2.1.6 international rental
E.2.2.1.6 international inward rental
E.2.2.1.6 international outward rental
E.2.2.1.6 local one-way rental
E.2.2.1.6 round-trip rental
E.2.2.1.6 walk-in rental
E.2.2.1.7 cash rental
E.2.2.1.7 cash rental price
E.2.2.1.7 driver charge
E.2.2.1.7 extras charge
E.2.2.1.7 penalty charge
E.2.2.1.7 points rental
E.2.2.1.7 points rental price
E.2.2.1.11 corporate renter
E.2.2.1.11 individual customer

Characteristics used to define states.
There is a mixture of use of the verb form and the gerund form. The verb form seems better for states. The changes are:
Section Replace With
E.2.2.1.6 advance rental being assigned advance rental is assigned
E.2.2.1.6 advance rental being reserved advance rental is reserved
E.2.2.1.6 rental being returned rental is returned
E.2.2.1.9 rental being late rental is late
E.2.2.1.9 rental being overdue rental is overdue
E.2.2.1.9 rental car being in need of repair rental car is in need of repair
E.2.2.1.9 rental car being in need of service rental car is in need of service
E.2.2.1.9 driver being barred driver is barred

Disposition: Resolved

No Data Available

In 8.7 in the definition of “cardinality”, remove the word “distinct”. Note that “distinct” remains in the definition of “set has cardinality”, but is not appropriate for cardinalities of all collections types (e.g. bags).

Make the suggested change.

On p. 171, in the entry for "definition serves as designation", the text for "serves as designation" should be entirely styled using verb styling.
Per Issue 9952: In 11.1.3 REPLACE the entry for 'definition is used as term of concept' with this:
definition serves as designation
Definition: the definition acts as a designation of the concept defined by the definition
Note: In the case of a concept for which no designation is given, the concept is represented by its definition.

withdrawn by submitter

Multiple changes (different Issues) resulted in ambiguous instructions for placement of entries. On p. 169, move the new entry for "definite description" to follow the entry for "intensional definition uses delimiting characteristic".

withdrawn by submitter

Sjir Nijssen Revisions to Clause 10 – "With respect to Clause 10 I would like to make the following suggestions which are primarily communication motivated:" 10.1.1.2 1. Facts refer to individuals ... please change to: Instantiated roles of facts refer to individuals 2. The schema declares ... please change to: The conceptual schema declares 3. Derivation rules indicate how a fact type may be derived from one or more fact types ... please change to: Derivation rules indicate how the population of a fact type may be derived from the populations of one or more fact types 4. machine-oriented technical language (such as C#, Java, or SQL) ... please change to: machine-oriented technical language (such as C# or Java) [It could be argued that SQL is another way of expressing first order logic and SBVR does not regard this as a machine-oriented language.] 5. An existential fact is used to simply assert the existence of an individual ... please change to: An existential fact is used to simply assert the existence and identification of an individual 6. The domain-specific component includes declarations of ... please change to: The domain-specific component includes the concept definitions and declarations of 7. The classification of facts as forwarded last saturday could help in Clause 10 or be put in Annex M.

The suggestions were reviewed, and agreed, by Terry Halpin, with the exception of number 5, to which Terry responded:
It's much better for formalization purposes to leave the definition of existential fact the way I originally worded it. Identification claims are made separately (in ORM by asserting uniqueness and mandatory constraints, which may be in simple or composite reference schemes).

NIAM Annex – NIAM is the grandfather of fact-based semantic approaches, and has significant current application. However, it is not represented in the SBVR document. Its approach should be represented among the Annexes, in a manner corresponding to SBVR-SE, RuleSpeak and ORM.

1. Re-letter Annex L as Annex M.
2. Add the NIAM Annex as Annex L
3. Add bibliography references in the new Annex L to Annex M.
4. Add the Annex changes to Clause 6.2.1
5. Add acknowledgement to 6.3

In 9.3 in some Necessity statements the term “scoped-over variable” is used, but is undefined. The Necessity statements need to be reworded.

Correct the Necessity statements.

In 9.2.5 in the definition of ‘binary logical operation’, CHANGE “logical formulation” to “logical operation”.

Make the correction.

The URLs of SBVR’s XML documents must be changed to match OMG’s new file structure whose base directory is www.omg.org/spec.

Change the affected URLs.

In clause 11.1.2, the term 'category' is defined as:
'concept in a generic relation having the broader intension'
Similarly, the term 'more general concept' is defined as:
'concept in a generic relation having the narrower intension'

I don't know, and the text doesn't say, what a 'generic relation' may be. One might conclude that it means "any instance of the concept 'relation'", but SBVR doesn't define the concept 'relation', either.
Assuming the 'relation' is an undocumented synonym for 'fact type', the only "relation" that involves these terms jointly is
'concept1 has more general concept2'
Synonymous Form: 'concept2 has category'

(1) It appears that both of these are synonymous forms for 'concept1 specializes concept2', which is defined in clause 8.1.1. These could easily have been defined to be roles in that fact type, e.g.:
category specializes more general concept
This would make it clear that the relationship is 'specializes' and not some undefined 'generic relation'.

(2) The terms 'broader intension' and 'narrower intension' appear to be assigned to the wrong concepts. Does a 'broader intension' mean
"an intension that applies to more things"
or
"an intension that involves more characteristics"?
For the existing text to be correct, the meaning must be the latter – the 'category' applies to fewer things, so its 'broader intension' must mean that it involves more characteristics. This usage is counterintuitive – people think of "more general concepts" being "broader concepts".

Recommended action:

These two definitions should be rewritten to
(a) specify that the 'generic relation' is the "specializes" relationship, preferably by defining the roles as part of the definition of that relationship, in clause 8.1.1,
and
(b) discard "broader intension" and "narrower intension" in favor of wording that says specifically that it is about more "things" or more "characteristics".

Regarding (a): no change.
Regarding (b): add a note to "category" explaining the intended meaning of "broader intension" as "an intension that applies to more things". Add a similar note to "more general concept" explaining "narrower intension".

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.)

see above

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.)

see above

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.)

see above

The root of many problems is the flawed definition of "rule" in SBVR,
which differs from the sense that was intended in the formal logic
appendix. The SBVR definition is also at odds with the dictionary
definition of "rule" and includes some riders that seem a little
bizarre.

The intended meaning of "rule" in the formal logic appendix was the
dictionary meaning of the term. The definitive source (the ODE - Oxford
Dictionary of English) has the following:

Rule (core meaning)
"One of a set of explicit or understood regulations or principles
governing conduct or procedure within a particular area of activity."

Rule (main subsidiary meaning)
"A law or principle that operates within a particular sphere of
knowledge, describing or prescribing what is possible or allowable."

You will recall that when we tried to make such a definition explicit in
the revision of the formal logic appendix there was vehement opposition
from some members of the FTF, and we were obliged to indulge in the
unhappy compromise of using the term "logic rule" to mean the above
(although it is indeed the correct definition of "rule").

By the way, the ODE defines "logical" as:
"Of or according to the rules of logic."
(and, yes, it does dare to say "rules"!)

In contrast, here are the relevant SBVR definitions:

======================================================

rule
Definition: element of guidance that introduces an obligation or a
necessity Dictionary Basis: standard by which something is judged or
valued; criterion [MWUD (2B) 'rule'] Dictionary Basis: principle or
standard by which something may be judged or decided [determined] [NODE
'criterion'] Dictionary Basis: standard on which a judgment or decision
may be based [MWCD (2) 'criterion']

element of guidance
Definition: directive that is actionable, whose purpose is to advise or
inform with a goal of resolving a problem or difficulty, especially as
given by someone in authority
Necessity: No business policy is an element of guidance.

directive
Definition: means that defines or constrains some aspect of an
enterprise General Concept: proposition
Note: This sense of 'means' (as in 'ends and means', rather than 'is
meant as') arises from the Business Motivation Model.
Note: Intended to assert business structure or to control or influence
the behavior of the enterprise.
Note: Its formulation is under the enterprise's control by a party
authorized to manage, control or regulate an enterprise, by selection
from alternatives in response to a combination of assessments.
Dictionary Basis: an official or authoritative instruction [NODE]

directive is actionable
Concept Type: characteristic
Note: 'Actionable' means that a person who knows about the directive
could observe a relevant situation (including his or her own behavior)
and decide directly whether or not the business was complying with the
directive. Dictionary Basis: subject to or affording ground for an
action or suit at law [MWUD 'actionable'] Dictionary Basis: a thing done
: DEED [MWUD (5a) 'action']
Note: The sense intended is: "It's actually something you can put to use
or apply."

====================================================

As you can see, SBVR effectively treats "rule" as a synonym of
"criterion". I fear that this is fundamentally incorrect. The ODE says
that a criterion is: "A principle or standard by which something may be
judged or decided." The ODE does not equate "criterion" with "rule", as
the SBVR definition implies.

For example, a bank may decide that one criterion for determining that a
customer should be treated as a Gold Customer is the length of time they
have held an account. Another criterion might be balance held in the
account, averaged over some period. The bank might then define a "Gold
Customer" rule that uses these (and probably other) criteria. In simple
cases, a rule may boil down to not much more than a single criterion,
but that does not change the fact that "rule" and "criterion" are
different concepts, and are clearly identified as such in the ODE. It's
hard to see what SBVR gains by attempting to muddle the two together.
Why not let "rule" simply mean "rule"?

A second problem is the use of "actionable" in the SBVR definitions. The
intent of SBVR was to provide business level descriptions, not
prescriptions for processing. It may well be that a rule necessitates
some actions at a machine level, but that should be outside the SBVR
scope. It's hard to see how alethic constraints fit with the SBVR idea
of "actionable". For example, how does one "action" something like "a
person is born in exactly one country"? A strict interpretation of the
current SBVR definitions would appear to disallow alethic constraints of
this kind.

The dictionary justification quoted for "actionable" (and, by
inheritance, "rule" too) is also rather weird – I doubt that many
business rules are framed with legal action in mind.

A further problem is the demotion of a rule to just being a piece of
advice or information, rather than defining what must or must not be the
case. A rule may advise or inform, but that's not necessarily its
primary purpose, as claimed in the SBVR definitions.

In summary, the SBVR definition of "rule" could be paraphrased as "an
advisory criterion used to invoke a deed for which one could be sued",
which is very different from the ODE definition (and the common English
usage) of "rule". This SBVR meaning is NOT the meaning intended in the
formal logic section. Simply replacing "logic rule" by "rule" without
changing the SBVR definition of "rule" would therefore change the
meaning of the formal logic section.

A common-sense solution would be to change the term in SBVR from "rule"
to something like "SBVR rule", so that the term "rule" could be used
where necessary in its normal English language sense. In this case,
"logic rule" in the formal logic section could revert to just being
"rule" and no definition would be necessary since we would be using it
in its everyday sense. Where we can use ordinary English words in their
ordinary English sense it's hard to think of any reason why we should
not do so.

see above

The current notion of "actionable" falls short in several regards:

• It does not take into account structural (definitional) rules.
• Its wording is based on "complying", which is only appropriate for operative (behavioral) rules.
• It fails to address the issue of lexical indexicals – conversational references to person, place and time.

The attached document (SBVR-Actionable-pp138+178.doc) reflects the detail of
the proposed revision.

see above

The Interchange discussion in chapters 13 and Annexes K and L appear to discuss exchange of meaning between tools. But what about representations and expressions? Presumably users would want to preserve their forms of expression when moving rules between tools. Is that a goal of the Interchange design? If the answer is yes, then tool implementors will need more detail about how to accomplish that.

Consider the first example in chapter 9, "A rental must have at most three additional drivers". I can think of several ways to associate the expression with the semantic formulation described in this chapter.

1. Use the fact type "statement is formalized by closed logical formulation" to associate the complete rule statement with the top-level semantic formulation.
2. Use the fact types "representation has expression", "representation represents meaning" and "closed semantic formulation formulates meaning" to associate the complete rule statement (as an expression) to a representation that then gets associated to a meaning that then gets associated with the semantic formulation. This seems like one too many levels of indirection: why isn't a semantic formulation a type of meaning?
3 . Decompose the statement into sub-statements such as "rental has at most three additional drivers" and "rental has additional drivers" and associate these individually with the corresponsing logical formulations that compose the complete formulation. That is, exchange the expression corresponding to each logical formulation.

Absent further guidance, tool vendors will choose different answers to such questions. That will defeat the goal of interoperability between tools and repositories.

Resolved by the resolution to Issue 9950.

Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2.

Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation).

Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant.

Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned.

Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1.

Section 10.1.2 defines prohibition but not impossibility.

Suggestions:

1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 – but that seems undesirable since the unrestricted forms do appear in the real world.
2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality.
3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications.
4. Adopt a consistent approach to the negative forms (prohibition, impossibility):
a) Adopt one designation for nonpermission/forbidden/prohibition.
b) Define impossibility in section 10.1.2.
c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities.

No Data Available

SBVR vocabularies are represented (e.g. in SBVR.xsd) as "Instantiation" types, when sections 13.1.1 and 13.3.3 say they should be mapped to packages

A metamodel generated from each SBVR vocabulary (e.g. The Meaning and Representation Vocabulary described in Clause 8) is created based on the mapping rules in clause 13, and that metamodel is, in UML terms, a package. A designation for such a vocabulary (e.g. 'Meaning and Representation Vocabulary' defined in Clause 7) is mapped, liked every other designation for a noun concept, to a subclass of the Instantiation Class. This double appearance of "Meaning and Representation Vocabulary" results because SBVR is in terms of itself and is not a problem. Add a note into clause 13 to clarify how a vocabulary namespace might appear to be mapped more than once.

In semantic formulations, only variables and text are bindable targets. Because a role binding cannot bind to an individual concept, the formulation of rules involving individual concepts are overly large and complicated. For example, a formulation of something a simple as “1 + 2 = 3” must involve three quantifications and three variables, but it should be accomplished with a single atomic formulation. Or a formulation of “EU-Rent uses FedEx” must have quantifiers and variables for EU-Rent and for FedEx.

An early submission of SBVR had individual concepts as bindable targets. This was removed because individual concepts do not necessarily have the same extension across all time and in all possible worlds. Binding directly to individual concepts might not work when formalizing statements like “The President was once not the President” or “In 1776 there was no Statue of Liberty”. Explicit quantification would guarantee a precise formulation in all cases.

However, there is a way to allow binding to individual concepts while preserving precision. The way is to rigorously explain what is meant by a binding to an individual concept, and to explain it in terms of quantification. If that is done, then all bindings to individual concepts have a precise meaning. Special cases can continue to be handled using quantification.

Add 'individual concept' into the extensional definition of 'bindable target'. Explain precisely the meaning of a binding to an individual concept.

Problem Description Under the list of Operative Rule Keywords in the first paragraph of the page, the following is listed: << only ... often as in 'only if' ... rule keyword >> The actual full rule keyword is "may ... only". "Only" may not be used without "may". "Only" produces a restricted permissive form of a rule; "may" must be present to indicate that permission is being restricted. (Note: the corresponding structural rule keyword is "can ... only", which is given correctly in the list for the next paragraph on that same page.) Proposed Solution: 1. Change << only ... often as in 'only if' ... rule keyword >> to: << may ... only ... often as in 'only if' ... rule keyword >> 2. In the third paragraph of text, item 1, which reads: ‘Should’ may be used in place of ‘must’ in expressing a business rule only if one of the following is true: • The business rule does not have an enforcement level. • The business rule has an enforcement level, and that enforcement level is consistent with the English sense of ‘should’. ... change the very first "may" (second word in the extracted text) to styled text for rule keyword.

see above

Clause 10.2 promises a formal mapping from the "logical formulation vocabulary" in clause 9.1.1 to the mathematical logic vocabulary presented in 10.1.2. But the content of clause 10.2 is empty. No such mapping is provided.

Note that several logical concepts defined in 9.1.1 (e.g. negation, conjunction, disjunction, equivalence) have no direct cognates in the vocabulary presented in 10.2. For these concepts, either 10.1.2 must be expanded to include the definitions, or the mapping table must specify the equivalent logical formula (wff) as a composition of implications.

Note further that Clause 10.2 defines many of its terms as elements of a grammar for a surface syntax (expression) for the logical concepts defined here and there in clause 10.1. Clause 9.1.1 appears to define an abstract syntax for the same purpose. There is no reason why these two grammars should not describe the same expressions.

Recommendation:

Provide the mapping, revising clause 9.1.1 and/or 10.1.2 as needed to align the grammars.

Resolved by the resolution of Issue 9959.

There are some inconsistencies between Annex C (which explains proper SBVR
Structured English) and Annex E (which illustrates proper usage of SBVR
Structured English), as follows:

point-1) The unary fact type definitions are not written as fact type
definitions – i.e., beginning with a definite article ("the") plus the
placeholder term, and then saying something propositional. Instead, they
are written in the style appropriate to a noun concept – i.e., leading with
a term, followed by restrictive clauses.

point-2) The form of expression of the entry concept uses a participle –
e.g., 'having' or 'being') rather than an active verb. I was told that, in
SBVR Structured English, using the participle implies meaning in addition to
the naked fact type. That additional meaning is generally handled within a
semantic formulation that uses the fact type.

point-3) There is some ambiguity about the use of quantifiers (etc.) in the
form of expression. (ref. SBVR p. 201, final sentence of C.3.1), which
says, "It is recommended that quantifiers (including articles) and logical
operators not be embedded within designations and forms of expression."
Often we see a 'characteristic' (unary fact type) that uses an article
or quantifier. Is that incorrect? Or does 'unary fact type' have a
different set of guidelines for its form of expression?

point-1) Unary fact type definition expressions, when presented using the SBVR Structured English Definition caption, should be written in the standard way for fact type definitions, i.e., beginning with a definite article ("the") plus the placeholder term, and then saying something propositional. Any Annex C definitions that are written in a style appropriate to a noun concept – i.e., leading with a term, followed by restrictive clauses – should be corrected during the general pass to correct Annex E (if retained as Definition-captioned text).
point-2) The present participle form is an alternative for the fact type form of an entry concept. The Annex C explanation needed a small change to make this clear. (See below.)
point-3) It was confirmed that the C.3.1 statement (cited in the Issue statement) applies to all designations and fact type forms. However, it is a guideline, which does not make any such cases in Annex E necessarily wrong.

Much of the recent discussion of "rule" and "actionable" have swirled around the use of "dictionary basis". I decided to have a look at what "dictionary basis" actually means in SBVR.

It's not defined in the normative part of the standard. It appears in Annex C (C.3.4), where the following description is given:

This caption labels a definition from a common dictionary that supports the use of the primary representation. The entry source reference (written in the ‘Source’ style described above) is supplied at the end of the quoted definition. A dictionary basis should not be interpreted as an adopted definition.

Have I missed a seeing a definition somewhere else? If not, perhaps we should include this term in the normative part of the standard so it can be given a tighter definition? Most other captioned items have SBVR definitions. It's obviously a source of some confusion.

The above definition clearly indicates "not interpreted as an adopted definition." I had always thought dictionary basis "informs" a definition ... provides background, source ideas and insight ... but does not in and of inside need to be complete. Wouldn't it be the case that several definitions need to be aggregated to form a complete picture (basis)?

Anyway, it had never occurred to me this might be a problem until the recent discussions. Does it need to be raised as an issue?

closed , no change

"Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' – (the way many of the SBVR concepts are defined). 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning.

This Issue is too big to resolve in one piece. It has been broken into manageable pieces as, and replaced by, Issues 10571, 10572,, 10573, 10574, 10575, 10576

The dictionary basis of ‘body of shared meanings’ is the dictionary definition of ‘universal set’, which is way off track and can only produce confusion. No body of shared meanings is the universal set.

Since ‘body of shared meanings’ is defined with respect to “a given semantic community”, why isn’t it a ‘role’. A set of concepts and guidance that is a body of shared meanings of one community is not necessarily a body of shared meanings for another community, but it is still a set of concepts and guidance.

Either the second necessity listed under ‘semantic community understands body of shared meanings’ is incorrect or there needs to be a definition of that fact type that gives a particular meaning of “understands” that is different from normal usage. The contradiction is seen in a simple example. Assume a semantic community EU-Rent has a subcommunity EU-Rent Mechanics. EU-Rent Mechanics’ body of shared meanings includes everything in EU-Rent’s and more. Both EU-Rent and EU-Rent Mechanics understand the body of shared meanings that is understood by EU-Rent, which contradicts the necessity that “Each body of shared meaning [sic] is understood by exactly one semantic community”.

I suspect that the necessity is what is intended and that making ‘body of shared meanings’ a role and simply using the verb “has” rather than “understands” will clear things up.

Remove the Dictionary Basis under 'body of shared meanings'.
Replace 'semantic community understands body of shared meanings' with 'body of shared meanings unites semantic community' and add a note.

Page 103 of SBVR says ‘fact’ is “logical formulation that is taken as true…”, but a fact is a proposition and a logical formulation is not a proposition

Change the entry for "fact" in the table on page 103

Pg. 209, C.5 uses “Clarification Statement”, which is an out-of-date signifier left over from an earlier SBVR submission.

C.5, page 209, change “<Rule Statement or Clarification Statement>” to “<Guidance Statement>”.

C.5.1, page 209, change the section title from “Rule Statement or Clarification Statement” to “Guidance Statement”. And then change the beginning of the paragraph from “rule statement or clarification statement” to “guidance statement”.

C.5.2, page 209, change “rule or clarification.” to “element of guidance”.

see above

The XMI has some internal inconsistencies. For example, it references type "proposition" but does not define that type.

The documents referenced in this Issue were removed from the SBVR Specification by the resolution of Issue 9930. The much smaller number of supporting documents for the new version of SBVR Use of MOF are being supplied. There are no known inconsistencies in the new documents.

The XMI in bei/05-08-02 provides no means of representing many vocabulary and rules aspects shown in the specification and the EU-Rent example:

• Concept Type, Guidance Type
• Synonym, Synonymous Form
• Note, Example
• Necessity, Possibility

Resolved by the resolution to Issue 9930.

Chapter 15 promises various supporting documents. The latest I can find (in bei/05-08-02) are out-of-date with respect to the current draft. Others don't exist at all.

The documents called for in this Issue were removed from the SBVR Specification by the resolution of Issue 9930. The much smaller number of supporting documents for the new version of SBVR Use of MOF are being supplied.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 8.1.2 and 9.1.1, modal formulation
Pages: 101
Nature: Editorial
Severity: minor

Description:

In 8.1.2, 'obligation' is defined as follows:
"Definition: proposition that is required to be true, that is obligatory, that is not permitted to be false"

And 'permission', 'necessity' and 'possibility' are similar.

The problem is that an obligation is not a proposition that is required to be true. It is rather a proposition that requires another proposition be true.

Example:
"It is an obligation that every rental car has a scheduled service."
The proposition
'Every rental car has a scheduled service'
is what the obligation requires to be true. But that proposition itself is not an obligation. It is just a statement, like "all roads lead to Rome".

The 'obligation' is:
"It is an obligation that every rental car has a scheduled service."
or equivalently:
"Every rental car is required to have a scheduled service."
which is a different proposition.

The obligation itself is a proposition that (per the definition of 'proposition') can be true or false – that 'obligation' may or may not actually be a rule at UDriveIt.

The Note under the glossary entry for 'modal formulation' has this same error. It says:
"The meaning of a modal formulation is the proposition that the proposition meant by the embedded logical formulation is an instance of the modality claimed by the modal formulation."

I read this to say that the meaning of
"It is an obligation that every rental car has a scheduled service."
is the proposition:
"(The proposition) 'every rental car has a scheduled service' is
an (instance of) obligation."
This is incorrect. As above, the embedded proposition 'every rental car has a scheduled service' is not an obligation. The obligation is the meaning of the modal formulation itself.

That is, the meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation.

Recommendation:

In 8.1.2,

a. change the definition of 'necessity' to
"proposition that another proposition is necessarily true, always true"

b. In the definition of 'possibility', after "proposition that" insert "another proposition"

c. In the definition of 'obligation', after "proposition that" insert "another proposition"

d. In the definition of 'permissiblity', after "proposition that" insert "another proposition"

In 9.1.1,

a. Replace the text of the Note under 'modal formulation' with:
"The meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation."

b. Under the entry for 'modal formulation claims modality', add a note:
Note: The meaning of 'modal formulation claims modality' is that the proposition meant by the modal formulation is an instance of the concept that corresponds to the modality.

DUPLICATE OF ISSUE 9721

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.10
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.10, there are several problems with the specification of 'question nominalization'

"Definition: projecting formulation of a referent question being formulated by a particular projection"

No modeled property of a question nominalization refers to a question. Change to:
"noun concept that refers to all questions whose structure of meaning is formulated by a given projection"

'question nominalization' is not a logical formulation kind; it is a projecting formulation kind, if that has any significance.

The reference scheme cannot be the bindable target, unless a question nominalization is unique to its occurrence instead of its content. In general, the reference scheme for a question nominalization should be that of the projection, plus any attached bindings.

Replace the Note text with:
For a closed projection, the projection formulates exactly one question.
Otherwise, the projection formulates one question for each possible substitution of a referent for each free variable in the projection. The question normalization may include a set of bindings for the free variables that constrain the possible substitutions.

Replace the Example text with:
In the statement, “An agent must ask each new customer what kind of car the customer wants”,
an atomic formulation based on a fact type ‘agent:person asks customer:person question’ binds to three
variables, one for each role. The variable bound from the ‘question’ role binds to the question nominalization for a projection formulating “'kind of car' such that 'customer' wants 'kind of car'". Because the variable for ‘customer’ is free within the projection, the question nominalization would refer to one such question for each possible 'customer'. So the question nominalization must include a binding that binds 'customer' in the projection to 'customer' in the atomic formulation that includes the question.

A question nominalization should have zero or more bindings instead of one bindable target. It can have one binding for each free variable in the projection.

In 9.1.1.10, 'answer nominalization' has many of the same problems.

It is difficult from the definition to determine the intent. The example suggests that the intent is:
Definition: noun concept that refers to all noun concepts whose structure of meaning is formulated by a given projection (i.e. whose structure of meaning is a noun concept formulation)

It is not a logical formulation kind; it is a projecting formulation kind, if that has any significance.

The reference scheme should be that of the projection, together with any bindings.

Like question nominalization (above), add bindings and modify the Note and Example similarly.

see above

ISSUE: Rationalize 'Representation' and Support 'Cocnept'/'Object' Distinction 1. Remove duplication and unnecessary Complexity between Clause 8.3 and 11.2, especially the relationship between Namespace and Speech Community & Symbol Context 2. Add the distinction from ISO of verbal (linguistic) and non-verbal (but still text) representations. 3. Align subcategories of 'representation' with ISO terminology community SEE: a. Terminology Summer School 2006 slides - ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/TSS2006%20Verbal%20and%20Non-Verbal%20Representations.doc b. ISO 12620 Annex A.5 (Normative) Concept Related Description 4. Create a table show which types of representation go with which major categories of 'thing' (see related Issue).

NOTE: The ISO 639-6 Language Codes standard currently being developed is creating a registry for language dialects right down to the work group level within an organization. This registry will be able to be used as a registry for each speech community (and its dialect).

The resolution to Issue 9952 covers the verbal distinction point of this issue (number 2) because it has 'term' and 'name' as verbal designations, and then adds nonverbal designation following ISO-1087-1's lead.
1. Remove 'symbol' and replace all references to it with 'designation'.
2. Remove or change the fact types 'symbol' participates in.
3. Add 'subject field' as an adopted concept from ISO 1087-1.
4. Relate 'symbol context' and 'subject field' to representations and vocabulary namespaces.
5. Add 'nonverbal designation' and have 'icon' specialize it.
6. Correct the discussion of "Qualifier" in Annex C to discuss "subject field" (in place of "subject context").
7. Relate a subject field to a vocabulary (as is implied by ISO 1087-1's definition of vocabulary).

Logical Formulation Kinds of Quantifications

In 9.1.1.7, page 57, under “existential quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an existential quantification is the concept ‘at-least-n quantification’.

In 9.1.1.7, page 59, under “at-most-one quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an at-most-one quantification is the concept ‘at-most-n quantification’.

In 9.1.1.7, page 59, under “exactly-one quantification”, the Concept Type paragraph should be removed. The logical formulation kind for an exactly-one quantification is the concept ‘exactly-n quantification’.

Remove the Concept Type paragraphs as stated above

In 11.1.1.3, page 113, the reference scheme for ‘vocabulary’ is “a URI of the vocabulary”, but there is no fact type ‘vocabulary has URI’ to support the reference scheme.

Add the fact type 'vocabulary has URI'.

SBVR talks a great deal about propositions and particular types of propositions, such as facts and rules, but never defines what it means for a proposition to be true or false. Understanding these characteristics of propositions is essential to understanding semantic formulations and other parts of SBVR.

Recommendation:

In section 8.1.2, page 19, add the following entries after the entry for ‘proposition’.

proposition is true

Definition: the proposition corresponds to an actuality

proposition is false

Definition: the proposition does not correspond to an actuality

see above

E.1.4 example 2 and also the 2nd rule in E.2.2.2.7 use " rental has duration"

The correct fact type at E.2.2.1.5 is "rental has rental duration". Probably E.2.2.1.5 should be changed, plus the reference in E.2.2.2.3.

E.1.4 example 3 and numerous other places use "rental has driver".

The fact type "rental has driver" seems to be missing entirely, though cited at E.1.4 and elsewhere. Suggest adding it to E.2.2.1.11.

This also affects rules (e.g. in E.2.2.4) that depend upon "rental has primary driver" and "rental has additional driver".

And it affects E2.2.2.10 rule 4 that depends upon "rental has additional driver".

E.1.4 example 4 and several other places use "branch has drop-off location"

E.2.2.1.9 has "rental uses drop-off location". Maybe it should be marked as an "is-part-of fact type" or given a synonym "branch has drop-off location"

E.1.4 example 5 and several other places use "rental has rental charge"

"rental charge" is given in E.2.2.1.7 but not "rental has rental charge"

E.1.4 example 6 and E.2.2.2.3 rule 1 use "rental has estimated rental charge"

"estimated rental charge" is given in E.2.2.1.7 but not "rental has estimated rental charge"

Also, these two rules elide "of a rental" from "... an estimated rental charge [of a rental] is provisionally charged ...." Maybe that's ok since there is no
other kind of estimated rental charge, but if so the spec should say that somewhere.

E.1.4 example 6 and several other places use "rental has renter"

"rental has renter" presumably belongs in E.2.2.1.11
E.1.4 example 7 uses "branch is included in local area"

Question: "branch is included in local area" is a partitive fact type. Is that what makes "local area of branch" a legitimate usage?

E.1.4 example 7 uses "rental has rented car"

"rental has rented car" is missing from the list of Supporting Fact types, but see below about it.

E.1.4 examples 7 & 8 and various other places use "rental has rented car"

"rental has rented car" presumably belongs in E.2.2.1.5, but according to figure E-7 it is the renter, not the rental, that has the rented card

E.2.2.2.2 rule 2 uses "rental has rental period"

"rental has rental period" presumably belongs in E.2.2.1.5, maybe as a synonymous form of "rental includes rental period "

E.2.2.2.3 rule 4 and elsewhere use "cash rental has lowest rental price"

"cash rental has lowest rental price" presumably belongs in E.2.2.1.7, maybe as a synonymous form of "cash rental honors lowest rental price"

Also, this fact type is not listed in "Supported Fact Types".

E.2.2.2.3 rule 6 uses "rental has car group"

the correct fact type is "rental has requested car group"

E,2.2.2.5 rule 1 uses "rented car" in the rule but "local area owns rental car" in the Supporting Fact Types.

E.2.2.2.8 rule 1 uses "rental car has scheduled service"
... which probably belongs in E.2.2.1.10

E.2.2.2.14 rule 1 uses "rental has base rental price"
... which probably belongs in E.2.2.1.7

E.2.2.2.15 rule 1 uses "operating company has insurer"

"insurer" appears in Figure E.5 but is not defined anywhere, much less "operating company has insurer". Both belong in E.2.2.1.3.

E.1.4 example 2 and also the 2nd rule in E.2.2.2.7 use " rental has duration"
The correct fact type at E.2.2.1.5 is "rental has rental duration". Probably E.2.2.1.5 should be changed, plus the reference in E.2.2.2.3.
corrected in Issues 9449 and 9450
E.1.4 example 3 and numerous other places use "rental has driver".
The fact type "rental has driver" seems to be missing entirely, though cited at E.1.4 and elsewhere. Suggest adding it to E.2.2.1.11.
This also affects rules (e.g. in E.2.2.4) that depend upon "rental has primary driver" and "rental has additional driver".
And it affects E2.2.2.10 rule 4 that depends upon "rental has additional driver".
corrected in Issues 9449 and 9450
E.1.4 example 4 and several other places use "branch has drop-off location"
E.2.2.1.9 has "rental uses drop-off location". Maybe it should be marked as an "is-part-of fact type" or given a synonym "branch has drop-off location"
corrected in Issue 9449
E.1.4 example 5 and several other places use "rental has rental charge"
"rental charge" is given in E.2.2.1.7 but not "rental has rental charge"
corrected in Issue 9449
E.1.4 example 6 and E.2.2.2.3 rule 1 use "rental has estimated rental charge"
"estimated rental charge" is given in E.2.2.1.7 but not "rental has estimated rental charge"
Because 'estimated rental charge' is a kind of 'rental charge' it is valid to use the verb from the fact type that reflects the more general concept.
Also, these two rules elide "of a rental" from "... an estimated rental charge [of a rental] is provisionally charged ...." Maybe that's ok since there is no
other kind of estimated rental charge, but if so the spec should say that somewhere.
The fact type 'estimated rental charge is provisionally charged to credit card' is part of the vocabulary.
E.1.4 example 6 and several other places use "rental has renter"
"rental has renter" presumably belongs in E.2.2.1.11
corrected in Issue 9449
E.1.4 example 7 uses "branch is included in local area"
Question: "branch is included in local area" is a partitive fact type. Is that what makes "local area of branch" a legitimate usage?
corrected in Issue 9449
E.1.4 example 7 uses "rental has rented car"
"rental has rented car" is missing from the list of Supporting Fact types, but see below about it.
E.1.4 examples 7 & 8 and various other places use "rental has rented car"
"rental has rented car" presumably belongs in E.2.2.1.5, but according to figure E-7 it is the renter, not the rental, that has the rented card
corrected in Issue 9449
E.2.2.2.2 rule 2 uses "rental has rental period"
"rental has rental period" presumably belongs in E.2.2.1.5, maybe as a synonymous form of "rental includes rental period "
corrected in Issue 9449
E.2.2.2.3 rule 4 and elsewhere use "cash rental has lowest rental price"
"cash rental has lowest rental price" presumably belongs in E.2.2.1.7, maybe as a synonymous form of "cash rental honors lowest rental price"
Also, this fact type is not listed in "Supported Fact Types".
No change (beyond the scope of a simple fix, due to nature of the extended discussion in E.2.2.2.3 that this is part of). Defer to resolution in Issue 10628.
E.2.2.2.3 rule 6 uses "rental has car group"
the correct fact type is "rental has requested car group"
corrected in Issue 9449
E.2.2.2.5 rule 1 uses "rented car" in the rule but "local area owns rental car" in the Supporting Fact Types.
Not a problem. ('rented car' is a role of 'rental car' in the situation of a rental. The ownership fact type is correctly shown using 'rental car'.)
E.2.2.2.8 rule 1 uses "rental car has scheduled service"
... which probably belongs in E.2.2.1.10
See below.
E.2.2.2.14 rule 1 uses "rental has base rental price"
... which probably belongs in E.2.2.1.7
See below.
E.2.2.2.15 [actually, E.2.2.2.11.4] rule 1 uses "operating company has insurer"
"insurer" appears in Figure E.5 but is not defined anywhere, much less "operating company has insurer". Both belong in E.2.2.1.3.
See below.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.10
Pages:
Nature: Editorial
Severity: minor

Description:

There are several kinds of questions:

• those that ask for confirmation/denial of a proposition (whether),
• those that ask for the identification of an individual or set of things (who, what, where, when),
• those that ask for a reason or a proof (why).

In 9.1.1.10, 'question nominalization', SBVR only addresses the second. It should also address the first, and there is no reason why it could not also address the third.

Confirmation/denial (whether) questions look like proposition nominalizations, except that their meaning is a question.

Rationalization (why) questions look like proposition nominalizations, but they assert the proposition and have the meaning of asking for the rationalization for that state of affairs.

So both of these could be accomplished by subtypes of proposition nominalization that have the same structure but different meaning. And the assertion nominalization is the current kind of proposition nominalization.

see above

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.10
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.10, there are several problems with 'proposition nominalization'

Definition: logical formulation that a referent proposition is formulated by a particular logical formulation

What can refer to a proposition? A proposition nominalization is a noun concept, one that refers to a structure of meaning (a logical formulation) as a thing separate from its meaning. The concept is not itself a logical formulation.
Change the definition to:
"noun concept referring to all propositions for which a given 'logical formulation' is the structure of meaning"

Add Note:
When the formulation contains free variables, the noun concept corresponds to a collection of such structures of meaning, one for each possible substitution for the free variables. That collection may not be a finite set. For each possible binding of those variables to constants, the result is a particular closed formulation that corresponds to a proposition.

In Example (1), 2nd sentence: "The variable bound from the ‘proposition’ role is also the
bindable target of a proposition nominalization that considers a logical formulation
formulating “EU-Rent accepts no checks”."
replace "is also the bindable target of a proposition normalization" with
"is bound in the atomic formulation to a constant proposition normalization"

Replace the text of Example(2) with:
In the statement, “An agent must tell each new customer that the customer cannot use a check”,
an atomic formulation based on a fact type ‘agent:person tells customer:person proposition’ binds to three
variables, one for each role. The variable bound from the ‘customer’ role is also the
bindable target of a proposition nominalization that considers a logical formulation
formulating “customer:person cannot use a check”.
Because the variable for ‘customer’ is free within the proposition nominalization, the proposition nominalization corresponds to a set of propositions, one for each possible referent of 'customer', and the variable in the atomic formulation that is bound to 'proposition' ranges over that set. But in each fact that satisfies the atomic formulation, the referent for 'customer' in "agent tells customer proposition" and the referent for 'customer' in the referent for 'proposition' have to be the same.

In the entry for 'proposition nominalization considers logical formulation'
Definition: the proposition nominalization is based on the logical formulation
should be:
Definition: the proposition nominalization represents all propositions for which the 'logical formulation' is the structure of meaning.

In the entry for 'proposition nominalization binds to bindable target'
Definition: the bindable target indicates the referent proposition identified by the proposition
nominalization
No. The proposition nominalization may have associated variable bindings. The variables must be free in the logical formulation considered by the proposition nominalization, but may be bound in a reference to the proposition nominalization (to constrain the set), and must all be bound in order to select an individual proposition.

see above

The SBVR specification defines a metamodel that is not a MOF metamodel and then defines a transformation from the SBVR metamodel to a MOF metamodel for rules defined in the SBVR metamodel. This means that modeling based on MOF does not have all of the capabilities (e.g., reflective definition of vocabulary) of the SBVR model, and that MOF technologies (e.g. QVT) cannot be applied to the SBVR metamodel. Furthermore, this means that aspects of the SBVR metamodel cannot be integrated into other metamodel specifications so that, for example, business vocabularies (multiple) and business rules mught be specified for an organization structure model or a business process model.

Noun concepts are represented, in MOF terms, as classes, unary fact types as Boolean attributes, binary fact types as associations, and ternary fact types as classes. To be completely straightforward, this direct correspondence from SBVR meanings to MOF model elements requires two semantic modeling capabilities that are not in MOF 2, but which could soon be supported through a new initiative, Semantic MOF (SMOF). The two capabilities are support for multiclassification and for the open world assumption. Workarounds make the direct correspondence workable in the absence of SMOF as follows:
1. Multiclassification: When a thing is categorized in multiple ways such that it instantiates two or more MOF classes, neither class specializing the other, the thing is represented in MOF by multiple MOF objects which are linked together using an association to indicate that the multiple MOF objects represent a single thing (this approach to multiclassification is allegedly also being used in for ADM).
2. Open World Assumption: The open world assumption is that representation of facts in a model does not imply that those are the only facts of a particular type nor that they are the only facts of a particular type about a subject thing - there are no implications to be taken from what is unstated. MOF supports this open world assumption about instantiation of classifiers (classes and associations), but MOF's attributes support only representation of an entire extension of an attribute with respect to a given subject. In order to enable a clear distinction in a MOF context between individual facts and complete extensions, association links are used to represent individual facts of a fact type while attributes are used when identifying a complete extension of a fact type with respect to a particular subject. This means that a fact can in one model be represented using a link, and in another as a value of an attribute of an object.
The two workarounds, however clumsy, are used because they enable a direct use of MOF. It is anticipated that an acceptable SMOF will directly support multiclassification and the open world assumption, both of which are supported by RDF and OWL, and that SMOF will remove the need for the workarounds in the future.
Changes to the SBVR specification are summarized as follows:
1. Clause 5 explains that the MOF interpretation of the figures is explained in clause 13 (SBVR Metamodel).
2. The caption under each figure in the normative clauses 7 through 12 which says the figures are nonnormative is changed.
3. Clause 13 is entirely replaced by an explanation of the MOF interpretation of the vocabulary entries and figures, and of the direct semantic correlation of the SBVR vocabularies with the MOF-based SBVR Metamodel.
4. Annexes K and L are removed (they are no longer relevant).
5. Some fact type forms are added for existing fact types as needed where MOF attributes are required in order to indicate a complete extension of a binary fact type for a particular subject, especially where required by reference schemes.
6. Three signifiers that use characters (">", "<", "&") that do not work in an xmi:id are removed or replaced.
7. The use of xmi:id values in SBVR Metamodel documents is explained in clause 15 such that it supports URIs that refer to SBVR designations and fact type forms.
8. The use of square brackets around placeholders in UML figures is replaced by underlining so that the brackets are not thought to be part of an association's name.
The specific changes below assume that clause 2 will be corrected separately by the resolution to Issue 9957.

In 13.1.1, page 148, under “text is for placeholder”, there is the following:

Example: The placeholder ‘Note that a text is normalized to have no leading
or trailing spaces and no other white space than single spaces.

An editing error seems to have deleted whatever was supposed to be most of the example and has pulled in what is clearly a Note.

Recommendation:

Complete the example and show the note as a Note paragraph.

add 2nd example using subscripts and explain that they are not part of the form.

see above

Is a representation an actuality?

Remarks often made by people involved in SBVR have indicated that a representation is an actuality – an objectification of the portrayal of a meaning by an expression. This same generalization applies to all of the specializations of ‘representation’ such as ‘designation’, ‘definition’ and ‘symbol’. But SBVR does not define ‘representation’ this way.

Recommendation: Change the definition of ‘representation’ from “portrayal of a meaning by an expression” to “actuality that an expression portrays a meaning”. Alternatively, add a General Concept paragraph under ‘representation’ that identifies ‘actuality’ as a more general concept.

Add a new fact type: "expression represents meaning". Make 'representation' an objectification of it.

‘meaning has representation’

There places in the document such as in the definition of ‘symbol’ in 11.2.1.1 that assume there is a form of expression ‘meaning has representation’ given as a synonymous form of ‘representation represents meaning’. But that synonymous form is not given.

Recommendation: Add the synonymous form ‘meaning has representation’ and show it in Figure 8.3. In the definitions of ‘designation’, ‘definition’, ‘statement’, ‘form of expression’ and ‘placeholder’, put the “of a” after the word “representation” in styled text as is done in the definition of ‘symbol’.

see above

Concept Expression versus Meaning Expression

The following fact types in 11.2.2.2 and 11.2.2.3 relate to concepts:

concept is portrayed by description

concept is illustrated by descriptive example

concept is commented on in note

concept is supported by reference

All of these relationships should be generalized to relate to ‘meaning’ rather than to ‘concept’. As it is, SBVR does not support having a description, descriptive example, note or reference for a business rule because a business rule is another kind of meaning (a proposition rather than a concept).

Recommendation: replace the fact types above with these:

meaning is portrayed by description

meaning is illustrated by descriptive example

meaning is commented on in note

meaning is supported by reference

see above

role has role binding’

Figure 9.4 shows a fact type ‘role has role binding’, but the normative text has ‘role binding is of role’. By the rules of SBVR Structured English (and normal English), ‘role has role binding’ implies that we can use ‘role binding is of role’, but not the other way around. All of the current usage within the document appears to use “is of”, not “has”.

Either change Figure 9.4 to show ‘role binding is of role’ (not ‘role has role binding’) or else change the entry ‘role binding is of role’ in the normative text to ‘role has role binding’.

see above

Bug in Namespaces Diagram

In Figure 8.5, page 27, to properly match the normative text, the box marked “URI” should say “text” and the “also: uniform resource identifier” should be moved out of the box and added to the “URI” association end.

Fix Figure 8.5 to match the normative text

In SBVR clause 8.1.1, the fact type 'concept1' specializes 'concept2' is defined. What are 'concept1' and 'concept2'?

They seem to be roles. But the necessity in the definition of 'role' in the same section – a role is in at most one fact-type – would then disallow the use of 'concept1' in any other fact-type, and the very next fact type glossary entry is 'concept1' is coextensive with 'concept2'. So they aren't roles, by the principles of definition. What are they?

Resolved by the resolution of Issue 9257

In SBVR 10.3.4 on page 107, there is a comment on ‘thing’ talking about its “current definition” as if the definition is about to change.

Recommendation: Remove the word “current” from the comment.

Remove the word "current" from the comment

ISSUE: SBVR Structured English is Inadequate to Enable the Full Specification of SBVR in Terms of SBVR Fully specifying SBVR in terms of SBVR was a fundamental design objective and the basis for the expression of the SBVR metamodel. 1. Need a table to show how every SBVR metamodel construct can be expressed by SBVR Structured English. 2. Need to add SBVR Structured English Capability where the table shows it to be missing.

A mapping from SBVR Structured English to XMI based on the SBVR Metamodel is added to Clause 13.

Precise Differentiation of Structural Rule vs. Operative Rule in RuleSpeak section. (1) Change the sentence that reads "If not followed (applied) in creating a booking, the booking is simply invalid." to "If not followed (applied) in attempting to make a booking, no booking results." (2) Change the sentence that currently reads "In borderline cases, RuleSpeak best practice is the following:" to "Refer to the RuleSpeak best practices presented in [Ross2005]." Retain the fotnote (7). Delete the boxed item entirely. (The use of "should" is too confusing without additional explanation.)

Revise two sentences and delete a small section of text

Fac Type: "concept1 specializes concept2"

This definition of this fact type includes the following example:

"The role ‘sum’ specializes the noun concept ‘number’, the differentiator being that each sum is the result of adding up a set of numbers. It turns out that every number is a sum of that number added to zero, so the extensions of the concepts ‘sum’ and ‘number’ are always the same."

Issue on: "the extensions of the concepts ‘sum’ and ‘number’ are always the same"
The extension of a role is not a set of things but a set of involvement of things. In extension of sum example, it is not a set of numbers but a set of an involvement of numbers
3 + 2 = 4 implies that 4 is involved in sum with an involvement of 3 and an involvement of 2
2 + 2 = 4 implies that 4 is involved in sum with an involvement of 2 and an other involvement of 2
Therefore, the extension of the "sum" role is:

.

In version 6 of the SBVR specification, fact-type role was changed to "role", which is now a direct specialization of "concept". To express what concept can range over a role (play the role), the only available mechanism is concept specialization. Hence the example provided by Don:
wife
General Concept: woman

Concept Type: role

We should be able to specify the role of "wife" in the context of marriage with husband without specializing it from woman or even from person.
We should then be able to define the range of concepts to which the wife and husband roles can be applied: "woman/men", "female/male" or in a Disney movie, like Robin Hood, "animals".
I don't see the value of being forced to go to the hierarchy of concepts (specialization) has a fact-type between role and noun-concept.

Previously, a fact type role was an object type. But it is the nature of object types that two object types that incorporate the same characteristics are the same object type. Roles of fact types do not have this property. A role of a fact type is intrinsically tied to a point of involvement in a fact type, and in the case of invertible fact types like 'thing is thing' and 'person is married to person', and in some other cases, two fact type roles can incorporate the same characteristics, or a fact type role can incorporate the same characteristic as an object type. Also, an individual concept is not an object type because it includes the sense of there being one instance.
The resolution of this issue makes the following changes:
What was previously one concept termed 'noun concept' and 'object type' is split into two concepts. 'Noun concept' keeps its original definition, but 'object type' is changed to be a specialization of 'noun concept' that is intrinsically based only on incorporated characteristics and that excludes fact type roles. The necessity that was given for 'noun concept' goes with 'object type'. 'Fact type role' is then intrinsically tied to a point of involvement in a fact type such that its incorporated characteristics are those understood from the fact type.
'Object type' is then understood to be what ISO intended by its 'general concept' and is one specialization of 'noun concept', with 'individual concept' and 'fact type role' being two other specializations.
With these changes it is possible that a fact type role ranges over an object type that has exactly the same incorporated characteristics as the fact type role. For this reason, 'specializes' is not adequate to describe that relationship, so a "ranges over" fact type is added.
The extension of a role is the totality of objects to which the role corresponds (as defined by ISO 1087-1). E.g. the extension of a role 'husband' would be all of the husbands. However, Antoine is correct that is it not necessary that a role be defined to specialize any particular concept or to range over a particular single concept. A note is therefore added to explain that roles need not be so constrained. Also, the range of a role, if given at all, can be given as coming from many concepts (an anonymous union). Also, advices of possibility can be used to indicate concepts whose instances can fill roles.
The unresolved "role playing of thing in occurrence" and "involvement" have been submitted as two spin-off issues.

ISSUE: SBVR Uses the Signifier 'Vocabulary' with Multiple Meanings which Require Separate Concepts Some of the meanings for which the signifier, "vocabulary", is used are: 1. Synonyn for Body of Shared Concepts 2. Synonym for Body of Shared Meanings 3. "representational vocabulary" composed of representations for a Speech Community a. including only all concepts b. including all concepts + all rules 3. 'Representations' sepearate from naked meanings as in " we must talk about shared concepts and not shared vocabulary". 4. A packaging unit of less than a. all concept b. all concepts and all rules 5. A document containing any of the above

Make the informal glossary in clause 4 consistent with the definitions in clause 11. Change the uses of the signifier 'vocabulary' so that the signifier is used only for its meaning defined in Clause 11. Add a fact type relating a vocabulary namespace to a vocabulary. Combine the undefined fact types 'vocabulary includes symbol' and 'vocabulary includes fact type form' into one fact type and give it a definition.
Note that the term "Vocabulary" used in the title of the document, "Semantics of Business Vocabulary and Business Rules" is consistent with the defined meaning of "vocabulary". The document is about the semantics of the designations and fact type forms in used in business and of the rules stated using them.
Annex E needs some further changes to be done as part of the EU-Rent Clean-up issue. First, Figure E.2 shows use of an undefined fact type 'speech community creates vocabulary'. Secondly, E.2.1.2 should follow the patterns used in Clauses 7 through 12 in how it specifies and names its vocabularies (for anything listed that is intended to be a vocabulary). The term 'vocabulary' should not be used for anything intended to be a dictionary, glossary or book. The name of a vocabulary should refer to the vocabulary presented by the document or publication, not to the document or publication itself.

ISSUE: 'Role' has Multiple Meanings that Need to be Separate Concepts 1. Role in Situation 2. Role in Process 3. Role as part of the composition of a 'fact type' or 'fact' 4. Role bound to a group of 'fact types' These needs to be clearly defined and contrasted.

Add two specializations of 'role': 'fact type role' and 'situational role'.

Issue: Need to Check the Core Structures in the ISO Terminology Stnadards to Make Sure SBVR Builds on Them Correctly There may be some small adjustments needed to enable SBVR to build seemlessly on the ISO Terminology standards,, especially regarding 'term', 'subject field/area', and language. The concept adoption seems to be in good order.

ISO's definitions of "designation", "term" and "name" are used.
'placeholder' specializes 'designation'.

ISSUE: Work Needed to Clean Up Mapping to Formal Logics (Clause 10) 1. Clause 10.1.1 – Leave only formal logic 'interpretation' material a. Move term definitions currently in Clause 10.1.1 to Clause 10.1.2 b. Add term definitions from ISO 247xx to Clause 10.1.2 c. Add definitions for terms used in Clause 10.1.1 not in Clause 10.1.2 now or from steps 1a. or 1b. to Clause 10.1.2 d. Remove any remaining tutorial material not required to specifiy the interpretation of the formal logic grounding from Clause 10.1.1 2. Clause 10.1.2 – Complete / Minimal Formal Logic Vocabulary a. In addition to steps 1a., 1b., and 1c., - remove all terms in Clause 10.1.2 not needed for the mapping in Clause 10.2 (was Clause 10.3). - add terms needed for the mapping in Clause 10.2 (was Clause 10.3) 3. Clause 10.2 (was 10.3) – Clear Mapping from SBVR o Formal Logics a. Renuber Clause 10.3 to 10.2 by combining Clause 10.3 into Clause 10.2 b. Identify any SBVR Vocabulary entries that should be marked 'FL' but are not c. Verify that all SBVR Vocabulary entries marked 'FL' have an entry in the Clause 10.2 mapping, or remove the 'FL' from the SBVR Vocabulary entry. d. Remove mappings in Clause 10.2 that do not and should not have an 'FL' marking next to the corresponding SBVE Vocabulary entry. f. Revise the mapping information in Clause 10.2 to remove any ambiguity in the interpretation of each SBVR Vocabu;ary entry (with an 'FL') in terms of the formal logic vocabulary in Clause 10.1.2 as elaborated in Clause 10.1.1

1. Replace the all the tables and introductory text in Clause 10.3 with the new single integrated table mapping SBVR to ISO Common Logic (ISO 24707) and OWL and introductory text for it.
2. Add two supplemental Conformance Points: one for Restricted Higher Order Logic, and one for First Order Logic.
3. Create a spin-off Issue for items not resolved because of lack of time:
a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed
b. Remove tutorial material from Clause 10.1.1
c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO
4. Create a spin-off Issue for SBVR metamodel formal logic-based errors and omissions:
a. A reference scheme is needed for individual concept.
b. The entries in Clause 8.5 "Conceptual Schemas and Models" need to be corrected to agree with the first paragraphs of Clause 10.
c. In Clause 8.6 "Extensions" and other sections of Clauses 8-12 the definition of "corresponds to" in "meaning corresponds to thing" and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of "proposition corresponds to state of affairs" and " individual concept corresponds to thing" need to be clarified or added. How the relationship between concept and thing is different between the "use" and the "mention" of the concept needs to be made clear.
d. Thee reference scheme for individual concept needs to be fixed to include the "mention" of object types, roles, fact types, propositions and subcategories of them.
e. Definitions that cover all the uses of "individual" in Clauses 8-12 need to be added.
f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.
5. The resolution of this Issue also resolves Issues 9623 and 9707.

ISSUE: Clean Up 'Form of Expression' 1. Pick a better signifier that is less confusing e.g. 'Verb Concept Reading' 2. Fix definition and necessities

Change 'form of expression' to 'fact type form' throughout the SBVR specification.

ISSUE: Current SBVR Conformaance Clause Does Not Meet the Criteria for an OMG Specification The Conformance clause needs to be specified according to the follwoing rules from the OMG Specification tremplate: "The Conformance clause identifies which clauses of the specification are mandatory (or conditionally mandatory) and which are optional in order for an implementation to claim conformance to the specification. For conditionally mandatory clauses, the conditions must, of course, be specified. One side effect of this is that the clause numbering must be sufficiently fine grain to make it easy to distinguish between mandatory and optional clauses. It is for the writers of the specification to determine what material should be mandatory, conditionally mandatory, or optional for conformance. This is not easy. One way of summarising the difficulty is that it is probably impossible to define conformance such that the set of all conformant implementations is the same as the set of all useful implementations. However, you must try to ensure your conformance requirements means that all useful implementations are conformant, not that all conformant implementations are a subset of all useful implementations."

Revise the conformance clause to specify conformance of a document, conformance of a tool that creates a document, and conformance of a tool that processes a document.

ISSUE: BRT Decisions about Relationships & Necessities Among Community, Langugage, Vocabulary, Vocabulary Version Didn't Make it into the SBVR Specification Add these decisions based on flipchart documentation. (See tp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Vocabulary%20Decisions.doc)

Resolved by the resolution to Issue 9955

In Figure 9.12 on page 67 there is a small error. In order to agree with the normative text, the box at the upper right that says “fact type role” must be changed to say only “role”. The fact type being shown is “variable maps to role” from page 70.

Change the diagram to match the normative text

Issue name: “Admonition” and “Affirmation” are the same concept

Location: SBVR Section 12.1 Categories of Guidance

Issue:

“Admonition” and “Affirmation” are both elements of guidance that there is not a business rule where one might be expected (especially if members of the semantic community have been acting as if there were such a rule).

There is only one concept there, and “Admonition Statement” and “Affirmation Statement” are two different forms of representation for it.

Proposed Solution:

Replace “Admonition” and “Affirmation” by a single concept. The detail of the change may depend on the restructuring around “Directive” and “Guidance” that was discussed at the London face-to-face meeting.

Resolved by the resolution of Issue 9475

ISSUE: Better Term and Definition for 'Res' Change definition of 'res' to "thing that is not a meaning" and find a more common term for this concept. (see related Issue on Major Categories of Thing)

Recommendation: change the definition; retain the term.

: Representations of 'Objects' Belong in Vocabularies Indications of 'objects' by representations (that can be treated as existential assertions) need to be able to be included as entries in 'vocabularies' without having to form an'individual concept' about them. The original justification for omitting this capability "because ISO requires everything in a vocabulary (terminology) to be a concept" turns out to be based on a lack of knowledge about the ISO TC 37 position on this subject. In conjunction, 'definite' description' for 'objects' needs to be added to support statements that uniquely identify (not form or define a concept about) 'objects'. SEE: 1. InfoTerm – ISO Terminology TC 37 Secretariat - http://www.infoterm.info/standardization/basic_principles.php 2. Terminology Summer School 2006 Slides - ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/TSS2006%20Objects%20and%20Concepts.doc

Issue 9942 is resolved by the resolution of Issue 10790.

Location: SBVR Annex H

Issue: Is it legitimate in UML to have bidirectional association names with black triangles indicating direction, as in Figure H.4?

Resolution: none proposed as yet - need to have the question answered first.

No Data Available

Name: Definitions of 'projection'
Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1
Pages: 101
Nature: Revision/correction
Severity: Significant

Description:

9.1 defines 'semantic formulation' as: conceptual structure of meaning.

9.1.2 defines 'projection' as: semantic formulation that operates over one or more variables and results in a set or multiset.

How does a 'conceptual structure' 'operate' or 'result'? Structure is a static notion. A 'projection' must rather be a semantic formulation whose meaning is the SET – the conceptual structure – that results from applying a function to some collection of things.

The term 'multiset' is undefined, and does not have a NODE definition (it's IT jargon). In a formal model, a 'multiset' is either a set of pairs (thing, occurrence), each of which has a reference scheme, or a set of pairs (thing, count), for which thing has a reference scheme and count is a nonnegative integer. Whichever definition is chosen, if any, the conceptual structure of the projection is a SET. The only question is what it is a set of.

The example of a 'bag projection' indicates that the result is actually a set of pairs (balance, customer) and then says: "Only balances are in the result, but there can be duplicates where multiple customers have the same balance." This is true in SQL, but it has nothing to do with reality or logic. It can only be true in business if the result somehow carries the customer notion with the balance – a different line, a different position, a different memory cell – so that occurrences can be distinguished. In SQL, the result is a LIST of balances with distinguished positions, a SET of pairs (position, balance).

The projection (set) doesn't result from applying a function to 'variables', it results from applying the function to the things the variables range over.
So the concept 'variable ranges over concept' from 9.1.1 is critical to the meaning of a projection! (Note that much of the discussion of 'variables' in 9.1.1 is about projections and not about 'variables' in logical predicates.)

The projection is not 'on a variable'. A projection INTRODUCES a variable to denote the individual concepts in the range from which the result set will be extracted. The logical formulation that constrains the projection is called the 'selection criterion'. It involves the projection variable as a 'free variable'. Each individual concept for which the selection criterion holds appears in the result set.

In addition to projections, there are mathematical functions whose operands are sets and whose results are simple values, like 'average'. These should not be confused with projections. In the example "the average of ages of rental cars owned by each local area", the conceptual structure is a TABLE of cars with ages, created by the "projection"
TableOfAges =

over the projection
OwnedCars =

but the result of interest is the function
AverageOfColumn(TableOfAges, Age)
which is not a projection or anything the like.

If database Select and Project operations and arbitrary mathematical functions whose operands can be structures are all part of "semantic formulations", let us call a spade a spade. The relational database formulation of "semantics" is well understood, and we can use that. The current text for projections does not have any hope of capturing meaning.

Recommendation:

The real fix:
a. Define the 'relation' concept, and the cross product, select and project operations a la relational algebra. It is a perfectly usable form of "semantic formulation": "relational formulation"
b. Provide a concept for mathematical function that applies to arbitrary operands.

The minimal fix:
a. Correct the definition of projection, and decide on the model of projection (result) to be used.
b. Repair or delete the concepts bag projection and set projection according to the model chosen.
c. Correct the definitions of the relationships among the projection, the range variable(s), and the selection condition.
d. Eliminate 'auxiliary variable'. It is either a logical variable in the selection condition (logical formulation) or a (parallel) range variable depending on the model of projection results.
e. Remove the example about the average of ages of rental cars, and other such examples, whose formal representation is well out of the scope of SBVR.

Replace the definition of 'projection'. Split the fact type 'closed projection defines concept' into two fact types, one for noun concepts and the other for fact types, and explain them separately with examples.
Explain 'projection' with respect to its different uses. Move Necessity statements under 'closed projection' to be under fact types for the different uses. As a way of aiding the clarity of its uses, change the signifier of 'noun concept formalization' to 'noun concept nominalization' and reinstate 'fact type formulation' as 'fact type nominalization'.
Projections are related to meanings through the following fact types:
1. closed projection defines noun concept
2. closed projection defines fact type
3. close projection means question
The first two are fully explained and exemplified in this resolution. The third is already fully explained with an example.
Also, projections are used in the five types of projecting formulations. Each of those is already fully explained with examples except for 'fact type nominalization' which is explained with examples in this resolution. Note also, three of those five are correlated with the three relations to meaning listed above. The three are, respectively:
1. noun concept nominalization
2. fact type nominalization
3. question nominalization

SBVR’s definition of ‘body of shared guidance’ uses the word ‘guidance’ styled as a term. But no term ‘guidance’ is in the SBVR vocabularies. The word should either be unstyled or else replaced with the defined term ‘elements of guidance’.

Use the defined term 'element of guidance'

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.7
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.7, the model of quantification shows it to be a kind of logical formulation that MAY (0..1) scope over a logical formulation. A quantification has to "scope over" something. And it binds a variable in that something. The definition does not reflect this requirement.
Further, iIf a quantification doesn't 'scope over' a logical formulation, it isn't itself a logical formulation. A logical formulation represents a proposition that is true or false.

If necessary, define logical quantification with the well-defined properties and define some other kind of quantification for whatever else a quantification may "scope over".

Recommendation:

In the entry for 'quantification'
a. Modify the definition of quantification to read:
logical formulation that applies a logical quantification operator to a free variable in the logical formulation that the quantification scopes over.

b. Add a Note
Note: the variable must be free in the logical formulation scoped over. The quantification binds that variable in the resulting logical formulation.

c. Modify Necessity (3) to read:
Necessity: Each quantification scopes over exactly one logical formulation.
(Not "at most one".)

In the entry 'logical formulation restricts quantification', At the end of the Note, add:
The logical formulation represented by the quantification is logically equivalent to scoping over the conjunction of the logical formulation that restricts the logical quantification with the logical formulation it scopes over."

In the entry 'universal quantification', replace the text of Definition with:
quantification that is true if the logical formulation it scopes over is true for all admissible referents of the variable, and false in any other case.

In the entry 'existential quantification', replace the text of Definition with:
quantification that is true if the logical formulation it scopes over is true for any admissible referent(s) of the variable, and false only if it is true for no admissible referent.

Add Note: An existential quantification is equivalent to an at least n quantification where n=1.

Make the definitions of the different kinds of quantification more precise. Add notes for clarity.

In 8.1.2, 'obligation' is defined as follows:
"Definition: proposition that is required to be true, that is obligatory, that is not permitted to be false"

And 'permission', 'necessity' and 'possibility' are similar.

The problem is that an obligation is not a proposition that is required to be true. It is rather a proposition that requires another proposition be true.

Example:
"It is an obligation that every rental car has a scheduled service."
The proposition
'Every rental car has a scheduled service'
is what the obligation requires to be true. But that proposition itself is not an obligation. It is just a statement, like "all roads lead to Rome".

The 'obligation' is:
"It is an obligation that every rental car has a scheduled service."
or equivalently:
"Every rental car is required to have a scheduled service."
which is a different proposition.

The obligation itself is a proposition that (per the definition of 'proposition') can be true or false – that 'obligation' may or may not actually be a rule at UDriveIt.

The Note under the glossary entry for 'modal formulation' has this same error. It says:
"The meaning of a modal formulation is the proposition that the proposition meant by the embedded logical formulation is an instance of the modality claimed by the modal formulation."

I read this to say that the meaning of
"It is an obligation that every rental car has a scheduled service."
is the proposition:
"(The proposition) 'every rental car has a scheduled service' is
an (instance of) obligation."
This is incorrect. As above, the embedded proposition 'every rental car has a scheduled service' is not an obligation. The obligation is the meaning of the modal formulation itself.

That is, the meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation.

Recommendation:

In 8.1.2,

a. change the definition of 'necessity' to
"proposition that another proposition is necessarily true, always true"

b. In the definition of 'possibility', after "proposition that" insert "another proposition"

c. In the definition of 'obligation', after "proposition that" insert "another proposition"

d. In the definition of 'permissiblity', after "proposition that" insert "another proposition"

In 9.1.1,

a. Replace the text of the Note under 'modal formulation' with:
"The meaning of a modal formulation is the proposition resulting from interpreting the proposition meant by the embedded logical formulation under the modality claimed by the modal formulation."

b. Under the entry for 'modal formulation claims modality', add a note:
Note: The meaning of 'modal formulation claims modality' is that the proposition meant by the modal formulation is an instance of the concept that corresponds to the modality.

Remove 'modality' from chapter 8 - modal concepts are covered in chapter 10.
Replace the terms 'necessity', 'possibility', 'obligation' and 'permissibility' with characteristics that apply to propositions, and define them formally in such a way that the definitions invoke the appropriate modal formulations.
Change the definitions of 'modal formulation' and the concepts that specialize it to be stated in terms of possible or acceptable worlds. Change the designations of those concepts that end with the word "claim" to end with the word "formulation".
Add 'possible world', 'acceptable world' and 'Universe of Discourse' to the Formal Logic & Mathematics Vocabulary.
Some of the vocabulary items being replaced are used in examples. Change the examples to use other items.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1, 'logical formulation' is defined as:
"semantic formulation that is an abstract interpretation of a well-formed logical formula"

One may ask why it isn't just the expression as a wff. A Note to the effect that this is some kind of computational "abstract syntax" for a wff would help in putting this clause in perspective.

A 'closed logical formulation' has the property:
The meaning formulated by each closed logical formulation is a proposition.

It should be Noted that every kind of logical formulation can be closed by binding all of its free variables to constants. Consequently, it is important that every kind of 'logical formulation' specifies, for the case, in which it is closed, the circumstances under which the corresponding proposition is 'satisfied' or 'true', and those under which it is 'false'.

9.1.1.2 atomic formulation does not specify this.
9.1.1.3 instantiation formulation does not specify this.
9.1.1.4 modal formulation is a convenience concept, only its subtypes have meaning, and they do not specify it.
9.1.1.6 logical operation is a convenience concept, only its subtypes have meaning, and they do not specify it.
9.1.1.7 quantification is a convenience concept, only its subtypes have meaning, and they do not specify it.
9.1.1.8 objectification does not specify this.
9.1.1.9 projective formulation is a convenience concept, only its subtypes have meaning
aggregation formulation does specify this, but in a Note.
noun concept formulation does specify this, but in a Note.
fact type formulation does specify this, but in a Note.
proposition nominalization does specify this, but in a Note.
question nominalization does specify this, but in a Note.
answer nominalization does specify this, but in a Note.

Recommendation:

Add a Note to the glossary entry for 'closed logical formulation' that every kind of logical formulation can be closed by binding all of its free variables to constants, and thus formulates a proposition that is either true or false.

For each kind of logical formulation, specify the true/false/satisfaction behavior of the closed form in the normative/definitive text, e.g., the Definition, and not in a Note.

see above

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.9
Pages:
Nature: Editorial
Severity: minor

Description:

In clause 9.1.1.9, 'noun concept formulation', the definition is
"projecting formulation of a referent noun concept whose intension is formulated in a particular projection"

a. It is not clear in this definition what 'referent noun concept' is being referred to.
b. 'projecting formulation' as a GeneralConcept has no semantics. Use 'logical formulation'?
c. This apparently means that the noun concept is defined to be the set that is the projection, which is the extension, not the intension. (I suppose the intension is "is a member of that set".) The problem here is that while a projection has the form of an intensional definition, it has the semantics of an extensional definition. Perhaps the problem is that this use of the projection syntax does not have the same semantics as other uses.
d. This definition provides no indication as to the role of the bindable target (from 'projecting formulation'). The thing being defined is a noun concept – not a variable, although perhaps a constant – so the bindable target must enter into the definition, but the note says there is some "understood reference".
e. This definition is only a 'logical formulation' if the noun concept is treated as a classifying predicate, like an instantiation formulation. And in that case, the bindable target would be the thing whose referent is to be tested for membership in the projection set.
f. In the closed form, one possible interpretation of this construct is that it is a test for whether the bindable target is a member of the projection set. If that is the case, it would certainly be helpful to the reader to say exactly that, at least in a Note.
g. One possible 'open form' would apparently define a function of the bindable target whose result is the closed projection that corresponds to the substitution of the bindable target for the (sole?) free variable in the projection, but that is not a logical formulation in that its meaning is not a proposition.
h. Of itself, the open form does not define a noun concept. There must be a further requirement that all free variables in the projection are bound in the context in which the would-be noun concept is 'defined'. And what this means is that a noun concept formulation is only well-defined when it is closed by substitution. All of this should be part of the definition and not of some attached Note.
i. Another possible interpretation is that this really was intended to represent the definition of a term to refer to a noun concept defined by an intensional formulation. In that case, the 'bindable target' should be a constant (text?) whose referent is being defined, the noun concept formulation should introduce a single variable, and the intensional definiens should be a logical formulation with exactly one free variable, and that variable corresponds to the variable introduced. No projection ("set") is involved.

"Note: A noun concept formulation is satisfied for each referent that is a noun concept defined by the projection."
Whatever this was supposed to mean, it is wrong. A noun concept formulation is satisfied if the referent of the bindable target is actually in the set defined by the projection.

The Examples are strangely phrased. E.g. in the 2nd example, the noun concept formulation is: 'the distance that is the reading of the rental car's odometer', and anything that satisfies that formulation IS a distance, because 'distance' is the concept over which odometer-reading(?car) projects.
The 'distance concept' is in the formulation, but the referents are individual distances.

see above

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.8
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.8, Objectification: The intent here is completely obscure.

The example refers to a use that isn't at all clear. It appears to be two fact-types that are synonymous forms: 'car is assigned to rental' and 'car assignment of car to rental'.

If the intent is to construct a noun concept from a fact-type, the definition should say that, and the example should illustrate that. Alternatively, it is possible that an objectification is just a 'proposition nominalization' for an 'atomic formulation'.

see above

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.7
Pages:
Nature: Editorial
Severity: minor

Description:

General problems in clause 9.1.1.7:

a. Logical quantifications are intensive; they do not require the materialization of the set of satisfying instances. Cardinality quantifications are extensive; they require materialization of the set. It is not clear that the extensions of all SBVR concepts are sets, and it is clear that many of them cannot be materialized. In general, cardinality-based quantifications can only apply to projections.

Note: The intensive version of the "at most 1" quantification for a predicate P is a "uniqueness rule" (a Necessity): IF P AND P THEN x = y. So it is possible to specify "at most 1" and "exactly 1" quantification without using cardinalities.

b. Cardinality requires a notion of "equality" defined on the instances from which the set is drawn. Otherwise cardinality cannot be measured. SBVR appears to introduce this concept via Reference Schemes, but it does not do so explicitly in discussing cardinality.

c. The current definitions of the cardinality-based 'quantifications' (at least n, at most n, etc.) refer to undefined operations.

Other problems:

In what fact-type is Cardinality a role?
Cardinality is a property of a set, that is, a fact-type about a set, viz. 'set' has cardinality 'non-negative integer'.

The definitions of maximum and minimum cardinality are meaningless. These terms are roles in some unspecified fact types that make use of 'integer' is less than 'integer'.

Recommendation:

Before Cardinality, insert new section heading.

Change the definition of 'cardinality' to read:
non-negative integer designating the number of distinguished things in a collection

Specify the fact-types in which maximum and minimum cardinality are 'roles'. Or don't bother and specify cardinality quantifications as fact-types. E.g. at-most-n quantification:
X has at most n Ys
is interpreted:
for any given X, the cardinality of the projection = 'set of all Y such that X has Y' is-less-or-equal n
Note that such a construct IS a logical formulation, but it is NOT a "logical quantification".

Add the fact type 'set has cardinality'. Explain the relevance of distinguishability for quantifications other than universal and existential quantification.

The definitions of 'logical operator' and 'logical operand' are circular.
From 9.1.1
logical operator - logical formulation that operates on a logical operand
logical operand - logical formulation upon which a logical operation operates

Recommendation:

Redefine 'logical operator', e.g., to:
logical formulation whose meaning is derived from the meanings of one or more other logical formulations by a particular semantic relationship.

Replace the definition of 'logical operation'.

Section 12.1.2 defines "business rule" as a "rule that is under business jurisdiction". This is a key definition, yet it is not clear what "under business jurisdiction" really means. Presumably a law of physics is not "under business jurisdiction", hence is not a rule. How about a national or state law? How about a regulation? A standard or best practice?

Something like "All transactions must be archived for three years" seems like a rule. Say it starts as a rule created by a particular company for itself, hence is clearly a "business rule." Over time, it evolves to an industry standard and maybe a regulatory requirement. Has it morphed from a "business rule" to something else because it is no longer "under business jurisdiction?" What kind of rule is it once no longer "under business jurisdiction?"

Explanation in blue, indented
Section 12.1.2 defines "business rule" as a "rule that is under business jurisdiction". This is a key definition, yet it is not clear what "under business jurisdiction" really means.
It means that the semantic community, typically a business, governed by the rule can opt to change or discard the rule. See section A.2.3.
Presumably a law of physics is not "under business jurisdiction", hence is not a rule.
It's not a business rule.
How about a national or state law? How about a regulation? A standard or best practice?
These things are not business rules for businesses that have them imposed from outside. Such businesses will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.
Similarly, businesses will decide how to adopt standards or best practices, and will create business rules to ensure that they are implemented as intended.
Something like "All transactions must be archived for three years" seems like a rule. Say it starts as a rule created by a particular company for itself, hence is clearly a "business rule." Over time, it evolves to an industry standard and maybe a regulatory requirement. Has it morphed from a "business rule" to something else because it is no longer "under business jurisdiction?" What kind of rule is it once no longer "under business jurisdiction?"
If the company that created the business rule gives up its ownership, and no longer has authority to change it, then the artifact is no longer a business rule for that company. It's an externally owned regulation that is imposed on the company or an industry standard that can be adopted by the company.

Clause 10.3 says it is a mapping from "the selected subset of (important) SBVR business terms" to the formal logic terms in 10.1.2. It is not clear how these terms were selected. They are all drawn from clause 8 and 9, but they don't correspond to any defined vocabulary, and they are not complete with respect to clause 8 or 9. Those terms that are defined in Clause 9 should apparently be mapped in 10.2. Those coming from clause 8 should represent an organized set of concepts.

All of 8.1 is covered except for 'concept' and 'question'.
8.2 is not covered.
8.3 is not covered at all, except for 'statement'.
8.4 is covered, but the mapping is nonsense. Reference schemes have no counterpart in mathematical logic.
8.5 is covered.
8.6 is covered.
8.7 is covered.

9.1[only] is covered but the mapping is nonsense. A "semantic formulation" doesn't necessarily correspond to a logical proposition or predicate; it may be defined by the mathematics of sets or arithmetics or functions.
9.1.1 is covered, except for question nominalization and answer nominalization.
9.1.2 is covered in theory, but the mapping is nonsense. A projection is an operation on sets that has no logical result, although it may involve a logical formulation.

Many terms that are said to be adequately mapped by their supertypes in 10.3.3 are not, in that the subtype creates an importantly different mathematical logic interpretation.

And most of the subtypes of quantification defined in clause 9 have no image in mathematical logic. (Clause 10 would have to introduce set theory and model cardinality and basic arithmetic to support these.)

Recommendation:

a. Move and correct the mappings of terms defined in clause 9.1.1 from 10.3 into 10.2. (This may depend on other issues related to clause 9.1.1.)

b. Define the 'sub-vocabulary' of Clause 8 for which what remains in 10.3 defines a mapping, complete and correct the mapping of that vocabulary.

c. Delete the mappings for the terms from 9.1[only] or 9.1.2.

Resolved by the resolution to Issue 9959.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.9
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.9, 'fact type formulation' is defined as:
"projecting formulation of a referent fact type whose intension is formulated in a particular projection"

I don't know what this means. There is no referent fact type. If the formulation is closed, then it defines a fact-type. And there is no reference to the bindable target.

Is this intended to mean:
"definition of a fact type by a projection that formulates its intension"?
If that is the intent, the fact type formulation should have a referent (text?) constant, which is its name. And it introduces a set of variables corresponding to the roles of the fact type. And the intension is represented by a logical formulation in which each of those variables is free, and no other variable is free. Note that this description does not involve a projection, because there is no "set" involved. The definiens has the same syntactic structure as a projection (except that the bound variables are associated with the roles of the fact type and not with the projection per se), but the definiens means the logical formulation (the intension), while the projection means the "set" (of things that satisfies it – the extension).

If this is the intent, I would also say a fact-type formulation is not a 'logical formulation' in the usual sense – it is a definition, and cannot be substituted for 'logical formulation' in other uses.

Note also that the 'referent fact type' must be a constant, not a variable, and therefore not a 'bindable_target'. (If one allows the definition of variable fact types, it creates problems with the Henken semantics model in clause 10 – the fact types of a given SBVR model might not be enumerable.)

Now the above is all guesswork, because I don't understand the definition, and the example doesn't identify any part of it as the fact type formulation.

In the Example, the interpretation of "drinking and driving violates the rental agreement" is:
For any person such that p is-renter, IF p drinks AND p drives, THEN p violates-rental-agreement.
I don't see where any projection fits in here, except possibly for p is-renter.

In 9.1.1.10 'projection' (whose definition appears to be "some operation that results in a set"), the concept of formulating a fact type appears in the Note:
"A projection’s result can be taken in multiple ways. Which way depends on how the
projection is used. When used in an aggregating formulation or as defining a concept other
than a fact type, the result elements are simply the referents of the variable in the projection.
When used to define a fact type, each result element is taken as an actuality that involves the
referents of the variables in the projection."

This supports the idea above that 'projection' has more than one semantic interpretation, and the interpretations are only loosely consistent. And that means it fails as a "structure of meaning". It is a structure, but the meaning is imposed by something else.

Now, to define a fact type, the referents of the variables in the projection would have to be assigned to "roles", so the presumption must be that the different variables represent different roles. A "result element" must then be a tuple of referents, one for each variable, in which each 'position' corresponds to a role. Since no verb is associated with the tuple, such a tuple can be "taken as an actuality" only in the sense that the collection of referents in the tuple is related by satisfying the logical formulation that constrains the projection. But relating a variable that ranges over actualities (states of affairs) to such a tuple would be very difficult. You can only get the tuple by having a fact-type to interpret the actuality. (As Antoine says, a fact is an actuality interpreted by a fact-type.)

'Fact type formulation' appears to fill a theoretical hole in structuring meanings of natural language statements, but no good example of its use has been produced. Therefore, the resolution is to remove 'fact type formulation'.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1
Pages:
Nature: Editorial
Severity: minor

Description:

In clause 9.1.1, a 'bindable target', the thing to which a variable can be bound, is said to be either a variable (i.e. to its current referent) or to 'text'. 'text' is defined in 8.1.1 to have its conventional dictionary interpretation, which is inappropriate here. For a bindable target, the alternative to a variable is a 'constant' – a reference to a specific fixed individual concept (a 'name'). 'text' may be the physical expression of the reference.

And the first Example under the glossary item 'variable' appears to be a constant that has been transmogrified into some unnecessary doubletalk.

Recommendation:

1. In clause 9.1.1, after 'variable', add a glossary item for 'constant':

'constant'
Definition: a reference to a specific fixed individual concept (a 'name').

Necessity: the referent of a constant is exactly 1 individual concept.

Note: By definition, every constant is unitary.

Example:
Given the individual concept ‘London-Heathrow Branch’ defined as “the EU-Rent branch
located at London-Heathrow Airport”, the constant expressed as the name 'London-Heathrow Branch' refers to that EU-Rent branch in all occurrences.

2. In the definition of 'bindable target', replace all occurrences of 'text' with 'constant'.

A bindable target can be a variable, an expression (including a text) or an individual concept. The meaning of an individual constant is an individual concept. The resolutions to issues 9586 and 10570 clarify the distinction between binding to an expression and to an individual concept. The meaning of binding to an individual concept is explained - the binding references the one instance of the individual concept. In addition to the changes made in the resolutions to issues 9586 and 10570, an additional clarification is made in a note.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.9
Pages:
Nature: Editorial
Severity: minor

Description:

Recommendation:

In 9.1.1.9, the definition of 'aggregation formulation' is difficult to interpret. It seems to say it is an assertion of equality between two sets (or multisets), one of which is the value of a variable (bindable target?) and the other is the result of the projection. If that is what is intended, at least a Note should say this.

And in the Example about averages of ages, it is difficult to tell exactly what is supposed to be the 'aggregation formulation'. The model is:
AVERAGE( project car.age from car such that car is-owned-by b such that b is local-branch )
that is, a function of a projection that is based on a selection that is based on a selection. Which of these four operations is the aggregation formulation? But the logical formulation that is the rule has the form:
number is-less-than number
where the first number is the result of the 'average' function (which has no SBVR model I can find).

Provide a better definition of 'aggregation formulation'. Remove the note. Improve the example and give its full formulation.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1.9
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.1.1.9, the definition of 'projecting formulation' is obscure. How is 'a thing considered with respect to a projection' true or false. It might mean 'x occurs in the set resulting from projection y', but that wouldn't have 3 or 4 confusing subtypes. Or it might mean the set produced by a 'projection' (considered as some kind of function). It seems to be a supertype with no direct usage, e.g. 'semantic formulations that involve projections', and it models several relationships at a uselessly abstract level.

It is said to be a 'logical formulations', but with the possible exception of 'aggregation formulation', the subordinate concepts are not 'logical formulations'.

Recommendation:

Delete the concept 'projecting formulation'.

Add a note to the entry for 'projecting formulation'.

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 8.1.2
Pages: 19
Nature: Correction
Severity: minor

Description:

8.1.2 defines 'modality' (a pure mathematical logic concept) so that it can be the ConceptType for 'necessity', 'possibility', 'obligation' and 'permissibility'.

But in fact, 'necessity' is said to be a kind of 'fact', and the others are said to be 'propositions'. That is, the corresponding GeneralConcepts are not 'modality'. And they are not individual concepts, so they shouldn't have a ConceptType.

Recommendation:

a. Move the glossary entry for 'modality' to 9.1.1, or delete it if it is used nowhere else.

b. For 'necessity', replace "ConceptType: modality", with
"GeneralConcept: fact"

c. For 'possibility', 'obligation' and 'permissibility', replace
"ConceptType: modality",
with
"GeneralConcept: proposition"

Was a problem in interpreting SBVR Structured English. Not a problem with the specification. Close, no change

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1
Pages: 101
Nature: correction
Severity: minor

Description:

In the definition of 'variable' in 9.1.1, there are two Reference Schemes given for variables. The one for projection variables indicates that the scheme is a pair (projection, variable range concept).

In 9.1.2, the definition of 'projection position' says that it "distinguishes a variable", but it is not mentioned in the reference scheme in 9.1.1.

But 9.1.2 defines the 'projection position' to be the reference scheme for 'auxiliary variable'. Since an auxiliary variable could have the same range concept as the primary range variable for the projection, the reference scheme in 9.1.1 cannot be correct. The scheme given in 9.1.1 should be the same as that for auxiliary variable, and then it need not be restated for auxiliary variable.

Further, the reference scheme given for logical variables in 9.1.1 is:
"a quantification that introduces the variable and the set of each concept that is ranged over by the variable and whether the variable is unitary".

This is mostly unnecessary. The reference scheme is the quantification that introduces the variable, full stop. The scope of the quantification is the scope in which the variable refers to that one.

Now, since variables do not appear to be distinguished by type: logical variable vs. projection variable, it is difficult to manage incompatible reference schemes, when both kinds can appear in the logical formulation that is the selection criterion for a projection! So variables have to have either a common reference scheme or have distinguished subtypes with distinguished reference schemes.

Recommendation:

a. Define two subtypes of variable, 'logic variable' or 'quantified variable' in 9.1.1 and 'projection variable' (in lieu of 'auxiliary variable') in 9.1.2.

b. For the logic variable, the reference scheme should be: the quantification that introduces the variable.

c. For the projection variable, the reference scheme should be as given for 'auxiliary variable' in 9.1.2.

(I'm not sure this really solves the problem for parsing logical formulations that appear in projections.)

Clarify the use of reference schemes for semantic formulations in the introduction to Clause 9.
Fix the references schemes for 'variable' and 'auxiliary variable' so that they involve the complete structure (as is done for all parts of semantic formulations).

Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 8.1.2
Pages: 18
Nature: Editorial
Severity: minor

Description:

In 8.1.2, the definition of 'proposition' says:
"meaning that is asserted when a sentence is uttered or inscribed and which is true or false"

If the meaning is asserted when the sentence is uttered, the proposition is taken by the speaker to be true. Whether the meaning corresponds to the actual 'state of affairs' determines whether it is true or false, and even then not when the sentence is in the future tense. I think the intent here is: "meaning that is asserted by a sentence", full stop. Whether it is true, false, unknown, possible, etc., is irrelevant to the definition. And the time of the utterance ("WHEN it is uttered") is not intended to be important to the meaning of an arbitrary proposition.

The definition of 'question' in 8.1.3 uses the undefined term 'interrogatory', but is probably intended to be distinct from 'proposition'. This means that a proposition is not the meaning of an interrogative sentence, and therefore not of an arbitrary sentence, but only of a declarative sentence.

Recommendation:

In 8.1.2, replace the definition of 'proposition' with:
"meaning that is asserted by a declarative sentence"

For consistency, in 8.1.3 replace "interrogatory" with "interrogative sentence".

A proposition is a meaning; a sentence is an expression of a meaning. The same sentence, however, can express more than one meaning, e.g., when stated by different persons at different times, or in different contexts of reference. So it is important to separate the proposition from its expression, and not to define 'proposition' in terms of sentences.

In terms of kinds of meaning, a proposition is distinguished from a concept by having a characteristic that is a "truth value" - true or false. The referent of a proposition is a conceptual/potential state of affairs that may or may not be an actual state of affairs.

Issue 10621 deals with questions and their relationships to other kinds of meaning, including propositions.

Description:
The "10 Example Rules" material makes use of some 'convenience concepts'**
in several of the rules. A consistent approach needs to be applied for
making vocabulary entries for these in SBVR-SE, and a discussion of that
pattern should be added to Annex D.

Actions needed:

1) Using the "10 Examples" material, change as needed to apply a consistent
approach to specifying this kind of vocabulary entry(s), which appear as
cited vocabulary entries in the 'Supporting fact types' material of the "10
Examples" (and from there into the EU-Rent Vocabulary (Annex E)).

2) Add a section to the "Patterns" annex, describing this.

3) Decide if an SBVR term is needed for what this issue terms a 'convenience
concept'. If yes, agree to the term. If no, agree to a consistent, short
characterization.

**'convenience concept' is an interim term, selected to avoid
conflict/confusion with overloaded terms in other discussions. Such a
concept/term establishes an equivalency to other defined concepts to allow
rules (and definitions) to be expressed in a less verbose manner. From the
"10 Examples" this includes: business currency, drop-off branch, pick-up
branch, rented car, requested car group, return branch, and some concepts
from the EU-Rent common vocabulary for time periods and durations (e.g.,
actual pick-up date-time).

1) Using the "10 Examples" material, change as needed to apply a consistent approach to specifying this kind of vocabulary entry(s), which appear as cited vocabulary entries in the 'Supporting fact types' material of the "10 Examples" (and from there into the EU-Rent Vocabulary (Annex E)).
2) Add a section to the "Patterns" annex, describing this.
Note: At the June 2006 meeting it was decided that the new material would appear in a new (D.3) section of Annex D entitled "Defining a Fact Type for Convenience".
3) Decide if an SBVR term is needed for what this issue terms a 'convenience concept'. If yes, agree to the term. If no, agree to a consistent, short characterization.
**Note: This Issue originally used the interim term 'convenience concepts'; at the June 2006 meeting it was decided that the term 'short form expression' would be used in place of that initial terminology.

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).

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.

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]

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.

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."

see above

It is a matter of grammar that verbs have passive forms. The standard passive formation uses the past participle of a verb preceded by “is” and followed by “by”. For example, I can say a cat eats a mouse or I can say a mouse is eaten by a cat. The vocabularies defined in SBVR explicitly include passive forms. But this is not necessary any more than it is necessary to include infinitive, subjunctive and plural forms. The forms are produced by rules of grammar. Synynomous forms should be given where a different verb is being used, but not for simply showing the same verb in different grammatical configurations.

In general, passive forms have been left out of diagrams. But they are explicitly listed in the vocabulary entries. It would be benefitial to simply explain in the appendix on SBVR Structured English that passive forms are implicitly usable and then omit passive forms from the vocabulary entries. This simplifies and shortens the specification without losing any meaning and without changing the meaning of any definition or statement. It makes the SBVR MOF metamodels and XMI schemas smaller without losing any semantic content. It also sets a better example for future users of SBVR.

see above

When a reference scheme extensionally uses a role of a fact type, the SBVR Structure English takes the form “the set of each <singular noun> that <singular verb> …”. This is a very awkward wording. Plurals should be used: “the set of <plural noun> that <plural verb> …”. Examples of how this improves understandability are readily seen in the recommended changes below.

Recommendation:

Make the following changes, in each case removing the word “each” and pluralizing the noun, and verb if given. Keep the fonts as they are.

Pg. 25, “the set of each placeholder” becomes “the set of placeholders”.

Pg. 29, “the set of each role that is” becomes “the set of roles that are”, twice.

Pg. 43, “the set of each concept that is” becomes “the set of concepts that are”, twice.

Pg. 45, “the set of each role binding” becomes “the set of role bindings”.

Pg. 57, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”.

Pg. 58, “the set of each logical formulation that is” becomes “the set of logical formulations that are”, thrice.

Pg. 58, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”, thrice.

Pg. 59, “the set of each logical formulation that is” becomes “the set of logical formulations that are”, thrice.

Pg. 59, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”, thrice.

Pg. 60, “the set of each logical formulation that is” becomes “the set of logical formulations that are”.

Pg. 60, “the set of each logical formulation that restricts” becomes “the set of logical formulations that restrict”.

Pg. 68, “the set of each variable that is” becomes “the set of variables that are”.

Pg. 68, “the set of each logical formulation that constrains” becomes “the set of logical formulations that constrain”.

Pg. 129, “the set of each symbol context that qualifies” becomes “the set of symbol contexts that qualify”.

Pg. 206, “the set of each role that is” becomes “the set of roles that are”, twice.

Pg. 206, in the second paragraph of C.3.9, change “the set of each” to “the set of”.

Change uses of "the set of each" to "the set of" and uses plurals accordingly.

The specification does not address the mapping of rules to MOF and XMI. The following sections address in detail the mapping of vocabulary to MOF and XMI. It seems to me that – absent equivalent detail about mapping of rules – the goal of effectively interchanging rules may not be achieved.

• Section 13.3, "Vocabulary-to-MOF/XMI Mapping Rule Set" gives rules for mapping vocabulary to MOF and XMI, but ignores the question of mapping rules to MOF and XML.
• Annex K, "Design Rationale Details for the Use of MOF and XMI", contains lots of discussion about the representation of vocabularies in MOF and XMI but mentions rules only in passing.
• Annex L, "Examples of SBVR's Use of MOF" shows how a subset of the EU-Rent vocabulary should be represented in MOF and XMI but again overlooks rules.

Resolved by the resolution to Issue 9930.

SBVR uses URIs in a reference scheme for namespaces. The URIs are particularly important for standardized namespaces so that standard designations can be identified. But SBVR does not give the namespace URIs needed for its own vocabularies or for source vocabularies. These URIs are needed in order to facilitate interchange.

Also, XMI documents based on an SBVR vocabulary need to identify an xmlns URI for the particular metamodel being used and for Essential SBVR. Xmlns URIs are needed for each of these:

· Essential SBVR

· SBVR

· Meaning and Representation

· Logical Formulation of Semantics

· Vocabulary for Describing Business Vocabularies

· Vocabulary for Describing Business Rules

· Vocabulary-to-MOF/XMI Vocabulary

I have seen examples of such xmlns URIs for OMG specifications, but the pattern is not completely consistent.

· http://schema.omg.org/spec/XMI/2.1

· http://schema.omg.org/spec/MOF/2.0/cmof.xml

· http://org.omg//UML/2.0/UML2L1.xml

We need to determine a pattern to use for SBVR. Then for each corresponding vocabulary namespace, either use the same URI or some variation. Here is one possible set of xmlns URIs.

· http://schema.omg.org/spec/SBVR/1.0/SBVR

· http://schema.omg.org/spec/SBVR/1.0/Meaning-and-Representation

· http://schema.omg.org/spec/SBVR/1.0/Logical-Formulation-of-Semantics

· http://schema.omg.org/spec/SBVR/1.0/Vocabulary-for-Describing-Business-Vocabularies

· http://schema.omg.org/spec/SBVR/1.0/Vocabulary-for-Descibing-Business-Rules

· http://schema.omg.org/spec/SBVR/1.0/Vocabulary-to-MOF/XMI-Vocabulary

· http://schema.omg.org/spec/SBVR/1.0/Essential-SBVR

One possible variation for the namespace URIs would be to replace “schema” with “namespace”. E.g. http://namespace.omg.org/spec/SBVR/1.0/Meaning-and-Representation

This needs to be coordinated with OMG so that it fits a planned general structure.

Recommendation:

Note that this recommendation is incomplete. It needs an agreement in the FTF and with OMG on the OMG-based URIs to be assigned.

7.1.1 and 7.1.2 (pg. 11-12), add a “Namespace URI:” line under the “General Concept:” line or “Definition:” line of each entry in the sections. Give the appropriate URI.

7.1.3 (pg. 12), add a “Namespace URI:” line under the “Definition:” line of each name.

C.3 (pg. 201), add ‘Namespace URI:” to the end of the list of captions under “<primary representation>”.

Add “C.3.16 Namespace URI” at the end of section C.3 (pg. 208) as follows:

C.3.16 Namespace URI

If the primary entry is for a namespace, the ‘Namespace URI” caption is used to indicate a URI of the namespace. If the primary entry is for a vocabulary, the ‘Namespace URI” caption is used to indicate a URI of a vocabulary namespace for the vocabulary. Here is an example:

Meaning and Representation Vocabulary

General Concept: vocabulary

Namespace URI: <INSERT OFFICIAL URI HERE – same as what is used in 7.1.1>

In section 15, (starting on pg. 169), give the xmlns URIs for the XML schema documents.

Add a new captioned paragraph style, "Namespace URI" to the SBVR Structured English, and then use it to give URIs to the various vocabulary namespaces.
Assign URIs following OMG's pattern, which identifies SBVR and its version:
http://schema.omg.org/specs/SBVR/1.0/<specific-name>
Also, add SBVR Vocabulary as a combination of Meaning and Representation Vocabulary, Logical Formulation of Semantics Vocabulary, Vocabulary for Describing Business Vocabularies and Vocabulary for Describing Business Rules so that a namespace URI can be conveniently used in XML documents that convey combinations of vocabulary, rules and semantic formulations.

The specializations of ‘noun form’, namely ‘nominal restrictive form’, ‘mathematical form’ and ‘gerund form’, delve into grammatical structure, which SBVR generally avoids. It is sufficient to distinguish forms of expression into being propositional versus being nounish. The examples given for the different kinds of noun forms are helpful, but they can be given without introducing the added grammatical complexity into the formal metamodel. Also, these specializations are not complete with respect to noun forms and it is beyond the scope of SBVR to make the specializations complete.

Recommendation:

The following edits preserve and combine explanatory material and examples from the unwanted specializations and then delete the specializations. Brackets are used to show words that should be underlined (not the term style). The numerals attached to “number” should all be subscripts.

8.3.4 (pg. 25-26)

Add the following note to the entry for ‘noun form’ just below its definition.

Note: A noun form can have a placeholder for each role of a fact type, in which case the noun form result comes from the of role the first placeholder is for. A noun form can also have one less placeholder than there are roles, in which case the noun form result comes from the role that no placeholder is for.

Replace the examples in the entry for ‘noun form’ with these:

Example: ‘[transferred car] of [car transfer]’ for the fact type ‘[car transfer] has transferred car]’. This form yields a transferred car.

Example: ‘| [number] |’ for the fact type ‘[number] has [absolute value]’. The form yields the absolute value of the number.

Example: ‘[number1] + [number2]’ for the fact type ‘[number1] + [number2] = [number3]’. This form yields the third number – the sum of adding the first two numbers.

Example: ‘transferring [rental car]’ for the fact type ‘[car transfer] has [transferred car]’. This form yields the car transfer, which is an action. Gerunds are used in noun forms like this for actions, events and states. They are used in sentences like this: “A rental car must be cleaned before transferring the rental car.”

Remove the entire entries for ‘mathematical form’, ‘nominal restrictive form’ and ‘gerund form’.

I can provide an updated Figure 8.4 on page 24.

see above

The reference scheme for ‘reference scheme’ needs to consider characteristics used by the reference scheme, but it does not. This is necessary because a reference scheme that considers a characteristic is always different from one that does not.

Recommendation:

8.4 (pg. 29, bottom)

Add the following to the end of the “Reference Scheme:” paragraph for the ‘reference scheme’ entry:

and the set of each characteristic that is used by the reference scheme

The term style should be used for “characteristic” and “reference scheme”, the verb style for “is used by” and the keyword style for the rest.

see above

Based on ISO’s ‘individual concept’ a fact type could be an individual concept. But the specification gives ‘noun concept’ as the more general concept of ‘individual concept’. Also, as it stands, ‘individual concept’ is inconsistent with ‘general concept’.

Recommendation:

8.1.1 (pg. 17)

Remove line in the entry for “individual concept” that says, “General Concept: noun concept”.

I can provide an updated Figure 8.1 on page 15.

Remove from the specification that 'individual concept' specializes 'noun concept'.

The caption “Synonymous Form” should not be used for synonymous statements in the SBVR Structured English because the term has a different meaning which is related to forms of expression. See C.5.6 (pg. 210).

Recommendation:

Change the caption “Synonymous Form” to “Synonymous Statement” in the following places:

C.5 (pg. 209) in the list under <Rules Statement or Clarification Statement>.

C.5.6 (pg. 210) in the section heading and in the paragraph.

E.2.2.2.4 (pg. 278 near top).

E.2.2.2.5 (pg. 280 near bottom).

E.2.2.2.7 (pg. 282 top of section).

E.2.2.2.9 (pg. 284 near top).

F.3.3 (pg. 303 above middle).

F.3.8 (pg. 307 near middle).

see above

The following example given in C.3.2.1 (pg. 202) is no longer correct.

semantic formulation

Definition: logical formulation or projection

Recommendation:

Replace that example with ‘bindable target’ as follows:

bindable target

Definition: variable or text

Replace the sentence above the example that says “For example, a semantic formulation is anything that is a logical formulation or a projection” with this: “For example, a bindable target is anything that is a variable or a text”.

Replace the example with 'bindable target'.

Figure 11.5 on page 123 shows associations for two fact types that do not exist. If they did exist, an ambiguity would be created. The associations are for:

categorization fact type has more general concept

categorization fact type has category

Recommendation:

Remove the two associations from Figure 11.5.