The example of "adopting authority adopts element of guidance from owning authority citing reference" has the phrase "Example: EU-Rent has adopted an behavioral business rule from from an industry glossary" with a repetition of the word "from".

The word "smakrt" appears in the sentence:
"Unicode encodings contain all of the characters used in all of the natural languages, including readability characters such as smakrt quotes."

I presume the intent was "smart"?

Page 64 gives the Necessity "No verb concept role designation is a term.".

In SBVR verb concepts role are noun concepts, even though they are not general noun concepts. SBVR is deficient in that it doesn’t show terms as being for both general noun concepts and verb concept roles.

Also ISO 1087-1 does not exclude concepts that SBVR considers to be verb concept roles from its concept ‘concept’ and therefore from being designated by ‘terms’.

According to the diagram on p. 26 (Figure 8.5), element of guidance and rule are not mutually exclusive. But Figure 16.1 shows they are. That's an error. A proposition can be both a rule and an element of guidance.

The definition of "vocabulary" in SBVR is "set of designations and verb concept wordings primarily drawn from a single language
to express concepts within a body of shared meanings".

The definition does not explicitly indicate that definitions of concepts are part of a vocabulary. Most business people would probably assume they are.

SBVR 1.2, Annex B, references to diagramming conventions

Annex B has a number of references to diagramming conventions that are too colloquial. The implication is that the reader is already familiar with the UML or CDG diagramming conventions, but this is not appropriate, since the whole point of the Annex is to be explanatory at this level. For example:

B.3.5. “UML’s arrow style for ‘instantiation’” What is this arrow style? Where is it explained?

B.3.5. The notation has been adapted from standard UML notation to make it more ‘business friendly’. For example, in UML, in instance (‘object’) would be labeled as, Canada: country.

This information does not belong here, but in Annex C.

B.3.5. “the box in box style”. Where is this explained? Is it UML or CDG?

Suggested solution: when referencing UML or CDG diagramming conventions, do not attempt to be descriptive of symbols or drawing conventions, but use ‘base’ references instead: all the diagramming information should be in one place, ie., in Annex C or I respectively, but not in Annex B. Make sure the same format is used for all references to Annexes C and I, and that the difference between the two diagramming techniques is signposted adequately. An even better, more practical solution would be in each case to depict the symbol(s) involved and to refer to the appropriate paragraph in Annex C or I for any textual explanation. This would cause duplication of symbols between the Annexes but it would make Annex B much more helpful.

Make the suggested improvements by removing the instructions for how to do the graphic styles from Annex B and by standardizing the Annex B referrals to the appropriate material in Annexes C and I.

see attached Word document

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

Wording is part of Formal Theory for SBVR and not part of the "SBVR Vocabulary"

see attached Word document

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.

Subscripting is now in Annex A

see attached Word document

The use of UML described in the Annex does not represent any known UML tool nor the UML specification. The examples are UML-like diagrams presumably created with a drawing tool.

• In Figure C.1 the right hand class is shown with 2 names and an italicized label “also:” – this is not supported.

• Section C.3 and Figure C.2: in UML, Instance diagrams only the class and not the instance name is ever underlined

• Figure 6.3 is not a valid UML diagram if the lower shapes are InstanceSpecifications: they should have a colon after the names which should not be underlined. The use of Dependencies is not valid for class membership.

• Figure 6.4 is not valid – an association may have only one name optionally accompanied by one direction indicator.

• Figure C.7, C.12: In general UML does not include the notion of underline/font within a name: it’s modeled only as a text string.

• Figure C.9 is not valid – one cannot have an association with only one end.

• C.7.1, Figure 14: these 2 renderings are semantically identical in UML and serialized the same in XMI. UML has the ability to render the distinction using a GeneralizationSet with isDisjoint – so why not use that?

• C.15: powertypes should not have a name before the colon in UML, though the property of type “branch type” may

• C.9, Figure C.17: the dashed lien to association diamond is not valid in UML

Clarify that the Diagrams in Clauses 7-21 do not depict UML conventions or semantics

(see attached Word document)

SBVR should use the latest MOF rather than sticking with MOF 2.0.

State even more directly that SBVR uses MOF as a Syntax for SBVR Semantics + use MOF 2.4.2 and XM 2.4.2

see attached documents

SBVR 1.2, Formal Specification

Problem: In Annex B.2.3 the term ‘sentential form’ is used with a different meaning than defined for this term in Clause 8.4.4.

· In Annex B, it means the standardised form or ‘handle’ by which a verb concept is known in a presentation format such as a glossary. Going by this meaning, ‘customer rents car’ is the sentential form (Annex B uses ‘primary reading’ as a synonym) for the verb concept in question, and “car is rented by customer” is not a sentential form of the verb concept.

· In Clause 8.4.4, it means any verb concept wording that is available for a given verb concept, except noun forms. Going by this meaning, as the examples provided make clear, “car is rented by customer” and “customer rents car” are alternative sentential forms.

Suggested solution: Keep 8.4.4 as it is. Remove occurrences of ‘sentential form’ from Annex B, keeping only ‘primary reading’ in that context.

Discussion:

The dictionary basis for selecting the adjective ‘sentential’ in Annex B seems to be the meaning of ‘aphoristic’, as in ‘sentential saying’ or ‘sentential book’.

The dictionary basis for selecting the adjective ‘sentential’ in 8.4.4. seems to be the meaning ‘of a sentence, concerning a sentence’, i.e., the association with ‘sentence’ as a linguistic term.

The former use of ‘sentential’ in English seems to be the more common. This would explain why the issue has occurred. It also suggests that ‘sentential form’ in Clause 8 is not ideal.

‘Verb form’ as a complementary concept of ‘noun form’ would not have this problem but I agree that, because of cases where the wording contains no verb form at all, ‘verb form’ cannot be used. It could be said that ‘verb concept wording’ has the same problem, but I think it is more acceptable to say that a word like ‘of’ or ‘in’ is a “verb concept wording” than to say that it is a “verb form”.

All references to "sentential forn" removed

see attached Word document

SBVR should cover the concept of IRI as well as/instead of URI.

The URL/IRI standard is very much up in the air. No change until settled

(see attached Word document)

SBVR should re-consider the use of smart quotes

Made Clear that all UTF-8 characters including 'smart quotes' are accepted in SBVR content

see attached Word document

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?

Fixed in SBVR v1.4

see attached Word document

The description in C.4.2 leaves it very ambiguous as to whether “has” is to be assumed or not. In particular

Again, no UML tool will be able to add/remove “has” in diagrams.

Merged into SBVR 15-08

(see attached Word document)

Page 8 currently includes the following Note.

Note: As indicated in 2.4.1, an SBVR producer may produce instances of concepts not defined in SBVR as well. In such a case, the SBVR fact model would be only a part of the exchange document.

SBVR proper does not use the term “fact model”. The second sentence of the Note should probably read as follows:

“In such a case, the instances of concepts specified in the SBVR XMI Metamodel XML Schema (Clause 25.3) would be only a part of the exchange document.”

Replaced "fact model" wording with appropriate wording to clarify sentence

see attached Word document

From SBVR v1.3, clause 8.7:

term denotes thing

Definition: the thing is an instance of the concept that is represented by the term

thing has name

Definition: the thing is the instance of the individual noun concept that is represented by the name

Synonymous Form: name references thing

Note: A use of an individual noun concept by its name denotes the thing that is in the extension of the individual noun concept.

statement denotes state of affairs

Definition: the statement indicates the state of affairs that is posited by the proposition that is expressed by the statement

SBVR does not define ‘name’ at all. But, the UML diagram 8.12 shows ‘name’ as a category of ‘designation’, and the definition of ‘thing has name’ says that a ‘name’ represents a concept, which would make it a designation, and how it might differ from a term in that regard is not clear. In fact, the whole idea of a ‘name’ is that it denotes a thing, usually without regard to any concept, whereas a term designates a concept and indirectly denotes things.

But most of the vocabulary in 8.7 contradicts the notations on the semiotic triangle figure in 8.1.1. In the semiotic triangle, an ‘expression’ denotes a ‘thing’, but a ‘term’ is not an ‘expression’ in SBVR, and a ‘statement’ is not an expression in SBVR. All of that proceeds from the dual use of ‘designation’ in ISO 1087 to mean both “the state of designating” and “the thing that designates”. This needs to be fixed. A term must be an expression in order to denote a thing, and a statement must be an expression in order to denote a state of affairs.

SBVR has been changed since Issue was submitted to deal with all points.

see attached Wrod document

In SBVR 1.4 (pg. 34), in the first Note for the entry 'proposition is true', change "A proposition is true if and only the" to "A proposition is true if and only if the".

Add a missing 'if'

Add the missing 'if'.

SBVR 1.2, 'role': 'ranges over' vs. 'specializes'.

Clause 8, entry for ‘role’. Should the addition at the end of the second Example text: "(which generalizes the role)" read: "(which the role ranges over)"? As I understand it, you mean to say that the role shipment ranges over the general concept shipment. The reverse reading of "ranges over" is not "generalizes" (there is a specific Note at the lemma "role ranges over general concept" that warns against this confusion).

Fix wording in the referenced example

(see attached Issue Disposition document)

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!

Delete the Necessity that duplicates the definition, adding nothing to it

(see attached Issue disposition document)

Figure C.11 the right-hand diagram is not clear since both renter and driver seem to be independent roles (a renter, even of a car, may or may not drive it)

Diagram with the problem was already removed by different Issue

(see attached Word document)

Figure C.8: it should seem that composition in UML (black diamond) should be used for “contains”.

*A non-UML diagram convention is now used for partitive verb concepts *

(see attached Word Document)