Issues for Semantics of Business Vocabulary & Business Rules Revision Task Force

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

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

Issue 12437: Issue "fact type role is in fact type"
Issue 12540: Clause 8 does not include the concepts needed to represent itself
Issue 12541: No relationship defined between clause 8 concepts and clause 11 concepts
Issue 13139: Clean up and Complete Vocabulary for Clause 10.1.1
Issue 13150: Issue: SBVR Clause 8
Issue 14029: Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition
Issue 14849: Instances of Clause 8 fact type should be states of affairs
Issue 15124: Inconsistent use of terminology when relating facts to fact types
Issue 15157: Existential and Elementary
Issue 15953: 'reality' and 'in-practice' models
Issue 16059: Governed Community & Adoption of Business Rules
Issue 16062: SBVR Issue: Move 'rulebook'
Issue 16166: Distinguishing between Representation Expressions With and Without Embedded Markup
Issue 16258: A statement may express no proposition
Issue 16314: SBVR issue: Can there be multiple instances of a thing?
Issue 16486: SBVR Issue - Relationships between States of Affairs
Issue 16527: SBVR ISSUE - definite description
Issue 16610: SBVR issue - Need verb concept to support "local closure"
Issue 16630: Actuality demonstrates Proposition
Issue 16631: The formal logic interpretation for SBVR in Common Logic (CL) given in Clause 10 is incomplete
Issue 16683: Define that Clause 10 ‘Fact Models’ are by Default Closed World Models
Issue 16684: SBVR Vocabularies Relationship to SBVR Subclause 10.1.1
Issue 16685: Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1
Issue 16727: "thing has property".
Issue 16871: Annex F is in the wrong specification
Issue 17068: Simplification of presentation of Annex E
Issue 17097: SBVR issue - Re-sequencing Clause 11
Issue 17144: typo in clause 10.1
Issue 17241: Annex H recommends faulty UML constructs
Issue 17243: Precedence of operators
Issue 17244: Keyword "another"
Issue 17269: Use of morphological variants of terms is inadequately addressed
Issue 17414: Clarify Purpose and Scope of SBVR, the Authority for SBVR Vocabulary Content, and SBVR Vocabularies
Issue 17439: Individual Verb Concept
Issue 17440: Redefinition of "Body of Shared Concepts" (Clause 11)
Issue 17441: Definition of "representation uses vocabulary" (Clause 11
Issue 17452: New SBVR issue - Re-sequencing Clause 8
Issue 17527: Correct ambiguities in signifiers and definitions of noun concepts
Issue 17532: Noun form designates two different concepts
Issue 17542: Inadequate, Overlapping and Disorganized Specs for Sets and Collections of Concepts, Meanings, and Representations
Issue 17571: Distinguishing the senses of infinitive and present tense
Issue 17599: Align Definitions of Modal Entries in Clauses 8, 9 & 10
Issue 17791: How can an attributive role be declared?
Issue 17792: Clause 10.1.2 Vocabulary Clarifications
Issue 17819: Scope of an SBVR Body of Shared Concepts
Issue 18166: individual verb concept’ in SBVR
Issue 18172: Add Generic Occurrence to SBVR to Support Other Specifications for Occurrence in Time, Space or Other Dimensions
Issue 18317: Clarifications and Fixes for State of Affairs Related Entries
Issue 18367: The SBVR document is far larger than optimal. It needs to be reduced in size
Issue 18377: Simplification of SBVR by Integrating Clauses 8 & 11
Issue 18378: styling of signifiers
Issue 18524: SBVR 1.1 typos - p. 100 (logics modality table)
Issue 18621: Updating Annex F "The RuleSpeak Business Rule Notation
Issue 18651: Error message from XML Schema validator when trying a SVBR XSD
Issue 18658: SBVR 1.2] 'level of enforcement' editorial correction
Issue 18703: Fix the objectification example
Issue 18824: SBVR Issue: Problematic necessity in 8.5.2
Issue 18825: SBVR SE does not support the DateTime usage of subscripts
Issue 18826: Correct the scope of placeholder terms

Issue 12437: Issue "fact type role is in fact type" (sbvr-rtf)

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


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


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

SBVR currently has multiple concepts for organizing vocabularies and rules:


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


Some issues:


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

SBVR currently has multiple concepts for organizing vocabularies and rules:


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


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

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

 

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

 

-          the proposed resolution of this spin-off Issue which will be posted when it has a number; 

-          the proposed resolution to Issue 12540; and 

-          the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number.

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

 

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

 

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

 

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

 

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

 

conceptual schema

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

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

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

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

fact model1 includes fact model2

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

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

fact model includes description

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

thing has URI

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

 

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

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

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

-	 'proposition' meaning that is true or false          (the "semantic content"                                            
                                                    part in 'proposition' + performative')

-	'proposition' + 'performative'     (where the 'performative' part is the
                                                  "communicative  function") e.g.:

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

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

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

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

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


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

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

'Actuality' is a specialization of 'state of affairs'. 
Clause 8 says:
fact type (synonym: verb concept): concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities
There are other instances of fact type that need to be accommodated, such as:
§	states of affairs that are planned to become actualities
§	states of affairs that might be actualities, but the semantic community does not yet know for sure 
Instances of a fact type should be states of affairs. 

See summary
Dependencies with other Issue Resolutions
Un-numbered Issue: Fact Type and Verb Concept should not be not synonyms
This issue and the un-numbered issue "SBVR Linguistic Model and Fact Model are different models" together supersede "Fact Type and Verb Concept should not be not synonyms"
Resolution:
Change the definition of fact type to:
fact type (synonym: verb concept): concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all states of affairs

Inconsistent use of terminology when relating facts to fact types

 

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

 

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

 

Recommended changes:

 

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

 

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

 

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

 

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

 

With this:

 

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

 

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

 

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

 

REPLACE it with this:

 

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

 

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

 

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

 

REPLACE it with this:

 

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

 

 

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

 

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

 

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

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

 

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

 

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

Is it existential?  I cannot see it that way.

 

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

 

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

 

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

     Employee number 777 is assigned.

     There exists an employee that has the employee number 777.

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

 

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

 

Recommendation:

 

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

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

 

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

All, In resolving Issue 15950 it has come to our attention that "community" and "semantic community" are used in Clause 12 in ways that are not really appropriate. I believe we are currently missing a very important concept for SBVR -- namely, the "business" part of "business rule". Attached is discussion and proposed resolution.

Title: Governed Community & Adoption of Business Rules

Source: Ronald G. Ross, Business Rule Solutions, LLC, rross@BRSolutions.com

Summary:

SBVR currently lacks a concept and term for the kind of community that creates business rules. This glaring omission was separated by agreement of the team from resolution of Issue 15959 (Inappropriate definitions of Business Rule, Rule Statement). 

The current definition of “community” is: group of people having a particular unifying characteristic in common

The current definition of “semantic community” is: community whose unifying characteristic is a shared understanding (perception) of the things that they have to deal with

By these definitions, any of the following could qualify as (semantic) communities: atheists, deists, communists, surfers, Francophiles, Anglophiles, futurists, business travelers, rappers, wine lovers, car surfers, baseball fans, diabetics, business travelers, psychics, nudists, philatelists, Egyptian protesters, Japanese earthquake victims ...

Such communities do not, and cannot, create business rules. They lack the authority, standing and charter to do so. Unlike societies, organizations and businesses, they are not governed communities. 

Currently, SBVR has no concept for the special kind of communities that are governed. In effect, SBVR has no meaning for the “business” part of “business rule”. This omission is a significant one.

In addition, SBVR currently does not adequately recognize or treat adoption of business rules. Adopting business rules is an act of free will (by a governed community) and should explicitly satisfy the “under business jurisdiction” test in the definition of “business rule”. 

Resolution: 

Add a category of “community” called “governed community” as follows.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Definition: community that by virtue of some recognized standing, authority or charter can create, adopt and apply business rules

Dictionary Basis [MWUD “govern”]: 1a: to exercise arbitrarily or by established rules continuous sovereign authority over;  especially  : to control and direct the making and administration of policy in

Examples: societies, chartered organizations, businesses, government bodies

Example: EU-Rent is a legal entity, makes business rules for itself, and is therefore a governed community. Eu-Rent is also a member of each governed community (country) where it does business, as well as the European Union, a yet broader governed community.

Note: A governed community can adopt sets of business rules (and advices) as-is, just like vocabulary. The decision to adopt business rules ‘as-is’ is an act of free will and therefore satisfies the “under business jurisdiction” test in the definition of “business rule”.

Note: The “business” part of “business rule” is a popular, informal term for “governed community”.

Note: The question “Who makes the rules?” for a governed community is outside the scope of SBVR. 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Revised Text:

Previously, I did a search of Clause 12, and sent my findings and recommendations. There are 5 segments of text where “semantic community”, “community” or “communities” appear. Below are (revised) recommendations for each.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[1] body of shared meanings includes body of shared guidance 

Definition: the body of shared guidance is the set of all elements of guidance in the body of shared meanings uniting a semantic community that takes the elements of guidance as true 

RGR: This definition is problematic. Alethic elements of guidance might “unite” a semantic community (no real opinion), but I don’t see deontic elements of guidance as (a) “uniting” anything, or (b) pertaining to semantic community at all (unless the semantic community just happens to be a society, organization or business). 

Also, from a business perspective (as appropriate for Clause 11), a “community” doesn’t “take … elements of guidance to be true”. That’s a logician’s view. It would be more accurate to say ‘recognizes … as applicable’.

Recommendation: Delete the phrase starting “uniting ...”.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[2] business rule 

Definition: rule that is under business jurisdiction
 
General Concept: rule, element of guidance
 
Note: A rule’s being under business jurisdiction means that it is under the jurisdiction of the semantic community that it governs or guides - that the semantic community can opt to change or discard the rule. Laws of physics may be relevant to a company (or other semantic community); legislation and regulations may be imposed on it; external standards and best practices may be adopted. These things are not business rules from the company’s perspective, since it does not have the authority to change them. The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them. Similarly, it will create business rules to ensure that standards or best practices are implemented as intended. See subclause A.2.3. 

RGR: There are 3 instances of “semantic community” in this note. 

Recommendation: I would change this note to read as follows:

Note: A rule’s being under business jurisdiction means that it is under the jurisdiction of the governed community that it governs or guides - that the governed community can opt to change or discard the rule. Laws of physics may be relevant to a governed community; legislation and regulations may be imposed on it; external standards and best practices may be relied upon. These things are not business rules from the company’s perspective, since it does not have the authority to change them. The company will decide how to react to laws and regulations, and will create or adopt business rules to ensure compliance with them. Similarly, it will create or adopt business rules to ensure that standards or best practices are implemented as intended. See subclause A.2.3.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[3] advice of contingency

Definition: advice of possibility that is a claim of contingency 

Note: The purpose of an advice of contingency is to preempt application of rules that might be assumed by some members of a semantic community, but are not actually definitional rules admitted by the community. Often, the reason for this assumption in a business is that other, similar businesses have such rules. Typically, the reason for providing such explicit advice is that people in the business have mistakenly applied the non-existent rule in the past. 

RGR: There is one instance of “semantic community” in this note and one instance of “community”.

Recommendation: Both instances should be replaced by “governed community”. 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[4] advice of optionality
 
Definition: advice of permission that is a claim of optionality
 
Note: The purpose of an advice of optionality is to preempt application of rules that might be assumed by some members of a semantic community, but are not actually behavioral rules imposed by the community. Often, the reason for this assumption in a business is that other, similar businesses have such rules. Typically, the reason for such explicit advice is that people in the business have mistakenly applied the non-existent rule in the past. 

RGR: There is one instance of “semantic community” in this note and one instance of “community”.

Recommendation: Both instances should be replaced by  “governed community”.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[5] Section 12.5, page 178, the paragraph that reads:

In cases where definitions of concepts taken together do not logically imply something proposed in a structural rule statement, there is an inadequacy or mistake in either the relevant definitions or in the rule statement. The case of inadequate definitions is common and is acceptable in some communities. It occurs when a community shares a tacit understanding of many of its concepts. Words either have no explicit definitions or have definitions that use words that have no explicit definitions. Structural rule statements in this context can be correct, even if they logically follow from a tacit understanding of what characteristics are incorporated by concepts. 

RGR: There is one instance of “community” in this section and one instance of “communities”.

Recommendation: I have no strong feelings at present about whether these instances should be changed or stand.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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


Resolution:  Move 'rulebook' to Clause 12.

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

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

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

In clause 8.3.3, in the glossary entry for "statement", SBVR has the
Necessity "Each statement expresses exactly one proposition ". This
Necessity is also shown in figure 8.4 and is cited as an example on printed
page 6.  The issue is that some statements do not express propositions
(i.e. a meaning that is true or false, per the definition of 'proposition'
in 8.1.2).  There are at least two types of statements that are neither
true nor false: (a) paradoxes, such as "This statement is false"; (b)
atemporal statements used with temporal worlds.  For example, the statement
"the board of director meets" is a proposition (i.e. either true or false)
in an atemporal world (i.e.a world that only contains facts about one
moment in time).  But in a world that has records of multiple meetings of
the board of directors, the statement is ambiguous. It can be understood as
true if read as meaning "the board of directors meets at some time".  It is
either true or false (according to the facts in the world) if it is read as
"the board of directors meets right now". Clearly a statement does not
express a proposition when the statement is paradoxical or ambiguous.


Suggested resolution:


Revise the Necessity to read "Each statement expresses at most one
proposition."  Revise the figure and the example to match

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


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

SBVR’s explanation of the concept ‘state of affairs’ could be improved by clarifying how states of affairs include or exclude each other.  This is relevant to distinguishing involvement (already defined in SBVR) from inclusion.  It is also relevant to understanding the relationship between a situation and the circumstances it includes

Definite descriptions do not always define individual concepts

 

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

 

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

 

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

 

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

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

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

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

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

Example use cases for local closure include the following:

Example 1

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

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

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

Example 2

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

employee
Definition:	person that works for the business

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

Example 3

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

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

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

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

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

Resolution:
Revised Text:
Disposition:	

SBVR says (in clause 8.6.2, as of ballot RTF 1 ballot 5) that "Each proposition corresponds to exactly one state of affairs." For example, the proposition "each driver of a rental is qualified" (as may be embedded within an obligation statement) corresponds to a single state of affairs in which all drivers of a rental are qualified. Per clause 8.1.2, such a proposition is true or is false according to whether the corresponding state of affairs is actual.

This idea is meaningful to logicians but not to business people. Business users of SBVR will not care about a state of affairs in which "all drivers of a rental are qualified". What is meaningful to business users is the actualities that comprise that state of affairs – in this case, whether each driver, taken individually, is qualified.  If the overall proposition is false, an immediate question will be, "which driver is not qualified, and why not?"

To support this kind of analysis, SBVR should have a verb concept that relates a proposition to the actualities that make the proposition true or false. The relationship already exists indirectly through the "state of affairs1 includes state of affairs2" verb concept introduced by the disposition of issue 16526. The current issue proposes a direct relationship, built on and consistent with "state of affairs1 includes state of affairs2", that avoids the need for business users to understand the logician's idea of "proposition corresponds to state of affairs".

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


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

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

Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns:
1.	Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. 
The proposed resolution is:
1.	Define that Clause 10 ‘fact models’ are by default closed world models

Spin-off from Issue 14843 (via Issue 15623 Issue Resolution into which it was Merged)
The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined.
The underlying issue is:
1.	SBVR’s metamodel is defined in Clauses 8, 9, 10, 12 and 13. Its instances (domain models) are linguistic models of meanings. 
2.	The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR’s metamodel. Its instances (domain models) are fact models.
The proposed resolution is:
1.	State, in introductory text in Clauses 8 and 10, that the models are different 
2.	Somewhere in Clause 10: 
a.	List the major differences between the two models 
b.	Describe informally what transformation would be needed to derive a domain fact model from a corresponding linguistic model.  It is probably beyond the scope of this RTF to develop a formal specification

Resolution:
1.	Add a subclause to Subclause 10.1.1 to discuss to an appropriate level of detail all aspects of the relationship between the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 and the formal interpretation in Subclause 10.1.1, as well as removing ambiguity from Clause 10.1.1 by consistent use of terms intension, extension, fact population, and the set of all possible facts..

OMG Issue No:  16685
Title:	Fix Entries in Subclause 10.1.2.1 to Align with Subclause 10.1
Source:
SBVR Co-chair, Donald Chapin [Donald.Chapin@BusinessSemantics.com]
Summary:
Spin-off from Resolution of Issue 15623 (and 14843 which was Merged into it)
Fix the entries in SBVR Subclause 10.1.2.1 to bring them in line with what Clause 10.1 says as revised by the resolution to Issues 15623 & 14843.

(a) Clause 11 should include the verb concept "thing has property". This verb concept should appear in figure 11.5.
 
(b) Property needs to be indicated as an abstract concept in Clause 13 (since it is in the universe of discourse, not the model).

Date/Time Annex F is titled:  Annex F    Simplified Syntax for Logical Formulations.


First, the title is wrong.  The Date/Time standard contains logical formulations in OCL and CLIF.  This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9.  It should be titled:  Simplified Syntax for SBVR Logical Formulations.


Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification.  If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it.  If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it. 
Recommendation:  Delete Annex F and refer to the OMG (SBVR) specification that actually includes it.  Otherwise, use a standardized SBVR notation in Annex E. 
The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification -- a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification.

The value of a comprehensive and coherent SBVR example seems to be generally accepted, but there have been some concerns expressed about the size and complexity of the EU-Rent example (Annex E). 
Section E.2.2.1.1 Car Movement is a particular problem. It is presented first in the detail of EU-Rent‘s vocabulary but is quite complex. It introduces the idea of ‘car movement’, a component that is used in two different contexts ­ as part of the definition of a rental, and as part of the definition of a logistical car movement made by a EU-Rent employee. 
Annex E could be made more digestible, without substantially changing its content, by:
1) Presenting the sections in a different sequence, with sections that introduce simpler ideas presented earlier. 
2) Presenting ‘car movement’ in a simpler form
This issue can be resolved alongside Issue 10628: Align Annex E with the normative text.
To avoid delay in updating the SBVR specification, updating EU-Rent to comply with the SBVR Date-Time Vocabulary is outside the scope of this issue, and will be addressed later.

Problem: SBVR adheres to ISO 1087 as much as possible. Clearly evident in the structure of ISO 1087 is that no definition should appear until all terms within it have been defined (as needed). This best practice (rule) results in a logical, easy-to-follow presentation. Clause 11 of SBVR is clearly broken in this regard. The result is significant lack of clarity, making detection of errors unnecessarily difficult. The possibility of misinterpretation (or non-comprehension) by software engineers and other readers is high. 
 
Aside: Personally I think this solution amounts to simple editing because anyone could apply the ISO 1087 rule without understanding a thing about the content. However, since some might see new headings or groupings as somehow conveying meaning – never the case in SBVR – I have nonetheless requested an issue. There are also a few choices about optimizing placement.
 
Note: **This issue can be resolved without using any meeting time.**
 
Resolution: Apply the ISO 1087 rule about sequencing vocabulary entries rigorously. This re-sequencing requires no changes in the entries themselves. 
 
Attachments: Two files containing all Clause 11 entries are attached. One file is unchanged except that entries are numbered. The other file is re-sequenced. The entry numbers reappear in the re-sequenced file indicating the original location of each entry. Unfortunately, this working version does not use the latest version of SBVR … I did not have the source file for that. However, since no changes to the entries themselves are covered by this issue, the version used is largely immaterial to illustrate the proposed resolution. The lay-out simply needs to be re-done for the newer material. 

"vocabularies" is miss-spelled "vocabulaires" in the sixth paragraph of clause 10.1.1 in convenience document 8. 

Annex H provides detailed guidance on the representation of SBVR vocabulary concepts in UML diagrams.  Much of that guidance produces invalid UML constructs per UML 2.4.


H.1 "If there are additional terms for the concept they can be added within the rectangle, labeled as such -- e.g., “also: is-category-of
fact type” as depicted in Figure H.1."  There is no UML syntax for this.


H.2 "Alternatively, an individual concept can be depicted as an instance of its related general concept (noun concept), as in Figure H.3." The diagram uses an unidentified Dependency, which has no meaning.  It should be formally stereotyped.


H.3.1 shows three representations of the fact type 'semantic community shares understanding of concept'.  The third is invalid -- an association can have only one name.  Also the name of the association is 'shares understanding of'; it does not include the placeholder terms.


H.3.1 Figure H.4 shows associations that are navigable in both directions, inducing unnamed UML properties on 'semantic community' and 'concept' that are not intended.  (This is a vestige of UML v1 ambiguity.)  It should show no navigable ends, using UML 2.4 syntax.


H.3.4 Figure H.9 depicts an invalid relationship symbol; an association is required to have 2 or more roles.


H.4.2 Figure H.11 shows a stereotype <<is role of>> on a Generalization.  I'm not sure this is valid UML, but in any case such a stereotype would have to be defined in a formal Profile.  (Semantically, some "roles" are object types that specialize more general concepts, others are association ends (verb concept roles), and others are things in their own right that have the property 'role has occupant'.)


H.4.3 suggests that there is no consistent mapping for association names.  In any case, the UML model of a 'fact type role' is a named association end, regardless of ownership.


H.6.1 Figure H.14.  It is not clear what UML element has the name "Results by Payment type", and the text does not say.  It may be a GeneralizationSet.


H.6.2 Figure H.16. ":modality" appears to be a TagValue associated with some unnamed and undefined Tag, or it may just be another string that names no model element.


H.8 In, Figure H.17 there is a meaningless dashed line between 'car recovery' and a ternary association (verb concept).  It is said to represent 'objectification'.  That dashed line should be a Dependency that has a stereotype indicating the nature of that relationship, e.g., <<objectification>>, defined in a Profile.


H.9 says that the default multiplicity on association ends is 0..*. According to the UML metamodel v2.4, the default multiplicity on a UML association end is 1..1, i.e., exactly one.  This makes most of the SBVR UML diagrams implicitly erroneous.


So Annex H needs to be rewritten, and if it is to include standard stereotypes and tag values, it needs a standard UML Profile that defines them.


Further, it demonstrates the need for minor repairs to the UML diagrams throughout SBVR, to make them match the MOF model described in Clause 13.

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

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

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

SBVR apparently assume that business terms are composed of natural language words, and that those words may have multiple morphemes that are nonetheless the same word and the same term.  That is, a vocabulary term like 'purchase contract' may also have the form 'purchase contracts', and a vocabulary term like 'is owned by' may be expressed as 'has been owned by'.  But SBVR says nothing about any of this in defining 'designation' or 'signifier'. 
When a signifier for the same concept is in a formal language like OWL or CLIF, this idea of multiple morphemes is not (usually) part of the language syntax.  So this should be carefully addressed.


For the SBVR Structured English language, Annex C.1 explicitly says that these alternate morphemes are "implicitly available for use", which may mean they are treated as equivalent, or just that they are recognized as uses of the same designation.


In natural language, such morphemes carry additional meaning , e.g., plurality or tense or mood.  And a morphological variant of the same designation may or may not carry additional meaning, This is important, because SBVR examples assume that plurals are conventional and irrelevant, but the Date Time Vocabulary says that the use of verb tenses in natural language conveys indexical time intent.  That is:  
'John is in London' and 'John was in London' have different meanings in English.  Do they have different meanings in SBVR SE? 
And if so, do they always have different meanings?  Natural language convention requires that a statement that dates a past event uses the past tense, e.g., 'John was in London in 2008.'  Is it meaningful in SBVR SE to say (in 2012) 'John is in London in 2008'?  And does that mean a different proposition from 'John was in London in 2008'?

Title:	Clarify the Purpose and Scope of SBVR, the Authority for SBVR Vocabulary Content, and SBVR Vocabularies Do Not Include Business Instance Data
Source:
Business Semantics Ltd, Donald Chapin, (Donald.Chapin@btinternet.com)
Summary:
Since SBVR v1.0 was published in January 2008 there has been widespread misinterpretation and misrepresentation of SBVR as a data modeling specification that is not easy to refute with finality because Clause 1 “Scope’ does not make it clear that the authority for the content of an SBVR Vocabulary is the usage of terms and other designations in a corpus of business documentation.
Further contributing to the problem is the fact that the Subclause 10.1 formal semantics for SBVR is one that is based on a fact-oriented data modeling paradigm.  Even though the formal interpretation is meant to be specified only in terms of formal logic there is wide reference to “facts”.  Since the representations of facts are what data is, without statements to the contrary this can be used as a basis for incorrectly interpret the SBVR vocabularies in Clause 7, 8, 9, 1 & 12 as a collection of vocabularies for fact-oriented data modeling rather than documentation of the business language used by business people.
Resolution:
1.	Clarify the Scope of SBVR in Clause 1 to be explicit that SBVR does not include business instance data; and make it clear that the content of an SBVR vocabulary documents the meaning of terms that business authors intend when they use them in their business communications, as evidenced in their written documentation, especially governance documentation.
2.	Add a list of purposes / uses of SBVR 
3.	Explain that “Semantic Anchors” are the best way to relate SBVR vocabularies to data models and models for reasoning over data.
4.	Make it clear that SBVR vocabularies are different from all forms of data models models for and reasoning over data..
5.	Make fact an abstract concept in Clause 13.2.2 as instances of business facts (instance data) and fact statements do not go into an SBVR Vocabularies or Rulebooks.
6.	Clean up miscellaneous uses of the word “fact”.
Revised Text:
… to follow

Title:	Fix the anomaly in the subcategory structure of ‘concept’ to include ‘individual verb concept’ in SBVR
Source:
RuleML Initiative, John Hall, (john.hall@modelsystems.co.uk)
Summary:
SBVR handles noun concepts and verb concepts asymmetrically:
•	‘concept’ generalizes ‘noun concept’ and ‘verb concept’ 
•	‘noun concept’ generalizes ‘general concept’ and ‘individual concept’ – i.e. ‘general concept’ means ‘general noun concept’ and ‘individual concept’ means ‘individual noun concept’ 
There are no equivalents for ‘verb concept’. SBVR does not explicitly define ‘individual verb concept’, so cannot say:
•	‘individual concept’ generalizes ‘individual noun concept’ and ‘individual verb concept’ (inheriting from: ‘concept’ generalizes ‘noun concept’ and ‘verb concept’)
•	‘verb concept’ generalizes ‘general verb concept’ and ‘individual verb concept’ (paralleling: ‘noun concept’ generalizes ‘general noun concept’ and ‘individual noun concept’)
If it did, this structural inconsistency would be removed. 
It would also be helpful in using SBVR. Individual noun concepts, such as “EU-Rent” and “Luxembourg”, are useful in defining bodies of shared meanings in SBVR. If SBVR included ‘individual verb concept’, an SBVR body of shared meanings could include individual verb concepts such as “EU-Rent is incorporated in Luxembourg”. 
Resolution:
1.	Change the preferred term that is currently ‘individual concept’ to ‘individual noun concept’ to clarify that it applies to noun concepts only
2.	Add the concept ‘individual verb concept’ for a proposition that is a Clause 8 verb concept with all its roles quantified (closed) by individual (noun) concepts to fix the anomaly in the subcategory structure of ‘concept’.

Revised Text:
On printed page 22 in Clause 8.1.1 
REPLACE the current term heading “individual concept” WITH “individual noun concept” 

And REPLACE “concept”, the first term in the definition, WITH “noun concept”


On printed page 27 in Clause 8.1.2 at the end of the clause ADD this entry for ‘individual verb concept’:

individual verb concept

Definition:	proposition that is based on exactly one verb concept in which each verb concept role is filled by an individual noun concept
Note:	… some explanatory comments
Example:	… some illustrative examples


REPLACE the signifier “individual concept” WITH “individual noun concept” in the following places (but not in the “Source” subentry reference to ISO 1087-1 in entry for the concept current termed “individual concept’)

•	… to be identified and added 


REPLACE the following diagrams WITH diagrams that repolace the signifier “individual concept” with “individual noun concept”:

•	Figure 8.1
•	Figure 9.3
•	Figure 11.2

… plus fixes for any additional side effects:

Problem: If "body of shared concepts" were defined as [the set of] all of the concepts within a body of shared meanings", then I dont think the following entry would be needed: "body of shared concepts includes concept".

Resolution:

1. Change the definition of "body of shared concepts" to: the set of all of the concepts within a body of shared meanings"

2. Eliminate the entry: body of shared concepts includes concept

Problem: The current definition of "representation uses vocabulary" is "the representation is expressed in terms of the vocabulary". I think the un-styled "term" (in terms of) is a bad choice for the definition. A better choice might be based on. 

Resolution:

Change the definition of "representation uses vocabulary" to: "the representation is expressed based on the vocabulary".

All, The re-sequencing of Clause 11 has initially proven quite worthwhile, so I have been encouraged to do similar work on Clause 8. As before, I made no changes to the entries themselves whatsoever. (If I did, it was purely an error and should be corrected. Also, my work should be double-checked for any entries inadvertently omitted.) I used a Word version kindly supplied by Linda Heaton, which I believe is from the latest convenience document. (It does have some styling problems, which I have noted.) I hope we can move forward with this revision expeditiously. By the way, I found this re-sequencing much harder than Clause 11, which I am much more familiar with.

Ron

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Problem Statement: SBVR adheres to ISO 1087 as much as possible. Clearly evident in the structure of ISO 1087 is that no definition should appear until all terms within it have been defined (as needed). This best practice (rule) results in a logical, easy-to-follow presentation. Clause 8 of SBVR is clearly broken in this regard. The result is significant lack of clarity, making detection of errors unnecessarily difficult. The possibility of misinterpretation (or non-comprehension) by software engineers and other readers is high. 
 
Resolution: Apply the ISO 1087 rule about sequencing vocabulary entries rigorously. This re-sequencing requires no changes in the entries themselves (but does suggest some). Two files containing all Clause 11 entries are attached. One file is unchanged except that entries are numbered. The other file is re-sequenced. The entry numbers reappear in the re-sequenced file indicating the original location of each entry. New subheadings are suggested.

There are two minor ambiguities in definitions of types of noun concept: 
1.	‘unitary concept’ is defined as ‘individual concept or general concept that always has at most one instance’ .
This is ambiguous because it is not clear whether ‘that always has at most one instance’ applies to both ‘individual concept’ and ‘general concept’ or only to ‘general concept’.
2.	‘individual concept’ is defined as ‘concept that corresponds to only one object [thing]’ (adopted from ISO 1087-1)
This is ambiguous because it is not clear whether ‘only’ means ‘exactly one’ or ‘at most one’. The second note in the entry says “While each referring individual concept has at most one and the same instance …” suggesting that ‘only’ means ‘at most one’. 
Also, terms used for types of noun concept do not match their definitions.  In SBVR, ‘concept’ includes both ‘noun concept’ and ‘verb concept’, but some terms use ‘concept’ for ‘noun concept’. For example, the definition for ‘general concept’ is for a specialization of ‘noun concept’. 
Discussion:
The terms for types of noun concept became a concern after ‘fact type’ was replaced by ‘verb concept’ in Clause 8. 
Resolution:
Update the definitions of ‘unitary concept’ and ‘individual concept’ to remove the ambiguities. 
Throughout the specification, replace the terms ‘general concept’, ‘unitary concept’ and ‘individual concept’ with, respectively, ‘general noun concept’, ‘unitary noun concept’ and ‘individual noun concept’
Revised Text:
On printed page 21 in Clause 8.1.1 

REPLACE
unitary concept
Definition:	individual concept or general concept that always has at most one instance
General Concept:	noun concept

WITH
unitary noun concept
Definition:	general noun concept that always has at most one instance or individual noun concept

On printed page 22 in Clause 8.1.1 

REPLACE
individual concept 	FL
Source:	ISO 1087-1 (English) (3.2.2) [‘individual concept’]
Definition:	concept that corresponds to only one object [thing]
General Concept:	unitary concept
Concept Type:	concept type
Necessity:	No individual concept is a general concept.
Necessity:	No individual concept is a verb concept role.


WITH
individual noun concept 	FL
Source:	based on ISO 1087-1 (English) (3.2.2) [‘individual concept’]
Definition:	noun concept that corresponds to at most one thing
General Concept:	unitary noun concept
Concept Type:	concept type
Necessity:	No individual noun concept is a general noun concept.
Necessity:	No individual noun concept is a verb concept role.


UPDATE NOUN CONCEPT TERMS:

REPLACE the signifier “general concept” WITH “general noun concept” 
… list of replacement locations to be provided

REPLACE the signifier “unitary concept” WITH “unitary noun concept” everywhere
REPLACE the signifier “individual concept” WITH “individual noun concept” everywhere except for the “Source” subentry reference to ISO 1087-1 in the entry for the concept currently termed “individual concept’

UPDATE DIAGRAMS:

REPLACE the following diagrams WITH diagrams that replace the signifiers “general concept”, “unitary concept” and “individual concept” with, respectively,  “general noun concept”, “unitary noun concept” and “individual noun concept”:

•	Figure 8.1
•	Figure 9.3
•	Figure 11.2
•	Diagram in Clause 13.4 on printed page 198

In clause 8.3.4, the term 'verb concept wording' is defined as:
"representation of a verb concept by an expression that has a syntactic structure involving a signifier for the verb concept and signifiers for its verb concept roles"


In the same clause, the term 'noun form' is defined as:
"verb concept wording that acts as a noun rather than forming a proposition"


One would expect therefore, that a noun form of a verb concept would be a gerund, such as 'car transfer' for 'branch1 transfers car to branch2',  where the 'noun form' denotes the same actualities as the verb concept.


But only the last Example (which is hard to understand because of a particularly bad choice of verb) is said to be about gerunds.  The other examples clearly are not.  The first Example is: "'transferred car of car transfer' for the verb concept 'car transfer has transferred car'. This form yields a transferred car."


The instances of 'car transfer has transferred car' are actualities of a car being involved in a car transfer.  But the cited text says the instances of the 'noun form' 'transferred car of car transfer' are cars, not actualities.  Similarly, the interpretation of the other two examples of 'noun forms' correspond to numbers, not actualities.


So the instances of a noun form of a verb concept need not be instances of the verb concept!  The noun form therefore cannot be a 'verb concept wording'.  The noun form does not represent the verb concept!


It appears that there are two different concepts here.  Noun form 1 is "verb concept wording that acts as a noun."  That is the gerund in the last Example. In the other examples, the noun form represents a derived concept that is what SBVR calls a 'situational role'.  The intent of 'noun form 2' is "representation of a situational role by an expression that has a syntactic structure involving a signifier for the verb concept that the role is derived from and signifiers for some of its verb concept roles".


Finally, use of noun form 2 in declaring a glossary item for a situational role would be preferable to using only the role designation.  In particular, the explicit appearance of other role placeholders in the noun form would permit them to be used directly in defining the situational role.


For example:
cardinality
Definition: nonnegative integer that is the number of distinct elements in a given set or collection


could be declared with the noun form:
_cardinality_ of _set_
Definition: nonnegative integer that is the number of distinct elements in the set

Inadequate, Overlapping and Disorganized Specifications for Sets and Collections of Concepts, Meanings, and Representations

Problem:

Assumptions

Two assumptions are basic to the eight points of this problem statement:
•	SBVR must provide a business vocabulary for business people and business analysts to talk clearly and precisely about terminological dictionaries and rulebooks and what they represent. 
•	The various aspects of this Issue must be addressed holistically. They can be resolved only by unifying, normalizing and completing all related specifications. (Thus, the need for a new unifying Issue.)

Problems

1. A known problem in SBVR is that the current version does not make clear what the fundamental unit of interoperability in SBVR is. No matter how that issue is resolved the unit should:
•	Be identifiable from a business point of view.
•	Not always have to be the full, non-redundant set of concepts, meanings, or representations.
The existing content of Clause 11 does not currently provide an adequate term for the second of these. This Issue proposes “collection” for that purpose. 

Note: The term “collection” in the following discussion is never actually used on its own. Rather, it always appears with qualification – e.g., ‘collection of representations’. 

2. Another known problem in SBVR centers on the use of the word “container” in e-mails and discussion. (Use of the signifier “container” per se is not part of this Issue.) It is unclear (to some) whether “container” refers to the ‘thing that contains’, to ‘what is contained’, or to both. The term is easily misused and misinterpreted. Also there are many variations of what is (or could be) contained (e.g., sets, collections, etc.). SBVR needs a precise, non-overlapping vocabulary for these things from a business point of view.

3. Another known problem in SBVR is that the existing content of Clause 11.2.2.3 “communication content” (a.k.a. “document content”) is not adequate for all purposes to which it might be put. SBVR needs a richer (but still minimal) set of concepts to address this area.

4. Certain existing terms in the existing content of Clause 11 (e.g., ‘terminological dictionary’ and ‘rulebook’) conflate ‘completeness and non-redundancy’ (i.e., being a set) with ‘primary purpose’ or ‘essence’. This conflation needs to be eliminated. In the real world for example, a rulebook does not have to be complete (e.g., it may contain only what is appropriate for a given audience), and it does not have to be non-redundant. It can contain the same rule statements in different sections, the intent being to provide the greatest clarity when being used by members of some speech community.

5. SBVR currently provides no means to talk about a collection of representations that is complete with respect to one or more specific concepts, but not complete with respect to all concepts in the body of shared meanings. Example: A listing of all baseball rules that address the concepts “strike” and “ball” only.

6. With respect to interoperability there is a minimum set of pragmatic business specifications (such as completeness, effective date, shelf life, mutability, etc.) needed for things communicated. SBVR does not currently support such specifications. 

Note: There is no intent or need to get into document management or rule management. The dividing line is this: SBVR does not get into organizational issues (e.g., author, sponsor, reviewer, etc.), workflow issues (e.g., status, pre-approval distribution, sign-off, impact assessment, etc.), motivation (rationale, goals, risks), etc. SBVR must, however, provide minimum viability criteria for any sets or collections communicated. Otherwise the communicated content is not really useful and trustworthy on the receiving end. Consequently the purpose of interoperability is defeated.

7. Certain kinds of collections relevant to inter-operability are missing from the current content of Clause 11 – most notably ‘record’ (not IT ‘records’). Proper incorporation of this and other kinds of collections is needed.

8. Issue 16103, which addresses “speech community representation”, needs to be worked into a holistic solution. 

New SBV issue: Distinguishing the senses of infinitive and present tense
From Don Baisley
 
There are many verbs for which the present tense of a verb conveys a particularly different sense than the infinitive. The difference I refer to is not about "the present time", but about "occurring at least occasionally". For example, the statement that "Pam surfs" (present tense) combines the meaning of "to surf" (the infinitive) and the meaning that “it happens at least occasionally”.
 
For such verbs, there is a challenge when using SBVR's typical pattern of defining verb concepts in the present tense. It tends to conflate the infinitive sense of a verb with the different sense meant by the present tense. That conflation causes problems. This is not an issue for ORM or other approaches that do not try to support natural language tense in a generic way. The problem has no apparent impact for many verbs where the present tense sense of "occurring at least occasionally" is inconsequential or inapplicable. The problem is especially troublesome for eventive verbs. Most SBVR verbs are stative, so the problem has tended to go unnoticed in the SBVR vocabulary itself.
If supporting tense in a generic way, in logical formulations, the other tenses should be built on objectifications that start with the infinitive sense of a verb, not with the present tense. Also, modal operations like obligation build on the infinitive sense.

For examples below, I define verb concept forms for generic "tense" concepts using the verb "occurs" (where the there is a role that ranges over the concept 'state of affairs'). The choices of signifier and form are arbitrary (not necessary), but seem to convey the sense of the tenses naturally.

Example:
'person surfs' (present tense)
'person surf' (the infinitive sense)

Where someone puts 'person surfs' in a business glossary, there is an underlying verb concept that has the sense of "to surf", the infinitive. I show it here in examples as 'person surf' (leaving out the infintizing "to"). This underlying verb concept is necessary to correctly formulate other tenses, and even necessary to formulate use of the present tense in some cases, which I will show later.

Here are several examples of statements and interpretations using generic tense concepts built on the verb "occur". To be terse, I show objectification using brackets.

Pam surfs.
[Pam surf] occurs

Pam is surfing.
[Pam surf] is occurring

Pam was surfing.
[Pam surf] was occurring

Pam has been surfing.
[Pam surf] has been occurring

Pam surfed.
[Pam surf] occurred

Pam will be surfing.
[Pam surf] will be occurring

Pam will surf.
[Pam surf] will occur

Pam will have been surfing.
[Pam surf] will have been occurring
 
The second example above, "Pam is surfing", can serve to illustrate the need to build on the infinitive rather than the present tense sense. To build on the present tense would be to say the thing that “is occurring” is Pam surfing at least occasionally, which is incorrect.  The present continuous and other tenses do not include the present tense sense of occurring at least occasionally, so they cannot rightly be built upon a concept that conveys that sense.
 
I said above I would show where the infinitive sense is sometimes needed even for the present tense. Here is a case where the infinitive 'person surf' concept is needed to formulate a statement that uses "surf" only in the present tense:

Pam talks while she surfs.

Wrong Interpretation I1: [Pam surfs] occurs while [Pam talks] occurs

I1 misses the key sense of the statement, because [Pam surfs] (present tense) means that surfing is something Pam does at least occasionally and [Pam talks] means that talking is something that Pam does at least occasionally. I1 applies 'state of affairs1 occurs while state of affairs2 occurs' to the wrong states of affairs (the states in which Pam occasionally surfs and Pam occasionally talks).

Right Interpretation I2: [[Pam surf] occur while [Pam talk] occur] occurs

I2 correctly factors out the tense and applies it at an outer level (as we often do with modal operations). The conjunction joins objectifications of the underlying sense of "to surf" and "to talk" without the added meaning of the present tense (that the surfing or talking is at least occasional). The sense of present tense (happening at least occasionally) is then added at the outside where it applies to the simultaneous actions.
 
SBVR does not prevent verbs concepts from being defined in glossaries in the infinitive , as is typical of dictionary definitions of verbs.  That approach has always been available.  But that approach is not used in SBVR’s own glossary and examples.  In general, the sense of “occurs at least occasionally” is absent from SBVR’s own verb concepts, so the distinction is unimportant.  But business rules and facts run into the problem.  E.g., a EU-Rent rule about whether a renter smokes vs. a rule about whether he is smoking when in a rental car.

Recommendation:

It will be best to resolve this in a way that does not disturb the business-friendly approach of showing verb concept readings in the present tense.  It might be possible to define a pattern in SBVR Structured English by which verb concepts with an infinitive sense are implied where present tense versions are explicitly presented in a glossary.
 
Examples of formulations need to show the distinction.  Existing examples should be examined and fixed as needed.  New formulation examples might be helpful to demonstrate using generic tense concepts to build on a root verb concept.
None of this changes the meaning of 'state of affairs' or 'objectification', but understanding this issue and its solution might help bring clarity to some of the examples that have been discussed.

The definitions in most of the model entries in Clause 8.1.2 do not align with Clause 9 and Clause 10 modal definitions.
Resolution:
Align the definitions in Clause 8, 9 & 10 by changing the definitions in Clause 8; adding an intermediate concept to make the definition of “proposition is permitted to be true” intelligible to business people; and adding a definition for “actual world” to Clause 10.
Revised Text:
REPLACE the Definition in the entry for “proposition is necessarily true” in Clause 8.1.2 on printer page 26:

Definition:	the proposition always corresponds to an actuality 

WITH:

Definition:	the proposition corresponds to an actuality in all possible worlds


REPLACE the Definition in the entry for “proposition is possibly true” in Clause 8.1.2 on printer page 26:

Definition:	it is possible that the proposition corresponds to an actuality

WITH:

Definition:	the proposition corresponds to an actuality in some possible world

Add a new Entry after the entry for “proposition is obligated to be true” in Clause 8.1.2 on printer page 26:

proposition is obligated to be false
Definition:	the proposition does not correspond to an actuality in any acceptable world


REPLACE the Definition in the entry for “proposition is permitted to be true” in Clause 8.1.2 on printer page 27:

Definition:	the proposition corresponds to an actuality in at least one acceptable world.

WITH:

Definition:	the proposition is not obligated to be false 



REPLACE the Definition in the entry for “permissibility formulation” in Clause 9.2.4 on printer page 57:

Definition:	modal formulation that formulates that the meaning of its embedded logical formulation is true in some acceptable world

WITH:

Definition:	modal formulation that formulates that the meaning of its embedded logical formulation is permitted to be true

ADD immediately after the entry for “acceptable world” in Clause 10.1.2 on printed page 111 the following new entry:

actual world
Definition:	the possible world that is taken to be actual for some purpose, in particular, for the conduct of business and the application of business rules
Note:	the actual world is a set of things, situations and facts about them that some person or organization takes to be true for some purpose.  In most cases, it is the best estimate of the actual state of the world that is of interest at a particular time.

ftp://ftp.omg.org/pub/issue-attachments/17599/17599.doc

SBVR v1.1 Clause 8 says:
  Note: in the glossary entries below, the words “Concept Type: role” indicate that a general concept being defined is a role.
Because it is a general concept, it is necessarily a situational role and is not a verb concept role.


How does one declare an attributive role that is not a general concept?


SBVR v1.1 appears to use such declarations to also declare roles that are attributive roles of a given noun concept and thus also in the attributive namespace of the noun concept.  For example, clause 8.6 declares 'cardinality', which is an attributive role of integers with respect to 'sets', in a glossary entry with Concept type: role.  But 'cardinality' is not a general concept; nothing is a 'cardinality', full stop.  An integer can only be a 'cardinality' OF something. it is a purely attributive term.  As a term for a general concept, 'cardinality' is thus a term in the Meaning and Representation namespace; it has no 'context'.


The problem arises in defining attributive roles of general noun concepts, such as 'occurrence has time span' and 'schedule has time span', where the definitions of the two roles are importantly different because they are attributes of different general concepts that are only similar in nature.  Neither is a situational role. That is, neither is a general concept. No time interval is a 'time span', full stop.  A time interval must be a time span OF something.  One 'time span' is in the attributive namespace of 'schedule', and a different 'time span' designation is in the attributive namespace of 'occurrence'.  Neither is in the DTV.Situations vocabulary namespace per se.  How can this be declared using SBVR conventions?  Declaring them both in glossary entries with Concept Type: role apparently makes them conflicting designations for 'situational roles' in the DTV.Situations vocabulary.


Does simply declaring the verb concept 'occurrence has time span' declare the attributive role?  If so, how is the range of the role declared?  And where does the definition of the attributive role go?

There are four small but inportant wording additions need to clarify three entries in the Clause 10.1.2:
•	In “possible world” and “universe of discourse” the word “object” has the signifier “thing” in sBVR
•	Make it clear that the “at some point in time” is the “present time of the possible word” as set forth in SBVr Clause 10.1.1.
•	The referents of “corresponding propositions or states of affairs” at the of the definition for ‘state of affairs’ is not clear.
Resolution:
Make the clarifications as identifed in Issue Summary.
Revised Text:
ADD in the second sentence in the Note in the entry for “possible world” in Clause 10.1.2 on printed page 117 after the phrase “any given set of objects”:

[things]


ADD to the end of the last sentence in the Note in the entry for “possible world” in Clause 10.1.2 on printed page 117:

Thus, in the context of a static constraint declared for a given business domain, a “possible world” would correspond to (but not be identical to) a state of the domain’s fact model that could exist at some point in time.

the following text:

, which is the “present time” of the possible world.“

ADD the word “respectively” at the end of the Definition in the entry for “state of affairs” in Clause 10.1.2 on printed page 119 after the phrase “set of objects”:


ADD at the beginning of the Definition in the entry for “universe of discourse” in Clause 10.1.2 on printed page 120 after the phrase “set of objects”:

[things]

SBVR is intended for development of semantic models of businesses (and enterprises run on similar lines, such as public sector bodies and not-for-profit organizations). Its scope says “This specification defines the vocabulary and rules for documenting the semantics of business vocabularies, business facts, and business rules”. 
A lot of SBVR RTF email and teleconference discussion seems to be taken up with examples that are at best tenuously related to business, and often not at all related to business. There is, of course, no reason that people should not use SBVR as SVR – Semantics of Vocabulary and Rules – for any universe of discourse, whether business-related or not. But it is important to keep focus on what SBVR is intended for. 
Dependencies with other Issue Resolutions:
None
Discussion:
There are two aspects of keeping SBVR’s focus on business:
1.	The context of an SBVR model of a business – a body of shared concepts, represented as one or more terminological dictionaries and rulebooks – is the actual world in which the business operates.
2.	The content of an SBVR model of a business is the meanings of the definitions of relevant things, relationships and guidance in the business. 
The universe of discourse is the part of the business selected by the business owners to be within scope. For example, in EU-Rent (as used in the SBVR specification) it is car rentals as opposed to finance, car purchasing and sales, premises management, HR, etc. 
This issue is about a matter of SBVR practice and can be addressed with notes (or perhaps in more general editorial).
Resolution:
Add notes under the entry for ‘body of shared meanings’:
•	To describe the universe of discourse modeled by the body of shared meanings
•	To emphasize that the body of shared meanings comprises only meanings

Revised Text:
In 11.1.1.2, under the entry for body of shared meanings, add the following notes:
Note:	When modelling a business (such as EU-Rent), the universe of discourse is bounded by what the business owners decide is in scope. That would be the actual world of some part of EU-Rent’s business (e.g. rentals, as opposed to, say, premises management, purchase/sales of cars, or HR) and some possible worlds that are reachable from the actual world. If the EU-Rent owners say that they are considering renting RVs or starting up in China, then possible worlds that include these kinds of business are in the universe of discourse. 
If EU-Rent is not considering renting construction equipment or camping gear, then possible worlds that include these kinds of business are not in the universe of discourse – and neither are possible worlds that include impossibilities. Whether ‘Kinnell Construction rented backhoe 123 on 2012-08-28’ or ‘John rode into work on a unicorn’ correspond to states of affairs or not, are not relevant to EU-Rent. They are out of scope. 
In-scope propositions may have to be constrained by necessities to ensure that they are not impossible. e.g. ‘Necessity: Each rental car is stored at at most one branch [at any given time].’ 
Note:	A body of shared meanings contains meanings of:
•	noun concepts that define kinds of thing in the universe of discourse
•	verb concepts that define relationships between kinds of thing in the universe of discourse
•	elements of guidance that constrain or govern the things and relationships defined by the concepts.
It does not contain ground facts or facts derived from ground facts (other than as illustrative examples), or things in the universe of discourse, or information system artifacts that model things in the universe of discourse – although it may provide vocabulary to refer to them. 

Title:	Fix the anomaly in the subcategory structure of ‘concept’ to include ‘individual verb concept’ in SBVR
Source:
RuleML Initiative, John Hall, (john.hall@modelsystems.co.uk)
Summary:
SBVR handles noun concepts and verb concepts asymmetrically:
•	‘concept’ generalizes ‘noun concept’ and ‘verb concept’ 
•	‘noun concept’ generalizes ‘general concept’ and ‘individual concept’ – i.e. ‘general concept’ means ‘general noun concept’ and ‘individual concept’ means ‘individual noun concept’ 
There are no equivalents for ‘verb concept’. SBVR does not explicitly define ‘individual verb concept’, so cannot say:
•	‘individual concept’ generalizes ‘individual noun concept’ and ‘individual verb concept’ (inheriting from: ‘concept’ generalizes ‘noun concept’ and ‘verb concept’)
•	‘verb concept’ generalizes ‘general verb concept’ and ‘individual verb concept’ (paralleling: ‘noun concept’ generalizes ‘general noun concept’ and ‘individual noun concept’)
If it did, this structural inconsistency would be removed. 
It would also be helpful in using SBVR. Individual noun concepts, such as “EU-Rent” and “Luxembourg”, are useful in defining bodies of shared meanings in SBVR. If SBVR included ‘individual verb concept’, an SBVR body of shared meanings could include individual verb concepts such as “EU-Rent is incorporated in Luxembourg”. 
Resolution:
1.	Change the preferred term that is currently ‘individual concept’ to ‘individual noun concept’ to clarify that it applies to noun concepts only
2.	Add the concept ‘individual verb concept’ for a proposition that is a Clause 8 verb concept with all its roles quantified (closed) by individual (noun) concepts to fix the anomaly in the subcategory structure of ‘concept’.

Revised Text:
On printed page 22 in Clause 8.1.1 
REPLACE the current term heading “individual concept” WITH “individual noun concept” 

And REPLACE “concept”, the first term in the definition, WITH “noun concept”


On printed page 27 in Clause 8.1.2 at the end of the clause ADD this entry for ‘individual verb concept’:

individual verb concept

Definition:	Definition to be replaced
proposition that is based on exactly one verb concept in which each verb concept role is filled by an individual noun concept
	… some explanatory comments
Example:	… some illustrative examples


REPLACE the signifier “individual concept” WITH “individual noun concept” in the following places (but not in the “Source” subentry reference to ISO 1087-1 in entry for the concept current termed “individual concept’)

•	… to be identified and added 


REPLACE the following diagrams WITH diagrams that repolace the signifier “individual concept” with “individual noun concept”:

•	Figure 8.1
•	Figure 9.3
•	Figure 11.2

… plus fixes for any additional side effects

The DTV RTF has pointed out the value of adding to SBVR a very generic concept for all kinds of occurrences so that all specifications that define a particular kind of occurrence, e.g. occurrence in time, occurrence in space, can be consistent if they adopt and specialize the SBVR generic occurrence concept.  This approach also provides the ability of specifications that deal with occurrence to constrain the generic concepts adopted from SBVR to fit their specification.
Resolution:
1.	Incorporate that a state of affairs is not a meaning in its definition.
2.	Add a generic, overarching ‘occurrence’ noun concept.
3.	Add a “what happens” noun concept that is a role of ‘state of affairs’.
4.	Add a verb concept that defines the multiple relationship between “what happens’ and ‘occurrence’.
5.	Fix the definiiton of ‘state of affairs is actual’ 
6.	Clarify the Note for ‘actuality’.
7.	Remove confusing and unnecessary wording in the entry for ‘situation’.

Revised Text:
REPLACE Figure 8.8 in Clause 8.5 on printed page 40 WITH:

 

In clause 8.5, in the entry for 'state of affairs', REPLACE the Definition:
Definition:	event, activity, situation, or circumstance
with
Definition:	res that is an event, activity, situation, or circumstance
In clause 8.5, immediately before the entry for 'state of affairs is actual', INSERT three new entries:
occurrence 
Definition:	state of affairs that is the happening of another state of affairs for a given time interval and/or at a given location and/or in some other dimension
what-happens state of affairs
Definition:	state of affairs that can happen for a given time interval and/or at a given location and/or in some other dimension
what-happens state of affairs has occurrence 
Definition:	the occurrence is the realization of the state of affairs 
In clause 8.5, in the entry for 'state of affairs is actual', REPLACE the existing Definition:
Definition:	the state of affairs happens (i.e., takes place, obtains)
with: 
Definition:	the state of affairs is happening (i.e., takes place, obtains)

In clause 8.5, in the entry for 'actuality', REPLACE the Note:
Note:	Actualities are states of affairs that actually happen, as distinct from states of affairs that don’t happen but nevertheless exist as subjects of discourse and can be imagined or planned.
with:
Note:	Actualities are states of affairs that are actually happening, as distinct from states of affairs that are not happening but nevertheless exist as subjects of discourse and can be imagined or planned.

In clause 11.1.5.2, in the entry for 'situation' on printed page 154, REMOVE 
•	The phrase “that provides the context from which roles played may be understood or assessed” at the end of the Definition as it is about purpose and not essential meaning.
•	the words “a state of affairs” at the end of the first Dictionary Basis.

ADD two noun concepts, ‘occurrence’ and ‘what-happens state of affairs’, to the following line in the paragraph beginning with “The classes in the metamodel that mirror …” in 13.2.2 “MOF Classes for SBVR Noun Concepts”:

Clause 8:	meaning, concept, expression, state of affairs, actuality, thing, set

ADD two noun concepts, ‘property’ and ‘viewpoint’, to the following line in the paragraph beginning with “The classes in the metamodel that mirror …” in 13.2.2 “MOF Classes for SBVR Noun Concepts”:

Clause 11: community, situation, res

Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
Summary:
During recent in-depth SBVR RTF discussion on the topic of state of affairs a number of clarifications and fixes were identified as needed:
1.	Add a missing Reference Scheme for ‘state of affairs’.
2.	Add a Necessity to unambiguously distinguish states of sffairs from propostions.
3.	Add a Note to clarify how the representations of the meanings in the reference schemes of state of affairs serve as definite descriptions of the state of affairs.
4.	Clarify the relationship between 'is actual' and 'exists', and the relationship between actualities and potential states of affairs.
Resolution:
Makr the the fixes and add the clarifications as identified as being needed in the Issue Summary list above.
Revised Text:

ADD the following Reference Scheme, Necessity and  Note  to the “state of affairs” entry in Clause 8.5 on printed page 40: 

Reference Scheme:	an individual noun concept that corresponds to the state of affairs
Necessity:	No state of affairs is a proposition.
Note:	Any representation of a proposition may be used to denote the state(s) of affairs that it corresponds to.  A proposition statement serves as a definite description for the state of affairs that the proposition coressponds to.    


In the entry for “state of affairs is actual” in Clause 8.5 on printed page 40, REPLACE the Note and the Example:

Note:	The meaning of ‘is actual’should not be confused with ‘exists,’ meaning existential quantification. A state of affairs can exist and thereby be involved in relationships to other things (e.g., plans, desires, fears, expectations, and perceptions) even if it is not actual, even if it never happens.
Example:	“The EU-Rent London-Heathrow Branch wants to be profitable”. Even when that branch is unprofitable, the previous statement can correspond to an actuality that involves the state of affairs that the EU-Rent London-Heathrow Branch is profitable. The state of affairs exists as an object of desire and planning regardless of whether it is ever actual. The state of affairs is actual only when the branch is profitable, but it exists and is involved in an actuality (an instance of the verb concept ‘company wants state of affairs’) even when the branch is unprofitable.

WITH:
Note:	The meaning of ‘is actual’should not be confused with logical existence, which just means being a thing in the possible world that is of interest. A potential state of affairs can 'exist' as a 'thing' in the possible world and thereby be involved in relationships to other things (e.g., plans, desires, fears, expectations, and perceptions) even if it is not actual, even if it never happens.
Example:	“The EU-Rent London-Heathrow Branch wants to be profitable”. Even when that branch is unprofitable, the previous statement can correspond to an actuality that involves the desired state of affairs that the EU-Rent London-Heathrow Branch is profitable. The desired state of affairs exists as an object of desire and planning regardless of whether there is ever an actual state of profitability. It exists and is involved in an actuality (an instance of the verb concept ‘company wants state of affairs’) even when the branch is unprofitable. The nature of the desired state of affairs is that it is a 'desired state of affairs' -- conceived, not perceived.
The actual state of affairs that the EU-Rent London-Heathrow Branch is profitable exists only when the branch is profitable.  The nature of the actual state of affairs, if it exists, is that it is a happening in the world.  It is perceived, not conceived. 

In the list of Necessities” in Clause 8.5.2 on printed page 41, REPLACE:

Necessity: Each proposition corresponds to at most one state of affairs.

WITH:

Necessity:	Each proposition corresponds to exactly one state of affairs.

The SBVR document is far larger than optimal. It needs to be reduced in size. Many of the Annexes do not contribute directly to core content.

Resolution

Delete Annexes that are not essential to the SBVR specification. Evaluation of the Annexes:

Annexes essential to the correct interpretation of the normative specification and that must be kept: 
Annex C - SBVR Structured English 
Annex E - EU-Rent Example 
Annex H - Use of UML Notation in a Business Context to Represent SBVR-Style Vocabularies 
Annex M - Additional References 
Annexes that are not essential and can be deleted. Their owners can choose whether to publish them independently: 
Annex F - The RuleSpeak® Business Rule Notation* 
Annex G - Concept Diagram Graphic Notation 
Annex I - The ORM Notation for Verbalizing Facts and Business Rules* 
Annex J - ORM Examples Related to the Logical Foundations for SBVR 
Annex L - A Conceptual Overview of SBVR and the NIAM2007 Procedure to Specify a Conceptual Schema 
The SBVR RTF should decide on a case by case basis whether the following Annexes are essential to the correct interpretation of the normative clauses or can be deleted: 
Annex A - Overview of the Approach 
Annex B - The Business Rules Approach 
Annex D - SBVR Structured English Patterns 
Annex K - Mappings and Relationships to Other Initiatives 
*To be discussed by the RTF: Since (a) SBVR-SE is not normative, and (b) RuleSpeak and ORM (Norma) served as reference notations in creating the specification, it might be useful to illustrate parts or all of Annexes C and/or E, and/or examples given in the specification itself, in these other two notations. Annexes F and I already did something like this, but (a) are much too large, (b) not well-focused on complementing SBVR, and (c) may need to be revised.

Simplification of SBVR by Integrating Clauses 8 & 11 which Cover the Same Topics and Removing Multiple Compliance Points
Source:
Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com)
Summary:
It is not possible to see all of the SBVR “Meaning and Representation” model constructs (terminological entries) on the same subtopics in one place because there are split almost evenly between Clause 8 and Clause 11.
Since “Meaning” and “Representation” are the foundation topics of SBVR, this is a particularly significant problem.
It is not easy to see how the whole of SBVR fits together on any one topic.  Ambiguities, inconsistencies, and internal disconnects, which lead to significant confusion and misinterpretation, are masked and therefore persist.
In addition there are a number of Issues that require moving terminological entries between Clause 8 and Clause 11, with equal arguments for having then in both Clauses.
Further, it is not possible to re-sequence the entries in Clause 8 and Clause 11 in a cohesive way while those two clauses remain as separate top level SBVR Clauses.
Part of the simplification of SBVR to gain full benefits should follow the example of Simplified UML.  UML v2.5 has removed separate conformance levels related to subject areas and relies on vendors providing lists of specific model constructs that they support.  
SBVR already has a very formal requirement for providing list of model constructs supported.  Since conformance is already defined in SBVR at the terminological entry level, removing the four level 1 Clause conformance levels will free up the structure of SBVR Clauses to enable the principles below to be implemented.
Resolution:
1.	Integrate the terminological entires in Clauses 8 and 11 by subtopic.
2.	Remove the four Comformance Levels following the example of UML 2.5.
Revised Text:
… to follow

Title:	SBVR needs a consistently applied policy for styling or not styling signifiers 
Source:
John Hall, RuleML Initiative
john.hall@modelsystems.co.uk
Summary:
There is some inconsistency in the SBVR specification regarding which signifiers are styled and which are not.
A policy needs to be agreed and applied consistently through the SBVR specification.
Resolution:
1.	Style each use of the signifier of a concept (e.g. ‘thing’, ‘meaning’) where that use has the specific meaning defined in its SBVR entry;
2.	If the signifier of a defined concept has an everyday English meaning that is different from its SBVR definition, don’t style uses of it where the everyday meaning is intended;  
3.	Add a paragraph to the introduction explaining the basis for styling/not styling.

I spotted some typos in the logics table on p. 100  (PDF p. 114) of the SBVR 1.1 Convenience draft.  Attached is an annotated screenshot of the errors.  


To summarize, the errors are in column 3 of the deontic section:


the bold, capital letters need to be in italics (to match the legend on the following page, as well as the other places where these symbols appear).


the small 'p' needs to be in italics (to match the legend on the following page, as well as the other places where this symbol appears).

The problem statement: The Annex is out of date with respect to RuleSpeak notation, probably the newly released version of EU-Rent, and perhaps newer aspects of SBVR itself. 

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


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


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



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


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


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


Any ideas?

In Clause 12.1.3 the preferred term for enforcement of a behavioral (operative) business rule is 'level of enforcement'. This concept is used only in examples in the specification -  SBVR itself contains no behavioral business rules. In some examples (including the one in Clause 12.1.3) the older term 'Enforcement Level' is used. 'Enforcement Level' is not defined as a synonym for 'level of enforcement'.

An editorial correction is needed to replace each occurrence of 'Enforcement Level' with 'level of enforcement'.

        I've used "enforcement level" for many years in the Business Rule Concepts book, including the 4th edition out just this month. I'll be quite surprised if anyone doesn't consider "enforcement level" and "level of enforcement" to be synonyms(?).

Thanks,
Ron

The objectification example “EU-Rent reviews each corporate account at EU-Rent Headquarters” in SBVR v1.1 clause 9.2.7 (as modified per the resolution to issue 16309), is expressed in the usual sequence of sentences.  The formal logic interpretation of those sentences is:  
 For each corporate account A, there exists a state of affairs S such that 

  S  objectifies “EU-Rent reviews A”, 

  and S occurs at EU Rent HQ.

 

Now, per Clause 8 there is only one such state of affairs; and its existence is a given, that is, for every proposition of the form ‘company reviews account’, the corresponding state of affairs necessarily exists.  But nothing is said here about that state of affairs being actual.  Moreover, since there is probably more than one “occurrence” of that state of affairs, the definition of ‘state of affairs occurs at place’ would be less than obvious.  Or is it the intent that there is only one review of each corporate account?  Whatever it means for an abstract state of affairs (that might be a set, including the empty set) to ‘occur at a place’, it is not clear, and it is important to the example of objectification – what is the state of affairs that it produces.  

 

In SBVR v1.0,  the variable S ranges over the verb concept ‘company reviews account’, because the instances of the verb concept were then said to be actualities.  The resolution of Issue 14849 makes instances of a verb concept ‘states of affairs’ instead of actualities.  But states of affairs need not be actual. It is obvious that some thought was given to this example, because v1.1 changed it.  What is not clear is whether it is any closer to what was intended.

 

A definition of ‘state of affairs occurs at place’ should probably follow the DTV pattern for ‘state of affairs occurs at time’.  In DTV parlance, what was intended is:  Each occurrence of the state of affairs “EU Rent reviews A” ‘occurs at’ EU Rent HQ.  But SBVR lacks the vocabulary to express that.

 

In SBVR clause 8.5.2, the following Necessity appears:  

Necessity: If a concept[sub]1 is coextensive with a concept[sub]2 then the extension of the concept[sub]1 is the extension of the concept[sub]2.

(where [sub] is used to show subscripts).

 

There are three problems with this Necessity:

1.  This Necessity just restates the definition of ‘concept is coextensive with concept’ in 8.1.1.1.  It adds nothing.

2.  It is the only occurrence in SBVR v1.1 of the use of a subscript outside of a placeholder term, and that use is not defined in Annex C.

3.  The meaning of the article ‘a’ before concept (1) and concept (2) is universal in this case, not existential, which contradicts Annex C.

 

Delete it!

The Date Time Vocabulary specification contains several Definitions and Necessities that use subscripted terms, e.g.,

 

Necessity: For each time interval(2) and each time interval(3) that finishes time interval(2), the duration of the time interval(1) that starts time interval(2) complementing time interval(3) is equal to the duration of time interval(2) minus the duration of time interval(3).

 

time point1 to time point2 specifies time period

Definition: time point(1) is the first time point of a time point sequence and time point(2) is the

last time point of the time point sequence and there is a time point(3) that is just before time point(2) in

the time point sequence and time point(1) through time point(3) specifies the time period

 

Each case introduces a subscripted term that is used to denote the same ‘referent’ ‘thing’ elsewhere in the definition/necessity.  In the Necessity, all the subscripts are introduced terms.  In the Definition, time point(1) and time point(2) refer to placeholders in the verb concept wording being defined, but time point(3) is an introduced term.  These introduced terms were patterned on a usage of subscripts in SBVR clause 8.5.2 that introduces similar “local names”.  SBVR Annex C does not describe such usages.  Without them, it is not possible to formulate these definitions and necessities in SBVR Structured English.  

 

Is it the intent of SBVR SE to support such usages?  If yes, then SBVR Annex C needs wording to support them.  If no, then DTV needs to convert these formulations to plain text.

In SBVR clause 8.3.4, in the entry for ‘placeholder’, it is stated that a placeholder exists in only one verb concept wording, and it refers to some role of the verb concept in that wording.  It follows that the two placeholders spelled ‘concept1’ in ‘concept1 specializes concept2’ and in the Synonymous form: ‘concept2 generalizes concept1’ (in 8.1.1.1) refer to two roles of the verb concept being defined.  Since these two placeholders spelled ‘concept1’ are different designations, how are they related?

 

Annex C.3.1 does not say anything about the relationship between placeholders in the primary verb concept wording and placeholders in synonymous forms.  (It just says something about subscripts being used to differentiate placeholders.)  The intent is that the placeholder expression represents the SAME verb concept role in ALL primary and synonymous forms.  That is, the placeholder is the SAME DESIGNATION in all verb concept wordings for the same verb concept.  The text of 8.3.4 contradicts this intent, saying that the placeholder only has meaning within a given verb concept wording.  If the text is correct, it is necessary to state some rule about the meaning of the same placeholder expression (the distinct designation) in the different synonymous forms.

 

Further, in the Definition of ‘concept1 specifies concept2’, the expression ‘concept1’ appears.  Since that expression only refers to a verb concept role within a verb concept wording, it is utterly meaningless in the Definition!  There are no placeholders in a Definition, and ‘concept1’ is not a signifier for any concept.  And yet, the intent is that ‘concept1’ in the Definition is the placeholder expression and is intended to be interpreted as a reference to the thing that plays that verb concept role in an actuality of ‘concept1 specializes concept2’.  Annex C says nothing about the use of placeholder expressions in Definitions, and 8.3.4 makes these usages meaningless, but they appear in every verb concept definition in SBVR.

 

It appears that the real intent is that a placeholder expression refers to one and the same verb concept role throughout the terminological entry for the verb concept, including at least all synonymous forms and definitions.  Whether it also refers to the verb concept role in embedded Necessities needs to be clarified (it is not clear that SBVR ever assumes that, but DTV apparently does).  The only aspect of a placeholder that is specific to a given verb concept wording is the ‘starting character position’, which suggests only that that relationship should be ternary, i.e., placeholder has starting character position in verb concept wording.