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 11647: mismatch between diagram
Issue 12165: URGENT SBVR.xsd issue
Issue 12437: Issue "fact type role is in fact type"
Issue 12531: editorial issue -- example is missing a line
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 12542: terminological dictionary
Issue 12543: A rulebook should have a URI
Issue 12589: "characteristic type" should be a "category type"
Issue 12614: SBVR typos
Issue 12849: fact type 'fact type form incorporates fact symbol' needs additional captio
Issue 12956: Note for individual concept does not follow from the Definition
Issue 13135: SBVR Issue: can a role range over multiple object types
Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540)
Issue 13139: Clean up and Complete Vocabulary for Clause 10.1.1
Issue 13150: Issue: SBVR Clause 8
Issue 13716: Definitions in subsection 11.1.5
Issue 13802: SBVR Issue: What is a fact type form
Issue 13803: SBVR Issue: Definition of signifier
Issue 13804: SBVR Issue: Model expression structure
Issue 13835: Use of the Signifier "Fact Model"
Issue 13836: Note for Is-Facet-of Fact (Type)
Issue 13849: SBVR did not pick up the ISO synonym "Part-Whole Relation
Issue 13850: The segmentation 'Thing in Context' is inconsistent with the definitions of 'role' and 'facet'
Issue 13851: Definition of Is-Property-Of Fact Type
Issue 13865: SBVR Issue : Inconsistent use/definition of keyword 'or'
Issue 13996: SBVR Fig 12-1 tweak
Issue 14029: Conflation of Proposition with "Proposition + Performative " plus Disconnect between Concept and Proposition
Issue 14241: Coexistence approach to SBVR
Issue 14843: Concepts-centric Model and Fact Model are different
Issue 14844: Move the Definitions in Subclause 8.5 to Clause 13
Issue 14849: Instances of Clause 8 fact type should be states of affairs
Issue 15008: Use of "denotes" in note for "state of affairs"
Issue 15124: Inconsistent use of terminology when relating facts to fact types

Issue 11647: mismatch between diagram (sbvr-rtf)

mismatch between diagram where speech community is associated with exactly one semantic community but 07-09-04 version of the XMI/CMOF has speech community mapping to multiple semantic community e.g. <ownedMember xmi:type="cmof:Association" name="semantic community has speech community" xmi:id="semanticCommunityHasSpeechCommunity" memberEnd="semanticCommunityHasSpeechCommunity.semanticCommunity semanticCommunityHasSpeechCommunity.speechCommunity"> <ownedEnd xmi:type="cmof:Property" name="semantic community" xmi:id="semanticCommunityHasSpeechCommunity.semanticCommunity" type="semanticCommunity" lower="0" upper="*"/> <ownedEnd xmi:type="cmof:Property" name="speech community" xmi:id="semanticCommunityHasSpeechCommunity.speechCommunity" type="speechCommunity" lower="0" upper="*"/> </ownedMember> 

The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>" 

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

In section 9.2.8, on page 70, the example for "aggregation formulation"
introduces several variables.   All but one of the introduced variables is
specifed as ranging over some concept.   For example, ". . . . The second
variable ranges over the concept ‘number’."


My issue: there is no corresponding "ranges over" line for the third
variable.   It is true (per 9.2.1) that variables need not range over any
concept.  But this example would be clearer if the "ranges over" line were
included for that third variable.


I believe this third variable is supposed to range over the concept 'set'.

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 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:
3) A terminological dictionary should be able to incorporate other
terminological dictionaries, as with "vocabulary incorporates vocabulary".
Otherwise, we cannot structure terminological dictionaries in parallel with
vocabularies

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:
4) A rulebook should have a URI, so that the rulebook can be addressed over
the Internet.

Section 11.1.2.2 "Kinds of Characteristic" on page 136 says that
"characteristic type" is "General Concept: concept type".  I suggest that
"General Concept: categorization type" would be more accurate.


Given this proposal, in EU-Rent, making "branch type" a "characteristic
type" would enable statements such as "if there exists a branch that is a
city branch ...."

attached is a dcument containing SBVR typos

p. 150 (PDF p. 162), Clause 11.2.1.2,
to the entry for 'fact type form incorporates fact symbol':


Add the following caption, to appear after the current Synonymous Form caption:



Synonymous Form:  fact type form demonstrates designation



using term styling where underlined (above) and verb styling for italics (above)


Also,  on this same page, there is a typo in the Definition caption under the entry for 'fact symbol':


In 'fact type form' (which ends the Definition) the first space needs to be underlined — i.e., apply term styling to the space.

Clause 8.1.1


Concept: individual concept


The Definition of 'individual concept' is:
 concept that corresponds to only one object [thing]


The Note says:
 "each referring individual concept has exactly one and the same instance in all possible worlds"


"Corresponds to only one object" (in any possible world) is not at all the same thing as "corresponds to exactly one and the same object in all possible worlds".  One of the definition and the Note should be corrected.  I would prefer changing the definition to match the note.


Note also that changing the definition means that "the President of the United States" is an 'individual concept' that denotes an office, but not a person.  And the concept "the person who is President of the United States" is _not_ an 'individual concept'.

The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types.

This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types.

Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type".

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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number.

 

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. 

A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. 

Title: What is a fact type form?
Specification:  SBVR
Version:  1.0
Source:  Ed Barkmeyer, NIST, edbark@nist.gov


Summary:


In SBVR, clause 8.3.4, 'fact type form' has the definition:
"representation of a fact type by a pattern or template of expressions based on the fact type".


According to clause 8.3(.0), 'representation' is "actuality that a given expression represents a given meaning".  Is "a pattern or template of expressions" an "expression"?  According to 8.2, a 'signifier' is "expression that is a linguistic unit or pattern [of sounds or symbols]".  So apparently there are expressions that are patterns and they can be signifiers.


Per 8.3.1, designation is the "representation of a concept by a sign", and a fact type is a concept, so it may have a representation that is a designation.  But the UML diagram shows that a fact type form is not a designation.  So presumably a 'pattern or template of expressions' is not a 'sign'. But a signifier, which is a pattern, must be a 'sign', because it is the expression that participates in a designation.  But the expression of a fact type form is apparently not a signifier, since only designations have a 'signifier' role, and a fact type form is not a designation.  The inconsistency in the terminology, and the failure to make clear parallels and distinctions, is very confusing.


It seems that the idea here is that an 'expression' can be a structure of individual sub-expressions, and that, in representing a fact type, the structure and the sub-expressions play distinct roles in the "actuality" of representing the fact type.  This means that at least this idea of structured expressions should be described in clause 8.2, as a kind of expression more interesting than "text".


It appears to be the intent that a fact type form expression always has a structure with representation sub-behaviors.  Is that what distinguishes a fact-type form from a designation?  The text is completely silent as to what the delimiting characteristic is.


The remaining question then is: what kind of representation is exemplified in a terminological entry for a fact type in the SBVR vocabulary itself?  E.g., is "designation has signifier" a designation for a fact type or a fact type form for it?  (According to the UML diagram it cannot possibly be both.) And if the latter, does an SBVR fact type not actually have a designation?  More confusion.


Recommendation:
  1.  Define the concept that is "pattern or template of expressions" in 8.2
  2.  Use these structure concepts to define the nature of a fact type form in 8.3.4.  For example, a placeholder is a sub-expression.
  3.  Specify the distinguishing characteristic of a fact-type form that makes it different from a designation.
  4.  Specify what the vocabulary entries for fact types are: fact-type forms or fact-type designations.

Title: Definition of signifier
Specification:  SBVR
Version:  1.0
Source:  Ed Barkmeyer, NIST, edbark@nist.gov


Summary:


SBVR clause 8.2 defines 'signifier' to be a role in a 'designation'.
But the concept 'designation' is defined in 8.3.1.


Recommendation:


Move the entry for 'signifier' to 8.3.1, where it is used.

Title: Model expression structure
Specification:  SBVR
Version:  1.0
Source:  Ed Barkmeyer, NIST, edbark@nist.gov


Summary:


SBVR clause 8.2 defines 'starting character position' as a means of reference to a substring of a Text object.  And the definition of placeholder in clause 8.3.4 treats the placeholder as a syntactic substring that is identified by its starting character position.
This is a junior programmer model of expressions -- a poor PSM -- and it doesn't work reliably for a number of surface languages.


The idea is that the unspecified representation of a concept may involve an expression that has a syntactic structure.  Since SBVR has no idea what that syntactic structure is (because it belongs to an undefined surface language for which SBVR is the metamodel), it must define a general model of expressions sufficient to support the idea that a placeholder is a subexpression, and has a surface-language-defined means of identification.


Recommendation:


In 8.2, Delete 'starting character position'.  Replace it with a model of expressions that makes clear the point at which surface-language grammar and orthography determine the technical structure of the expressions.


In 8.3.4, delete all references to 'starting character position' in the entry for 'placeholder', and replace them with references to the structural concepts (to be) defined in 8.2.


In 8.3.4, delete 'placeholder has starting character position' and replace it with a relationship to a structural concept (to be) defined in 8.2.

The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11.

A Note for Is-Facet-of Fact (Type) currently reads: "A given community may choose to include only one facet." The Note could be read as a rule: It is permitted that a given community include only one facet." The Note should probably read: A given community may choose to include any number of facets, including just one or none at all.

The concept "Partitive Fact Type" is based on the Concept "Partitive Relation" in ISO 1087. However, SBVR did not pick up the ISO synonym "Part-Whole Relation". This could raise questions about how the SBVR notion is being based on the ISO notion. Also, "Part-Whole" is more business-friendly than "Partitive". Proposed Resolution: Add "Part-Whole Fact Type" as a synonym of "Partitive Fact Type". (If for some reason this is deemed inappropriate or undesirable, a note should be added as to why.)

The segmentation 'Thing in Context' is inconsistent with the definitions of 'role' and 'facet'. The segmentation is based on an assumption that the extensions of 'role' and 'facet' are completely disjoint. But there is nothing in the definitions of 'role' or 'facet' that cause them to be disjoint. It is possible that a situational role is relevant only from a certain viewpoint. Recommendation: Remove 'Thing in Context' and all references to it. Change Figure 11.1.5 to not show segmentation between 'role' and 'facet'. 

The definition of is-property-of fact type is based on the notion of ‘essential quality’. Use of the word ‘essential’ is misleading since ISO and therefore SBVR talks about ‘essential characteristic’ in quite a different sense. The three Dictionary Bases are poorly chosen (probably because they were chosen before the ISO notion of characteristic was introduced into SBVR). In any event, the current definition of is-property-of fact type does not accurately express the intended meaning of the concept. Resolution: 1. Change the definition of "Is-Property-Of" fact type to: associative fact type that is defined with respect to a given concept such that each instance of the fact type is an actuality that an instance of the concept has a particular quality or trait 2. A better Dictionary Basis should replace the existing ones. Use the following definition from MWUD: 1 a : a quality or trait belonging to a person or thing; 

Title: Inconsistent use/definition of keyword 'or'
Spec: SBVR
Version: 1.0


Source: Ed Barkmeyer, NIST, edbark@nist.gov


Summary:


In clause 9.2.1, p.52, 'bindable target' is defined as:
  variable, expression or individual concept
In clause 11.1.5, 'contextualization fact type' is defined as:
  is-role-of fact-type or is-facet-of fact-type
In clause 11.1.5, 'contextualized concept' is defined as:
  role or facet
At the end of section C.3.2.1 in Annex C, the example is:
  contextualized concept
     Definition: role or facet
In Annex E, p.327, 'fuel level' is defined as:
  full or 7/8 or 3/4 or 5/8 or 1/2 or 3/8 or 1/4 or 1/8 or empty


In all these, 'or' is stylized as a keyword.  According to Annex C.3.2.1, these represent extensional definitions, i.e., the unions of the extensions of the concepts.  But according to Annex C.1.1, the
keyword 'or' is defined to mean logical disjunction between two
propositions.  So the definition of keyword 'or' is inconsistent with the usages.


One solution is to change the definitions.
E.g., for contextualized concept:
 Definition: concept that is a role or is a facet
This form has a direct translation to the concepts in Clause 9.


An alternative is to change the meaning of the keyword in C.1.1, assuming it is never used for logical disjunction of propositions.
Another alternative is to introduce a new keyword.

Figure 12-1 shows 'merged' arrowheaded lines from 'element of guidance' and 'rule' into 'propositiion'.  While this is not formally meaningful our graphics have used a convention to bring the lines together for elements that are mutually exclusive and to show the lines separate when not — ref. the separate lines into 'rule'.  I suggest that Figure 12-1 be updated to show separate arrowheaded lines into 'proposition'.

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)

According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected:
1. Closed world assumption; state of affairs interpretation
2. Closed world assumption; actuality interpretation
3. Open world assumption; state of affairs interpretation
4. Open world assumption; actuality interpretation.


For convenience it is recommended to add the following four meta fact types:


1. The population of all fact types in <conceptual schema> is considered <closed_or_open>
2. The population of all fact types in <conceptual schema> is considered <state-of-affairs_or_actuality>
3. The population of <fact type> is considered <closed_or_open>
4. The population of <fact type> is considered <state-of-affairs_or_actuality>

Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality.

The definition-based model specified in Clauses 8, 9, 11, 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.	Separation of the two different meanings of 'fact type' into different models
2.	Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption.

The overt problem is that SBVR has two different meanings for 'fact type':
1.	In Clause 8, the extension of a fact type is currently a set of actualities, (although another issue proposes that this should be changed to a set of states of affairs)
2.	In Clause 10, the extension of a fact type is a set of facts (propositions taken to be true). 
The underlying issue is:
1.	SBVR's metamodel is defined in Clauses 8, 9, 11, 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 Clause10: 
a.	List the major differences between the two models (see below) 
b.	Describe informally the transformation 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 of the transformation
3.	Define fact models to be 'closed world' models.
Another useful change would be to move the current Clause 10 so that it is placed after the clauses that define the SBVR metamodel - i.e. to renumber Clauses 11, 12 and 13 as 10, 11, 12 respectively, and renumber Clause 10 as 13.
One of the reasons for raising this issue is the email discussion about Issue 14241 "Coexistence approach to SBVR" earlier this year. There, a case was made for allowing a fact model to be 'closed world', to enable it to be used as the basis for business applications that will run on relational databases using SQL. 
There was some discussion that SBVR was not primarily intended to model business applications; it was intended to model the business to be supported by these applications, and the models needed to be 'open world'. 
When the two kinds of model are recognized as being different, both needs can be satisfied:
§	The linguistic model defined in Clauses 8, 9, 11, 12 and 13 is the semantic community's open world model of its business. 
§	The corresponding clause 10 fact model is the closed world model that is the basis for developing the data model and database for the required business applications. The transformations to these specifications are well-defined in both ORM and CogNIAM (the two fact modeling approaches described in Annexes of the SBVR Specification). 
One concern to be kept in mind is that the detail of specification in fact models (identifiers, data types, formats etc.) should not replicate capabilities already provided in other OMG specifications, especially UML and IMM. 
Dependencies with other Issue Resolutions
Issue 10803: 'state of affairs' is an individual concept, not a thing 
If 'state of affairs' were deemed to be to be an individual concept, the argument here for the differences between the two models would not be substantially changed. 
Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 
A new issue has been submitted, proposing that the definitions in Subclause 8.5 be moved to Clause 13. 
Issue 14241: Coexistence approach to SBVR
The proposed resolution here includes: 'closed world' assumption for Clause 10 fact model; fact type (Clause 8) having an extension that consists of states of affairs; fact type (Clause 10) having an extension that consists of facts.
Issue (awaiting number): Each individual in the extension of a fact type (Clause 8) should be a 'state of affairs'. 
The proposed resolution here assumes that the extension of a fact type (Clause 8) is states of affairs. 
Resolution:
See the discussion "Differences between Linguistic Model (Clauses 8, 9, 11, 12) and Fact Model (Clause 10)", below 
Revised Text:
To be developed after discussion with RTF
Disposition:	Open

Subclause 8.5 is about the interchange files defined in Clause 15.  
The syntax for these files is (mostly) defined in Clause 13; the content of Subclause 8.5 should be placed in Clause 13. 

From Issue 13138 (as of 5 Dec 2008):
"Subclause 8.5 includes concepts conceptual schema and fact model that have no bearing on the content of the SBVR metamodel (as defined in the Clause 15.1 XMI file) or an SBVR model (to be illustrated by Clause 15.3 SBVR model of SBVR file).  Rather they explain the structure of the SBVR model file in Clause 15.3 as an XML file containing a fact model population for an externally referenced SBVR XSD conceptual schema."
The conceptual schema for interchange is the XSD, the facts are the XML content of the interchange file. 
Supporting arguments for making the change:
§	The specification does not place the syntax of Clauses 8, 9, 11 and 12 in Clause 8 - it is in Annex C
§	The specification does not place (most of) the syntax of Clause 15 in Clause 8 - it is in Clause 13 
Some corrections are needed:
§	'fact model' has two parts: 'conceptual schema' and 'fact population'
§	 'fact model is based on conceptual schema" should be 'fact population is based on conceptual schema'
§	'conceptual schema includes fact' should be 'fact population includes fact'




Dependencies with other Issue Resolutions
Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 
This issue removes the definitions in Subclause 8.5 from the scope of Issue 13138. 
Resolution:
Move the content of Subclause 8.5 into Clause 13, with the corrections listed in Discussion, above. 
Revised Text:
TBD

'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

The note under "state of affairs" reads:

"A state of affairs can be possible or impossible. Some of the possible ones are actualities. A state of affairs is what is denoted by a proposition. A state of affairs either occurs or does not occur, whereas a proposition is either true or false. A state of affairs is not a meaning. It is a thing that exists and can be an instance of a concept, even if it does not happen. "

Although unstyled, the use of "denoted by" is likely to confuse readers. The fact symbol "denotes" is used in clause 11.2.1.3 in the fact type "term denotes thing ". But a proposition is not a term, so this fact type is not what is meant in the note. The note is trying to use a passive version of "meaning corresponds to thing" from clause 8.6.1.

Proposed resolution:

1. Add a synonymous form to "meaning corresponds to thing" such as "thing is meant by meaning".
2. Revise the note under "state of affairs" to use the new synonymous form and style the wording to make clear the reference to this formal SBVR concept.

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.