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

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

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)

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.

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

Resolution: Move 'rulebook' to Clause 12.

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

Move 'rulebook' to Clause 12

This was taken care of in the major restructuring of the SBVR document in v1.3 (see attached Word document)

Definite descriptions do not always define individual concepts

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

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

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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)

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

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

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

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

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

Is it existential? I cannot see it that way.

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

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

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

Employee number 777 is assigned.

There exists an employee that has the employee number 777.

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

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

Recommendation:

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Issue Description:

1. Spin-off Issue for items not resolved In Issue 9959 because of lack of time:

a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed

b. Remove tutorial material from Clause 10.1.1

c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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.

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

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

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

Example use cases for local closure include the following:

Example 1

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

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

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

Example 2

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

employee
Definition: person that works for the business

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

Example 3

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

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

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

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

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

Resolution:
Revised Text:
Disposition:

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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.

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

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

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

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

The following SBVR metamodel formal logic-based errors and omissions need to be dealt with as we ran out of time to deal with them:

a. A reference scheme is needed for individual concept.

b. The entries in Clause 8.5 “Conceptual Schemas and Models” need to be corrected to agree with the first paragraphs of Clause 10.

c. In Clause 8.6 “Extensions” and other sections of Clauses 8-12 the definition of “corresponds to” in “meaning corresponds to thing” and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of “proposition corresponds to state of affairs” and “ individual concept corresponds to thing” need to be clarified or added. How the relationship between concept and thing is different between the “use” and the “mention” of the concept needs to be made clear.

d. Thee reference scheme for individual concept needs to be fixed to include the “mention” of object types, roles, fact types, propositions and subcategories of them.

e. Definitions that cover all the uses of “individual” in Clauses 8-12 need to be added.

f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

The ‘involvement’ Issue is as follows (from my email sent on Saturday):

Issue Submitter’s Name: Donald Chapin

Issue Submitter’s Company: Business Semantics Ltd (submitted as SBVR FTF Chair)

Issue Submitter’s Email: Donald.Chapin@btinternet.com

Issue Name: The Notion of “Involvement” has not been Adequately Specified with in SBVR

Document No: dtc/06/03/01

Document Revision Date: March 2006

Document Version No: —

Chapter/Section: 8.1.1

Page No(s): 16

Nature of Issue: Revision

Severity of Issue: Major

Issue Description:

The notion of Involvement has not totally been taken into account by the resolution of Issue 9948 as stated in that resolution.

Several clarifications are needed regarding Involvement such as the nature of instance of roles (see the sum example in the initial 9948 statement).

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

As a result of the vote on Issue 9959, there is a need to clarify and strengthen the Note in front of the Formal Logic Interpretation Table in Clause 10.2, particularly to cover these points:

• a major subset of SBVR has a complete formal logic interpretation whose principles are set forth in Clause 10.1

• the table will contain:

o a formal logic interpretation specified in ISO Common Logic based on Clause 10.1

o a cross-reference to OWL constructs that equivalent to SBVR constructs

• the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

Need to establish approved baseline from SBVR v1.5 Issue Resolutions to proceed with the Rest

The following SBVR metamodel formal logic-based errors and omissions need to be dealt with as we ran out of time to deal with them:

a. A reference scheme is needed for individual concept.

b. The entries in Clause 8.5 “Conceptual Schemas and Models” need to be corrected to agree with the first paragraphs of Clause 10.

c. In Clause 8.6 “Extensions” and other sections of Clauses 8-12 the definition of “corresponds to” in “meaning corresponds to thing” and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of “proposition corresponds to state of affairs” and “ individual concept corresponds to thing” need to be clarified or added. How the relationship between concept and thing is different between the “use” and the “mention” of the concept needs to be made clear.

d. Thee reference scheme for individual concept needs to be fixed to include the “mention” of object types, roles, fact types, propositions and subcategories of them.

e. Definitions that cover all the uses of “individual” in Clauses 8-12 need to be added.

f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.

The ‘involvement’ Issue is as follows (from my email sent on Saturday):

Issue Submitter’s Name: Donald Chapin

Issue Submitter’s Company: Business Semantics Ltd (submitted as SBVR FTF Chair)

Issue Submitter’s Email: Donald.Chapin@btinternet.com

Issue Name: The Notion of “Involvement” has not been Adequately Specified with in SBVR

Document No: dtc/06/03/01

Document Revision Date: March 2006

Document Version No: —

Chapter/Section: 8.1.1

Page No(s): 16

Nature of Issue: Revision

Severity of Issue: Major

Issue Description:

The notion of Involvement has not totally been taken into account by the resolution of Issue 9948 as stated in that resolution.

Several clarifications are needed regarding Involvement such as the nature of instance of roles (see the sum example in the initial 9948 statement).

As a result of the vote on Issue 9959, there is a need to clarify and strengthen the Note in front of the Formal Logic Interpretation Table in Clause 10.2, particularly to cover these points:

• a major subset of SBVR has a complete formal logic interpretation whose principles are set forth in Clause 10.1

• the table will contain:

o a formal logic interpretation specified in ISO Common Logic based on Clause 10.1

o a cross-reference to OWL constructs that equivalent to SBVR constructs

• the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force

Issue Description:

1. Spin-off Issue for items not resolved In Issue 9959 because of lack of time:

a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed

b. Remove tutorial material from Clause 10.1.1

c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO

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

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

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.

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

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

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

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

Example use cases for local closure include the following:

Example 1

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

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

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

Example 2

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

employee
Definition: person that works for the business

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

Example 3

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

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

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

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

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

Resolution:
Revised Text:
Disposition:

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.

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

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

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

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

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

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

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

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

Is it existential? I cannot see it that way.

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

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

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

Employee number 777 is assigned.

There exists an employee that has the employee number 777.

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

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

Recommendation:

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

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

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

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

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

Definite descriptions do not always define individual concepts

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

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

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

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

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

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)

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

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.

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

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

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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)

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Definite descriptions do not always define individual concepts

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

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

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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?

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

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

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

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

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

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

Is it existential? I cannot see it that way.

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

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

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

Employee number 777 is assigned.

There exists an employee that has the employee number 777.

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

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

Recommendation:

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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?

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

Resolution: Move 'rulebook' to Clause 12.

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

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

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

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

Example use cases for local closure include the following:

Example 1

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

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

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

Example 2

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

employee
Definition: person that works for the business

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

Example 3

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

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

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

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

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

Resolution:
Revised Text:
Disposition:

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

As a result of the vote on Issue 9959, there is a need to clarify and strengthen the Note in front of the Formal Logic Interpretation Table in Clause 10.2, particularly to cover these points:

• a major subset of SBVR has a complete formal logic interpretation whose principles are set forth in Clause 10.1

• the table will contain:

o a formal logic interpretation specified in ISO Common Logic based on Clause 10.1

o a cross-reference to OWL constructs that equivalent to SBVR constructs

• the current table is incomplete and immature, and will be completed during the SBVR Revision Task Force

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

The ‘involvement’ Issue is as follows (from my email sent on Saturday):

Issue Submitter’s Name: Donald Chapin

Issue Submitter’s Company: Business Semantics Ltd (submitted as SBVR FTF Chair)

Issue Submitter’s Email: Donald.Chapin@btinternet.com

Issue Name: The Notion of “Involvement” has not been Adequately Specified with in SBVR

Document No: dtc/06/03/01

Document Revision Date: March 2006

Document Version No: —

Chapter/Section: 8.1.1

Page No(s): 16

Nature of Issue: Revision

Severity of Issue: Major

Issue Description:

The notion of Involvement has not totally been taken into account by the resolution of Issue 9948 as stated in that resolution.

Several clarifications are needed regarding Involvement such as the nature of instance of roles (see the sum example in the initial 9948 statement).

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Issue Description:

1. Spin-off Issue for items not resolved In Issue 9959 because of lack of time:

a. Adding terms and definitions used in Clause 10.1.1 to Clause 10.1.2 and remove terms in Clause 10.1.2 no longer needed

b. Remove tutorial material from Clause 10.1.1

c. Add ISO 24707 terms to 10.1.2 if permission is received from ISO

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

The following SBVR metamodel formal logic-based errors and omissions need to be dealt with as we ran out of time to deal with them:

a. A reference scheme is needed for individual concept.

b. The entries in Clause 8.5 “Conceptual Schemas and Models” need to be corrected to agree with the first paragraphs of Clause 10.

c. In Clause 8.6 “Extensions” and other sections of Clauses 8-12 the definition of “corresponds to” in “meaning corresponds to thing” and all the relationship and necessities between all the subcategories of meaning and all the subcategories of thing, especially the meaning of “proposition corresponds to state of affairs” and “ individual concept corresponds to thing” need to be clarified or added. How the relationship between concept and thing is different between the “use” and the “mention” of the concept needs to be made clear.

d. Thee reference scheme for individual concept needs to be fixed to include the “mention” of object types, roles, fact types, propositions and subcategories of them.

e. Definitions that cover all the uses of “individual” in Clauses 8-12 need to be added.

f. The meaning of Henkin semantics needs to be specified as it applies to the SBVR metamodel.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

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

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

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

1. An SBVR metamodel noun concept (named something like “role playing of thing in occurrence”) that is very similar to ‘object type’, ‘fact type’, ‘individual concept’, ‘situational role’ (role type), or ‘fact type role’ in that it defines a kind of vocabulary entry that can be entered in an SBVR model is needed in SBVR. It’s omission represents a critical gap in SBVR.

2. Preferably this noun concept (“role playing of thing in occurrence”) would be a category (subtype) of object type; but it is much better to have the concept in the SBVR metamodel than to require it to be an object type, if that is too difficult (e.g. fact type role is not (a category/subtype of) an object type).

3. The meaning of this kind of SBVR model vocabulary entry would be that it talks about "the ‘thing’ with respect to (in the context of) its/his playing some role in a fact of a fact type, and so on for each thing that plays that role in a fact of that fact type.

a. E.g. "the person with respect to (in the context of) his renting a given car on a given date", and so on for each person who rents a car on a date.

4. The extension of each vocabulary entry concept that is this kind of SBVR metamodel concept (“role playing of thing in occurrence”) must be in one to one correspondence with the actualities that are instances (and the facts [that correspond to the actualities]) that are of a given fact type which is identified in the definition of this kind of vocabulary entry. In the reference scheme below:

a. The first part (a name of an individual concept that corresponds to the thing that fills the given fact type role) is the thing we’re talking about

i. Example: Joe Smith (the person)

b. The second part (the fact type form of the fact type and a name of an individual concept that corresponds to the thing that fills each of the other fact type roles of the fact type) of the context of the role playing

i. Example: with respect to (in the context of) Joe’s renting of car 1234 on July 30, 2007 (with respect to (in the context of) his renting a given car on a given date)

5. The instances in the extension of each vocabulary entry concept that is this kind of SBVR metamodel concept (“role playing of thing in occurrence”) must be the ‘playings’ of a given ‘role’ by a ‘thing’ in the ‘facts’ that are for the ‘fact type’ identified in the vocabulary entry concept definition.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

The definition currently reads "scheme for partitioning things ..."
Should read "scheme for classifying things ..."

'Partitioning' is a segmentation, which is a categorization scheme that is complete and disjoint. The problem here is that the general concept, "categorization scheme" is defined to be a specialization of itself, "partitioning". Categorization schemes are not, in general, segmentations. Categorization schemes are, in general, neither complete nor disjoint. The word "classifying" captures the more general concept and should be substituted for "partitioning" in the definition. The Example is a segmentation. It could be revised to show a categorization scheme that is neither total nor disjoint, e.g.

. The Example under "categorization scheme" could be moved to be an example under "segmentation."

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Doc: SBVR, dtc/06-08-05
Date: September 2006
Version: FTF Interim Specification
Chapter: 11.1.3
Related issues: none

Title: owned definition and adopted definition are roles

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

Description:

In clause 11.1.3, the terms 'owned definition' and 'adopted definition' are defined without reference to any category. They are both roles of the concept 'definition'. 'owned definition' is a role in the fact-type 'speech community owns owned definition' and ''adopted definition' is a role in the fact-type 'speech community adopts adopted definition from source vocabulary'.

Recommendation:

1. In the entry for 'owned definition', immediately behind the Definition paragraph, ADD:
"Concept type: role
General concept: definition"

2. In the entry for 'adopted definition', immediately behind the Definition paragraph, ADD:
"Concept type: role
General concept: definition

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

In clause 8.1.3, 'question' is defined as "meaning of an interrogatory".
Assuming that "interrogatory" means "interrogatory sentence", this defines the meaning in terms of the form of expression. Because the same interrogatory sentence may have more than one meaning, depending on the context of its utterance, this definition means: the meaning of an interrogatory sentence in context. But the same meaning extends across (some) contexts, while the answer may be different in each such context. That is, some part of the context of utterance affects the interpretation of the utterance; other parts of the context of utterance only affect its result. So this is a poor definition.

A question is really an "operation" on a concept or proposition that creates a new form of meaning. One can describe a 'question' as a function applied to a concept or proposition whose result is its extension. There are 3 kinds of questions:

• a concept question (What), which asks for the extension of a concept,
• a proposition question (Whether), which asks for the truth-value (technically the extension) of a proposition.
• a propositional relationship question (Why), which asks for the extension of a 2nd-order proposition about propositions (or objectified 'states of affairs' identified by propositions) – the set of all propositions P such that 'P causes Q' or 'P entails Q'.

Since clause 9 apparently supports 'question' meanings in exactly this way, SBVR should define 'question' to be a meaning that explicitly refers to the extension of a concept. That is, the question means its answer. It should not mean the action of asking.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE TITLE: 'Thing' Is Incorrectly Equated with ISO 1087 'Object' ISSUE DESCRIPTION: In ISO TC 37, and in ISO 1087 in particular, 'object' and 'concept' are mutually exclusive. ISO 1087 'object' is equivalent to SBVR 'res', (thing that is not a meaning). SUGGESTED RESOLUTION: 1. Move the adoption of ISO 1087 'object' from SBVR 'thing' to SBVR 'res'. 2. Make 'res' and 'meaning' a segmentation of 'thing'. 3. Change definition of 'thing' back to the original one supplied by BRG before the adoption of ISO 1087 'object'; i.e.: "whatsoever; literally anything: - that exists external to the mind ; - which can talked about regardless of: a. what it is b. how it is perceived" NOTE: This resolves Sridhar's concern that the definition of 'thing' began with 'anything'.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE TITLE: Relationships Between Definition Concepts and Semantic Formulation Concpets Seem to be Wrong or Missing ISSUE DESCRIPTION: The relationships between 'definition' (both intensional and extensional) and 'semantic formulation' (both 'necessity' and 'closed projection') and the 'intension' and 'extension' of a concept in some cases seem to be wrong and other cases missing. - The connections between 'intensional definition', 'necessity' logical formulation (structural rule), 'essential characteristic set' and 'concept' are missing (as discussed above). - The connection between 'definition', 'closed projection' and 'concept' seems ambiguous, and maybe incorrect, as 'closed projection' is usually associated with 'extension' and not directly with 'concept'. Also associating 'closed projection' with 'definition' in general (vs. intensional or extensional definition) seems strange. - The connection between 'extensional definition', some kind of semantic formulation, and extension seemns to be missing.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

Vocabulary Adoption vs. Inclusion The vocabulary of section 12 is directly built on, and depends on, some (but not all of) of the vocabulary of section 10. Questions have arisen in that regard, including (but not limited to) the following: * Is the latter vocabulary being included or adopted into the former? * Is there a difference between “inclusion” and “adoption”, and if so, what is it? * Can you adopt and/or include concepts and/or definitions without terms? * What exactly is included or adopted when “inclusion” and/or “adoption” occurs? * How exactly does SBVR intend “adoption” and/or “inclusion” to work? SBVR needs to be more specific about the notions of “adoption” and/or “inclusion”, since SBVR itself requires these notions, and since leaving the specifics to practice or interpretation is likely to produce divergent and perhaps undesirable results.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: "SBVR 'Thing' <-> 'Expression' Architecture" Needs Fixing 1. Form for Representation needs to be added between 'meaning' and 'representation' to include 'semantic formulations; forms of concept meaning (intensional, extensional,etc.); types of forms of expression. 2. 'Representation' should to tie to 'form of representaiton' instead to directly to meaning and add should only Speech Community considerations (language, Speech Community-specific terms, notations) to 'form of representation'. 3. 'Expression is in Language' needs to be added 4. Representations, at least designations, should be in canonical form 5. The relationship between 'representation' and 'expression' should allow for basic linguistic analysis e.g. multiple spellings, plurals, etc.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Bring the Specification of SBVR Which is in Terms of Itself to the the Full SBVR Metamodel Standard The current specification of SBVR in terms of itself (SBVR Structured Englich) is not completed or up to full integrity in that: 1. not all SBVR metamodel constructs are specific for each SBVR entry in Clauses 8, 9, 1, and 12 2. some entries are lower quality than they should be, e.g. some definiitions are not fully structured; some necessities are missing; etc. 3. Definitions and Necessities have not been fully tested by software to see that all supporting entries in in SBVR.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Use URI to Uniquely Identify and Assert the Existence of Every 'Thing' Represented in an SBVR Model to Support Multi-Classification of 'Things' Need to develop a URI pattern for all kinds of representations that can assert the existence of any 'thing' in an SBVR Model. These patterns need to take Speech Community and Symbol Context / Subejct Area into account. The appraoch chosen needs to support composite identifiers and identifiers with a narrow context scope. Topic Maps has an excellent approach for this and has done extensive work with the W3C to identifying the issues with URIs and the best ways to deal with them. For Topic Map / W3C References see: ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Subject%20Identifiers.doc Another benefit of this is that is laying the necessary foundation for mapping to RDF/ORL as well as the Rules Interchange Format

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

ISSUE: Major Categories of 'Thing' Need to be Related and Made Clear Important in any case, but especially so with the inclusion of 'objects' as vocabulary entires, the major concepts that are subcategories of 'thing' such as 'state of affairs', 'actuality', 'expression', 'res', 'object', (as defined by the terminology community), etc. need to be related and clarified to such the major divisions of 'thing' that are significant in SBVR of SBVR. This will make the real world cornerstone of SVCR much clearer for new audiences.

Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.