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