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)

Section C.10 states that the default assumed multiplicity for an unannotated association end is *. That’s a terrible idea since the UML default is 1 (i.e. 1..1).

Merged into SBVR 15-08

(see attached Word document)

SBVR 1.2, Annex G, G 6.2.8, lemma ‘rental is open’

There is a color-coded occurrence of ‘end date/time is in the future’ but there is no such declared concept.

Discussion: The way this Annex has been set up suggests that each colour-coding is meant to imply that the colour-coded concept is either explicitly listed or specifically adopted from a different vocabulary.

The only like concept is in G.8.5, ‘period is future’. SBVR 1.1 Annex E used to have a concept ‘date/time is in the future’.

Current version of Annex G no longer contains problem entry

(see attached Word document)

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

Fix Typo in clause 10.1

Correct the spelling from 'vocabulaires' to 'vocabularies'. (see attached Word Document)

C.5.2, including the diagram, should use single guillemet characters not >> and <<

Merged into SBVR 15-08

(see attached Word document)

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?

Close - Already solved in SBVR v1.3

(see attached Issue Disposition document)

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.

Close - Already solved in SBVR v1.3

(see attached Issue Disposition document)

In SBVR clause 8.x, in the entry for 'at least n quantification', the Definition ends with the term ‘logical fomulation kind’, which makes no sense in the context.

What was intended is a new paragraph:

Concept Type: logical formulation kind

Move text to Concept Type: sub-entry where it belongs

(see attached Issue Disposition document)

SBVR 1.2, p. 225, the Index entry for ”proposition” appears twice (and once out of alpha order).

Fix typo - duplicated entry in Index (p. 225)

This typo is not in SBVR 1.4. (see attached Word Document)

Issue: Can a Noun Form Be Created on the Basis of a Unary Verb Concept

• The entry for Noun Form in SBVR is currently silent as to whether or not a noun form can be based on a unary verb concept.
• If the answer is no, a Note should say as much.
• If the answer is yes, an example should be given.

Resolution:
Indicate explicitly yes or no, and include an example if yes.

The answer is "yes' to "Can a Noun Form be Created on the Basis of a Unary Verb Concept?"

(see attached Word document)

Issue: Stand-Alone 'Must' in a Necessity

The second Necessity for "adopted definition" on p.137 includes a stand-alone "must". Use of a stand-alone "must", with its inherent sense of obligation, in Necessities is inappropriate. (In reviewing the whole document, this is the only case I find of its use in a Necessity.)

Resolution

Change:

Necessity: Each adopted definition must be of a concept in the body of shared meanings that unites the semantic community that has the speech community.

to

Necessity: Each adopted definition is of a concept in the body of shared meanings that unites the semantic community that has the speech community.

Close - Already solved in SBVR v1.4

(see attached Issue Disposition document)

Correctly style the text at the end of the Definition text of two entries on p. 36. The styling should not be all in ’keyword’ style.

Correct the styling errors in Definition text

Correct the styling errors in the Definition text for the entries "element of guidance necessitates state of affairs" and "element of guidance obligates state of affairs" (see attached Word Document)

Acceptance of the Resolution for 19840 under Ballot 4 in the second half of 2016 resulted in the following text being substituted for a Note in the entry for Advice of Possibility.
Note: Every definitional rule implies an advice of possibility. Consider the definitional rule expressed as:
It is necessary that each rental has exactly one car group.
Alternatively:
Each rental always has exactly one car group.
This definitional rule implies an advice of possibility that can be expressed as:
It is possible that a rental has exactly one car group.
Alternatively:
A rental can have exactly one car group.
There is no practical reason, however, to express the advice of possibility implied by a definitional rule explicitly. In such cases, best practice generally favors keeping the number of elements of guidance to be managed to a minimum.
The equivalent substitution needs to be done for Advice of Permission. It’s just a clarification of the Note, which is otherwise somewhat hard to decipher

Clarify Note for Advice of Permission

Clarify wording and add two examples to Note (see attached Word Document)

The line for 'operating country' reflects the styling of a 'Definition:' caption. It should be styled as a vocabulary entry term.

This can be confirmed by checking this entry in the Word docx source, where this line (paragraph) has the correct style of 'term'.

Fix SBVR SE styling in SBVR Annex G: EU-Rent Example terminological entry

(see attached Issue Disposition document)

The entry for "Definitional Rule" in SBVR lacks an example. Here is an appropriate one.

EU-Rent requires that a rental is for one car group (economy, compact, full-size, etc.). This definitional rule can be expressed as:
It is necessary that each rental has exactly one car group.
Alternatively:
Each rental always has exactly one car group.

Add Example for Definitional Rule

Add two examples (see attached Word Document) (see attached Word Document)

The SBVR entries for the various statement forms present Example(s) that illustrate the particular statement kind. Most of the entries provide two examples, to illustrate both the verbose and the more-compact statement styles. However, two of the entries only provide one example (the verbose style).

Resolution: Add a 2nd example statement, parallel to each of the current examples, to the entries ’non-necessity statement’ and ’permission statement’, illustrating the use of ’not always’ and ’need not’ (respectively).

Add 2 Statement Examples

Add a 2nd example statement, parallel to each of the current examples, to the entries ’non-necessity statement’ and ’permission statement’, illustrating the use of ’not always’ and ’need not’ (respectively). (see attached Word Document)

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.