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