-
Key: SBVR-61
-
Legacy Issue Number: 9712
-
Status: closed
-
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
-
Summary:
Name: Definitions of 'projection'
Doc: dtc/06-03-02
Date: March 2006
Version: Interim Convenience Document
Chapter: 9.1.1
Pages: 101
Nature: Revision/correction
Severity: SignificantDescription:
9.1 defines 'semantic formulation' as: conceptual structure of meaning.
9.1.2 defines 'projection' as: semantic formulation that operates over one or more variables and results in a set or multiset.
How does a 'conceptual structure' 'operate' or 'result'? Structure is a static notion. A 'projection' must rather be a semantic formulation whose meaning is the SET – the conceptual structure – that results from applying a function to some collection of things.
The term 'multiset' is undefined, and does not have a NODE definition (it's IT jargon). In a formal model, a 'multiset' is either a set of pairs (thing, occurrence), each of which has a reference scheme, or a set of pairs (thing, count), for which thing has a reference scheme and count is a nonnegative integer. Whichever definition is chosen, if any, the conceptual structure of the projection is a SET. The only question is what it is a set of.
The example of a 'bag projection' indicates that the result is actually a set of pairs (balance, customer) and then says: "Only balances are in the result, but there can be duplicates where multiple customers have the same balance." This is true in SQL, but it has nothing to do with reality or logic. It can only be true in business if the result somehow carries the customer notion with the balance – a different line, a different position, a different memory cell – so that occurrences can be distinguished. In SQL, the result is a LIST of balances with distinguished positions, a SET of pairs (position, balance).
The projection (set) doesn't result from applying a function to 'variables', it results from applying the function to the things the variables range over.
So the concept 'variable ranges over concept' from 9.1.1 is critical to the meaning of a projection! (Note that much of the discussion of 'variables' in 9.1.1 is about projections and not about 'variables' in logical predicates.)The projection is not 'on a variable'. A projection INTRODUCES a variable to denote the individual concepts in the range from which the result set will be extracted. The logical formulation that constrains the projection is called the 'selection criterion'. It involves the projection variable as a 'free variable'. Each individual concept for which the selection criterion holds appears in the result set.
In addition to projections, there are mathematical functions whose operands are sets and whose results are simple values, like 'average'. These should not be confused with projections. In the example "the average of ages of rental cars owned by each local area", the conceptual structure is a TABLE of cars with ages, created by the "projection"
{ c: OwnedCars, a: Age | (CarHasAge c a) }
TableOfAges =over the projection
{ c: Car | (Exists b: branch)(owns b c) }
OwnedCars =but the result of interest is the function
AverageOfColumn(TableOfAges, Age)
which is not a projection or anything the like.If database Select and Project operations and arbitrary mathematical functions whose operands can be structures are all part of "semantic formulations", let us call a spade a spade. The relational database formulation of "semantics" is well understood, and we can use that. The current text for projections does not have any hope of capturing meaning.
Recommendation:
The real fix:
a. Define the 'relation' concept, and the cross product, select and project operations a la relational algebra. It is a perfectly usable form of "semantic formulation": "relational formulation"
b. Provide a concept for mathematical function that applies to arbitrary operands.The minimal fix:
a. Correct the definition of projection, and decide on the model of projection (result) to be used.
b. Repair or delete the concepts bag projection and set projection according to the model chosen.
c. Correct the definitions of the relationships among the projection, the range variable(s), and the selection condition.
d. Eliminate 'auxiliary variable'. It is either a logical variable in the selection condition (logical formulation) or a (parallel) range variable depending on the model of projection results.
e. Remove the example about the average of ages of rental cars, and other such examples, whose formal representation is well out of the scope of SBVR. -
Reported: SBVR 1.0b1 — Thu, 11 May 2006 04:00 GMT
-
Disposition: Resolved — SBVR 1.0b2
-
Disposition Summary:
Replace the definition of 'projection'. Split the fact type 'closed projection defines concept' into two fact types, one for noun concepts and the other for fact types, and explain them separately with examples.
Explain 'projection' with respect to its different uses. Move Necessity statements under 'closed projection' to be under fact types for the different uses. As a way of aiding the clarity of its uses, change the signifier of 'noun concept formalization' to 'noun concept nominalization' and reinstate 'fact type formulation' as 'fact type nominalization'.
Projections are related to meanings through the following fact types:
1. closed projection defines noun concept
2. closed projection defines fact type
3. close projection means question
The first two are fully explained and exemplified in this resolution. The third is already fully explained with an example.
Also, projections are used in the five types of projecting formulations. Each of those is already fully explained with examples except for 'fact type nominalization' which is explained with examples in this resolution. Note also, three of those five are correlated with the three relations to meaning listed above. The three are, respectively:
1. noun concept nominalization
2. fact type nominalization
3. question nominalization -
Updated: Fri, 6 Mar 2015 20:58 GMT