Informal Survey #1 -- joins on foreign keys

[Rob]

First, let me qualify my interests. I am primarily interesested in the
mechanics of
relational database management, not the semantics. I am interested in
the evaluation
of sql queries without regard to their meaning.


1. without racking your brain or searching the archives of your
previous work, does
your gut feeling tell you have ever authored or seen an sql query in
which two relations
were joined on a foreign key in each?

2. using your knowledge and understanding of (any) relational algebra,
is a join
between two relations on a foreign key in each ever meaningful? (Keep
in mind
the definition of the domain of a foreign key.)

3. in the semantic realm you use to "think about" relational databases
(i.e., E-R,
facts, etc.), does a join between two relations on a foreign key in
each make sense?

I request that you spend at least 10 minutes thinking about this
before you flame
me.

Rob

[Cimode]

On 1 oct, 19:09, Rob <rmpsf...@gmail.com> wrote:
> First, let me qualify my interests. I am primarily interesested in the
> mechanics of
> relational database management, not the semantics. I am interested in
> the evaluation
> of sql queries without regard to their meaning.

A contradiction in your statement. You seem interested in relational
management but not enough to put some effort to understand what it is
about.

> 1. without racking  your brain or searching the archives of your
> previous work, does
> your gut feeling tell you have ever authored or seen an sql query in
> which two relations
> were joined on a foreign key in each?

Yes. No big deal.

> 2. using your knowledge and understanding of (any) relational algebra,
> is a join
> between two relations on a foreign key in each ever meaningful? (Keep
> in mind
> the definition of the domain of a foreign key.)

None particular.

> 3. in the semantic realm you use to "think about" relational databases
> (i.e., E-R,
> facts, etc.), does a join between two relations on a foreign key in
> each make sense?

JOIN is a relational operator. It can be used between any relation
column subset.

> I request that you spend at least 10 minutes thinking about this
> before you flame
> me.

No flames. Just simple answers as you requested.
> Rob

[Bob Badour]

Rob wrote:

> First, let me qualify my interests. I am primarily interesested in the
> mechanics of
> relational database management, not the semantics. I am interested in
> the evaluation
> of sql queries without regard to their meaning.
>
> 1. without racking your brain or searching the archives of your
> previous work, does
> your gut feeling tell you have ever authored or seen an sql query in
> which two relations
> were joined on a foreign key in each?

Obviously, I have.

> 2. using your knowledge and understanding of (any) relational algebra,
> is a join
> between two relations on a foreign key in each ever meaningful? (Keep
> in mind
> the definition of the domain of a foreign key.)

Yes, of course, it is.

> 3. in the semantic realm you use to "think about" relational databases
> (i.e., E-R,
> facts, etc.), does a join between two relations on a foreign key in
> each make sense?

Yes, it does.

> I request that you spend at least 10 minutes thinking about this
> before you flame
> me.

I don't know why you think it would take 10 minutes to answer such basic
questions.

[Rob]

On Oct 1, 11:09 am, Rob <rmpsf...@gmail.com> wrote:
> First, let me qualify my interests. I am primarily interesested in the
> mechanics of
> relational database management, not the semantics. I am interested in
> the evaluation
> of sql queries without regard to their meaning.
>

Mechanically, there is nothing to it. A join between two relations
requires only
that the join attributes have identical domains. According to Codd
(original 1970
paper), "We shall call a domain of relation R a foreign key if it is
not the
primary key of R but its elements are values of the primary key of
some
relation S." This is not exactly the same as saying that "the domain
of
the foreign key is the domain of the primary key" -- given the time-
varying
nature of relations, it seems to imply that the referenced value
actually
exists at the time R is defined. That is somewhat bizarre.

Codd's definition also implies that if relations R and T are joined on
foreign keys (one
in each of R and T), then both foreign keys have the identical domain.
So again, given
the time-varying nature of relations, it must be the case that the the
domains of the
foreign keys are indeed the domain of the primary key, not the sets of
existing values. (There
is room for disagreement here, but this is an incidental curiosity. I
think Codd's definition
of a foreign key domain is literally too restrictive.)

So, the only way foreignkey-foreignkey joins make sense is if both
joining relations R and T
are defined with a foreign keys referencing the same relation S on the
same pirmary key.
(This is more restrictive than saying each has the same domain as the
primary key of
the referenced relation.)

If R and T are the same relation, then the join reveals a sibling
relationship among
tuples of a single type. That is meaningful and might be of use in
some applications.

But if R and T are different relations, then what relationship does
the join reveal? It
looks a little like a "cousin" relationship, but R and T are different
types whereas
cousins would be the same type. So what in general would it mean if r
in R and t
in T get joined?

This is why I am asking the question in the mathematical [algebra]
realm or in the
semantics realm (of E-R or facts or ?). I simply cannot figure out
what the semantic
meaning is for a foreignkey-foreignkey join. Yet two responders say
they've used them.
Why? What question got answered?

I've designed hundreds of databases. After contemplating it long and
hard, I seriously
doubt I ever used a foreignkey-foreign key join in the queries I
authored for use with
these databases. Not because it was disallowed, but because
it lacks meaning. So if others have used these ("no big deal",
"Obviously, I have"), then what
was the meaning in the context of the databases where it was used?

Any help here is geniunely appreciated.

Rob

NOTE1: If R and T both reference S, then a R-S-T select query might
get optimized
to exclude S if no non-key attributes of S are included in either the
Select
subclause or the Where subclause. In that case, the optimizer would
be mechanically transforming the R-S-T query into a R-T query. That
doesn't address the higher-level issue of what an R-T query means.

NOTE2: (With apologies to those who discredit E-R modeling.) If R
and T both reference S, then in the E-R schema graph, there will
be an edge between R and S and between T and S, but not between
R and T. Edges correspond to causal relationships and joins between
connected entities reveal these relationships. Joins between
unconnected
relationships correspond to coincidental relationships ("Give me all
suppliers and projects located in the same city.") But detection
of coincidences based on non-key attributes (i.e., city) is not
quite the same as coincidences based on foreign keys. Puzzling.

NOTE3: (to Cimode) If I am designing an optimer, I could include
optimization of queries that include foreignkey-foreignkey joins.
But if such queries never get asked, why bother? Your inference
that I don't understand meaning is unfounded. I just can't find
meaning in these particular foreignkey-foreignkey joins.

[paul c]

On Oct 1, 2:07 pm, Rob <rmpsf...@gmail.com> wrote:
...

> I've designed hundreds of databases. After contemplating it long and
> hard, I seriously
> doubt I ever used a foreignkey-foreign key join in the queries I
> authored for use with
> these databases. Not because it was disallowed, but because

> it lacks meaning. ...

There must be thousands of db's that have Shipments, Invoices and
Receivables tables with a foreign key referencing a Customer table.
Obviously there will be people who will want to join two or more of
those tables to compare Shipment_Value to Invoice_Amount or
Receivable_Amount.

Of course there are probably thousands, maybe millions, of people who
have designed hundreds of databases that used no such join. And,
probably thousands of people who have designed dozens of databases
that used only such joins.

[paul c]

On Oct 1, 2:07 pm, Rob <rmpsf...@gmail.com> wrote:
...

> Mechanically, there is nothing to it. ...

Mechanically, there is plenty to it. The first SQL implementers were
obviously terrified of joins, which in part led to the conceptual mess
we have today such as screwball concepts like inner and outer joins,
ON DELETE CASCADE, etc. The official SQL standard is of such a size
that no single person could master it and have time left over for
anything else.

[Rob]

In my original post, I asked (first) for a gut reaction. Yours is a
gut
reaction and happens to coincide with my own. But gut reactions
can be misguided.

For example, those people who "will want to join two or more of

those tables to compare Shipment_Value to Invoice_Amount or

Receivable_Amount" will likely do so THROUGH the Customer
table so as to provide a Customer attribute that identifies the rows
of the
result. How many would do it without the Customer table?

As for the thousand, millions, hundreds, thousands and
dozens of which you write, that is more gut feeling. Let's
leave the monkeys-and-typewriters and statistical arguments
behind. The semantics (as opposed to the mechanics) of
foreignkey-foreignkey joins are not without questions.

What I'm really trying to get at is whether a foreignkey-foreignkey
join makes sense algebraically, and if so, do operations in higher-
level
abstractions (like E-R, facts) translate to them?

[Erwin]

A (natural) JOIN is an associative operation. To speak of joins as if
they are "THROUGH a table" is to expose ones ignorance of the
relational algebra, or it is to expose ones failure to properly
distinguish between model (the JOIN itself) and implementation (the
evaluation strategy as chosen by the engine that executes the query),
or it exposes yet some other important piece of knowledge that is
lacking in your brain.

Take any set of 6NF relvars. For example, CUST {CUST_ID} , CUST_DOB
{CUST_ID, DOB} , CUST_SAL {CUST_ID, SAL} , with key CUST_ID in each
and FK CUST_ID in the latter two. Now write the query that gives me
the customer ID of all the customers for which both date of birth and
salary are known. Hint : if you include my CUST relvar, then you've
got a relvar too many.

> What I'm really trying to get at is whether a foreignkey-foreignkey
> join makes sense algebraically,

Contradiction of terms. Nothing ever makes sense "algebraically".
"Making sense" refers to "having some meaning", and that requires, by
definition, the consideration of semantics, which you say you do not
intend to consider.

"Algebraically", one can, at best, only speak of "valid expressions of
the algebra" or so. Which is a bit of a superfluous qualification,
because "invalid expressions of the algebra" just aren't expressions
of the algebra to begin with.

> and if so, do operations in higher-level
> abstractions (like E-R, facts) translate to them?

You've got things the wrong way round. Relvars are associated with an
external predicate, which "documents" the "meaning" that is
represented by [the tuples in] it. Expressions of the relational
algebra that have such relvars for constituent components, also have
an external predicate associated with it, documenting in turn what
"meaning" is represented by [the tuples in] the relation value
resulting from evaluating the expression.

For example, if we have relvars R1 and R2 with predicates P(R1) and
P(R2), respectively, then the external predicate associated with R1
INTERSECT R2 is "P(R1) AND P(R2)".

Whether that external predicate is useful to the end user is another
matter (in fact it is the matter of whether or not the expression will
ever get written : if that predicate is useful, then the expression
will get written).

[paul c]

On Oct 2, 10:58 am, Rob <rmpsf...@gmail.com> wrote:
...

> For example, those people who "will want to join two or more of
> those tables to compare Shipment_Value to Invoice_Amount or
> Receivable_Amount" will likely do so THROUGH the Customer
> table so as to provide a Customer attribute that identifies the rows
> of the
> result. How many would do it without the Customer table?

> ...

Plenty. For one, the preparation of financial statements doesn't
require Customer information. That is a simple fact, not a gut
reaction.

...

> What I'm really trying to get at is whether a foreignkey-foreignkey

> join makes sense algebraically, ...

It makes sense in the same sense that 2 + 2 makes sense in a numerical
algebra, whereas 2 - / 2 doesn't make sense. Looks like you are
changing questions, the latest seems quite insensible.

> ... and if so, do operations in higher-level

> abstractions (like E-R, facts) translate to them?

What the heck are the operations of E-R? Now it's even harder to make
sense of your theme, can't tell what you mean by 'translate' -
mechanical, logical, mystical or what? Looks like you don't even know
what your question is, which will make it impossible to assess
answers.

[Rob]

In spite of my ignorance, my failures and/or my brain deficiencies,
(or perhaps because of them), you understood EXACTLY what I meant by
(the associative preposition) THROUGH. And, you came to the identical
conclusion: When no "parent" attributes are required, the result could
be obtained without access to the parent relation. The "Hint" just
says that a clever person doesn't need an optimizer to avoid the
additional join. But I believe my observation is basically correct,
that most sql authors would not catch it. (I also doubt any optimizer
would catch it, but that's another matter.)

However, if it were CUST(CUST_ID,CUST_NAME) where CUST_ID was some
opaque value, one could write the query as you suggest without CUST,
but then the result would not indicate which CUST has known date-of-
birth and salary. The result would only indicate the existence of such
CUSTs. And that existence inference would itself be based upon the
existence of a foreign key reference, with no certainty that the
referenced tuple actually exists. (Does anyone else see a problem with
that? What if referential integrity were not declared? Would that not
imply that a well-formed query on a correctly defined database COULD
produce incorrect results?)

As for the rest of your reply, you do not address whether higher-level
abstractions can map to this questionable construction.

[com...@hotmail.com]

On Oct 1, 10:09 am, Rob <rmpsf...@gmail.com> wrote:
> is a join
> between two relations on a foreign key in each ever meaningful?

On Oct 2, 10:58 am, Rob <rmpsf...@gmail.com> wrote:

> What I'm really trying to get at is whether a foreignkey-foreignkey

> join makes sense algebraically, and if so, do operations in higher-

> level
> abstractions (like E-R, facts) translate to them?

Rob,

I will enter this thread as I do most: you really don't understand the
relational model.

1.
(I quote Erwin for his versions of things I am saying.)

On Oct 3, 4:27 am, Erwin <e.sm...@myonline.be> wrote:
> Relvars are associated with an
> external predicate, which "documents" the "meaning" that is
> represented by [the tuples in] it.

Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)
of part Y, and Z units of part X are needed to assemble one unit of
part Y". Such a parameterized statement is a 'predicate'. Codd meant
that for modern relation (his "relationship") "the predicate for
COMPONENT is that part SUB-PART is an immediate component (or
subassembly) of part SUPER-PART, and QUANTITY units of part SUB-PART
are needed to assemble one unit of part SUPER-PART". And that we might
want to write "COMPONENT(X, Y, Z)" for "<SUB-PART X, SUPER-PART Y,
QUANTITY Z> IN COMPONENT".

When you give values for X, Y and Z or SUB.PART, SUPER.PART and
QUANTITY you get a 'proposition', which is a statement that either
holds or does not hold in a given world situation. ('Has truth value'
'TRUE' or 'FALSE'.)

The (relational) extension of a predicate is the relation whose body
is the set of tuples that make it into a proposition that holds in a
given world situation. So we say (informally) that a relation is the
extension of a predicate. A relation's attributes are the parameters
of its predicate.

2.
Each query relation expression has a predicate as follows. (This
correspondence is typically described as "informal" (and spoken of
vaguely if at all) but that is incorrect.)

On Oct 3, 4:27 am, Erwin <e.sm...@myonline.be> wrote:
> For example, if we have relvars R1 and R2 with predicates P(R1) and
> P(R2), respectively, then the external predicate associated with R1
> INTERSECT R2 is "P(R1) AND P(R2)".

The predicate of a relation expression that is a name of a relation
variable or constant is its predicate. The predicate of a relation
expression that is a JOIN is the AND of the predicates its operands;
of a UNION is the OR; of a MINUS is the AND NOT; of a RESTRICT X=Y or
of an ADD X AS Y is the AND X=Y; and of a PROJECTALLBUT X is the
EXISTS X.

The value of a query relation expression that is a relation name is
its named relation's predicate's extension. Each relation operator is
defined so that if its operand values are the extensions of their
predicates then its result is the extension of its predicate. (As can
be shown. Codd and (ADD) Hall et all defined them so this would be the
case.) So by induction every query relation expression value is the
extension of its predicate.

So the predicate and result value of a query relation expression is
independent of whether any normalization has been done or constraints
have been defined.

3.
Given the named relations' predicates and possible world situations,
of the syntactically typed database values certain ('valid') values
could arise and other ('invalid') ones definitely do not.
The DBMS evaluates a dba-given overall database constraint expression
and allows an assignment if and only if a proposed database value is
valid. (This involves further relation operators for equality and
nesting/aggregation.) So for values that the user got from (correctly)
evaluating the predicates on every tuple for the world situation (all
valid by definition), by this policy none is excluded and all are
included.

On Oct 3, 4:27 am, Erwin <e.sm...@myonline.be> wrote:
> You've got things the wrong way round.

The constraint expressions tell the user something if and only if the
user doesn't know all the possible world situations. But a query
predicate only ever depends on its relation expression and the named
relations' predicates and its result value only further on the named
relations' values. Neither depend on constraint expressions. (Of
course, they are correlated with them.) Constraint expressions
constrain updates. They do not constrain valid database values or
affect query predicates or result values. If the user never made a
mistake (incorrectly including/excluding tuples contrary to their
named relations' predicates and the world situation) they would not
need constraint expressions.

Of course, the constraint expressions are also telling or confirming
to the user important truths about the possible world situations in
terms of the named relations' predicates; and can help the user
understand those predicates and the world; and can help the user to
rephrase queries and the DBMS to optimize queries. A constraint
expression just expresses a truth.

4.
Modern normalization/dependency theory says that there is a foreign
key on attribute set K from a target D into a target F (domestic/
foreign) in a database when in all possible world situations ie in all
valid database states K forms a key in F and all the subtuple values
for K in D are also in F. (We can also speak of it being a foreign key
in a given situation.)

So there is a foreign key constraint on K from D to F if and only if
certain expressions express certain things that hold in every world
situation. This could happen for any two database named relations;
it's just a relationship that happens to always hold for pairs of
values of D and F in that database. And just like every constraint
expression's proposition, the only way in which this has anything to
do with a query predicate or result value is that the possible world
situations and the named relations' predicates collectively determine
them all.

5.
The "relationship" with predicate "there is a foreign key on attribute
set {...} from named relation R and T to named relation S" is a fact
that either holds or does not hold. As a predicate, it is a
proposition. It is a relationship on nothing. Its extension ie
relation is DEE. In practice we don't mean a fact when we say
"relationship". (Historically, TRUE and FALSE aren't even wffs.)

You seem interested in the constraint-oriented "relationship" FK on K,
D and F (in that order in wffs) with predicate "there is a foreign key
on attribute set K from named relation D to named relation F". Note
that D and F denote the names of named relations, not relation values.
Note also that a foreign key relationship holds on a K, D and F when a
certain thing is the case for all valid database values. You seem
interested in constraint propositions on expression "S JOIN T" that
can be inferred from certain constraint propositions on S and T when
EXISTS X, SR, ST: FK(X, R, SR) AND FK(X, T, ST). Ie when the
proposition "there is set X such that a foreign key on attribute set X
from named relations R and T to named relations SR and ST
respectively" holds.

We can have foreign keys on arbitrary expressions. So we can have FKe
with predicate "there is a foreign key on attribute set K from
expression D to expression F". It happens to be the case that that
FKe(k, "R", "SR") AND FKe(k, "T", "ST") implies FKe(k, "R JOIN T",
"SR"). Also that FKe(k, "R JOIN T", "ST") . Also that R{K} SUBSETOF (R
JOIN T){K}, and T{K} SUBSETOF (R JOIN T){K}. And lots of other things.
(But not "relationships".) Though I suspect you are interested in the
first two. (Do you care whether both foreign keys are to be to the
same target? They needn't.) Note that FKe is the relationship; FKe(k,
"R JOIN T", "S") is a fact that holds when Fe(k, "R", "S") AND Fe(k,
"T", "S") holds.

But a JOIN does not "reveal" any of this. Evaluating S JOIN T for a
particular world situation just tells you certain things are true of
that world situation per the predicates of S and T. The predicates and
facts above don't even involve the same world as the JOIN and named
relation predicates. It is the properties of FK and JOIN that have
relevant consequences.

Nothing "reveals" a relationship. It is meaningless to talk about
"the" relationship between some attributes/parameters. A predicate or
an extension/relation each tell you something about a relationship
independent of a world situation. You are not talking about a
particular relationship unless you have both its predicate and a world
situation or its predicate and its extension. Do not confuse
relationships, predicates, extensions/relations and propositions.
Don't even use the word 'relationship'.)

6.
So every JOIN just says that you want the tuples that make two other
predicates true at the same time. Regardless of constraint
expressions. Every relation expression is "meaningful". And you are
probably actually interested in constraint (proposition) inference.

So most of the sentences in your posts don't make sense. You are not
clear and you don't seem to have the relational understanding or
habits of thinking and writing to characterize your problem.

Working through any example you choose might help make this clear to
you. You might be interested in message
http://groups.google.com/group/comp.databases.theory/msg/1963ce6c0d2a603a?hl=en
. Also give up Codd, especially 40 years ago. (Which you misread,
although you're right about a certain unnecessary restriction.) Read
recent Date and Darwen.

7.
On Oct 3, 11:05 am, Rob <rmpsf...@gmail.com> wrote:
> On Oct 3, 4:27 am, Erwin <e.sm...@myonline.be> wrote:
>> [...]

> As for the rest of your reply, you do not address whether higher-level
> abstractions can map to this questionable construction.

Your reply to Erwin basically totally misunderstands him. And his post
was entirely on-topic.

On Oct 2, 9:07 am, paul c <toledobythe...@gmail.com> wrote:
> On Oct 1, 2:07 pm, Rob <rmpsf...@gmail.com> wrote:

> There must be thousands of db's that have Shipments, Invoices and
> Receivables tables with a foreign key referencing a Customer table.
> Obviously there will be people who will want to join two or more of
> those tables to compare Shipment_Value to Invoice_Amount or
> Receivable_Amount.
>
> Of course there are probably thousands, maybe millions, of people who
> have designed hundreds of databases that used no such join. And,
> probably thousands of people who have designed dozens of databases
> that used only such joins.

I believe Paul's point was not about gut reactions but that of course
such JOINs are meaningful.

On Oct 1, 2:07 pm, Rob <rmpsf...@gmail.com> wrote:

> Any help here is genuinely appreciated.

I believe you mean this, but I don't believe you know what it means.
Read and reread carefully. Think and write and rethink and rewrite
carefully. Don't disagree. Ask people to clarify what they mean. Every
time you disagreed you were wrong, and every time you agreed you
misunderstood. When world views collide, resolve contradictions, doubt
confirmations.

Thank you for the opportunity to clarify my thoughts and their
expression. (Ten minutes well spent.) (Joke.) (The ten minutes.)

philip

[vldm10]

> you. You might be interested in messagehttp://groups.google.com/group/comp.databases.theory/msg/1963ce6c0d2a...

In contrast to your conclusion, Rob's posts are good; on the other
hand I'm not sure that you are clear enough in your statements.

I think that we can generalize Rob's remarks. Therefore I would like
to ask you the following question: What does mean the pair (foreign-
key, primary-key) in terms of database design? What do you design with
this pair?
For the above-mentioned pair, it may happen that data from
"referencing table" or from "referenced table" is incorrect. The
attributes in each relation can be changed over time. Many things can
happen in real life.

You also commonly used undefined terms that are of fundamental
importance for db theory as well as for some others important science.

Could you give a definition (or description) of the following terms:
the world, the situation and the possible. For example, in several
places you use the term: "possible world situation"?
Note that the terms "world", "situation" and "possible" does not exist
in the RM.

It seems to me that you are not clear about predicates and that you
don’t seem to have understanding about a nature of the predicates.
It would be good if you can give us a definition of a predicate. Also
give us a definition of the extensionality (of predicate). Do you mean
here on the extensionality of atomic predicates? Do you use some
"interpretation" here or do you use a definition of truth? Do you use
second-order logic? (For example, the Leibniz's Law)

Note that the predicate is a linguistic construct. So, once again,
please give us a definition of a predicate.

Also could you give us a definition of the attributes in RM. (and
especially of the attributes in the structures determined with the
pair (foreign-key, primary-key)).

When you write about the meaning you are actually writing about the
truth value of the
corresponding proposition. Note that the truth is related just to
sentences. This, however, does not apply to the meaning also.
We can also notice that interrogative (query) sentence has no truth-
value.

Since you're trying ”to translate” a formal language for Predicate
Logic into English language, I have the following two questions:

1. What are the differences between formal languages and natural
languages?
2. Can semantics for formal languages be useful for natural languages?

Rob was asked questions related to time-varying nature of relations.
He also asked some questions related to semantics. In your response to
Rob you are advising him to "Read recent Date and Darwen". You also
give him examples of Codd’s work that are related to the semantics and
meaning.
Codd's work related to the database is very important. But his work on
semantics and time-varying relations is of no importance.
Date and Darwen in "Third Manifesto" have done great and good work.
But their work on semantics and time-varying relations is of no
importance.
Therefore, your recommendation to Rob that he should read Date, Darwen
and Codd has no sense.
--

(To Erwin) On October 3, in this thread, Erwin wrote: “Take any set of

6NF relvars. For example, CUST {CUST_ID}, CUST_DOB {CUST_ID, DOB},

…”

I would like to say that the identifier (ID) is poorly constructed. In
my opinion, in today’s existing software, these identifiers are
wrongly constructed. In fact for their construction there are no
rules. I am not talking about their industry standards but about db
design related to these identifiers. I explained on my website how to
construct this identifier.
See http://www.dbdesign11.com

Vladimir Odrljin

[com...@hotmail.com]

Vladimir,

1.

> On Monday, January 2, 2012 5:20:48 AM UTC-8, vldm10 wrote:
> Could you give a definition (or description) of the following terms:
> the world, the situation and the possible.

I just mean certain usual notions for logic and for states. A database
changes state as it keeps describing some changing "world". A
particular database state value describes a particular "situation".
(So predicate logic uses a single situation; a dbms uses a sequence of
them.) By "possible" situation I just mean a situation that could
arise as the world changes.

> Also could you give us a definition of the attributes in RM.

I just mean the usual unordered-attributes notion. A tuple is a set of
attribute name-and-something pairs with a given name only appearing
once. A relation has a heading and a body. A heading is a tuple of
name-and-type pairs. A body is a set of tuples of name-and-value
pairs. The heading and body tuples all have the same names. For each
name every body value paired with it is of the heading type paired
with it. I usually shorten "attribute name" to "attribute".

2.
My last message already answers, contradicts, or obviates your other
comments. Rather than me cutting and pasting the answers could you try
finding them? Though I'll do a few:

> It would be good if you can give us a definition of a predicate.

> > Such a parameterized statement is a 'predicate'. Codd meant
> > that for modern relation (his "relationship") "the predicate for
> > COMPONENT is that part SUB-PART is an immediate component (or
> > subassembly) of part SUPER-PART, and QUANTITY units of part SUB-PART
> > are needed to assemble one unit of part SUPER-PART".

> Note that the predicate is a linguistic construct.

> > When you give values for [...] SUB.PART, SUPER.PART and

> > QUANTITY you get a 'proposition', which is a statement that either
> > holds or does not hold in a given world situation. ('Has truth value'
> > 'TRUE' or 'FALSE'.)

"Predicate" gets used in lots of ways. I am using it as a mapping from
a tuple to a proposition, with a proposition a mapping from a
situation to a truth value reflecting whether the situation is a
certain way. In other words a certain usual predicate logic notion. (A
wff predicate symbol's interpretation/extension set (ordered-relation)
is determined by a predicate/function/mapping which maps a tuple to a
statement/proposition/function/mapping which maps a situation to a
truth value.)

> Also
> give us a definition of the extensionality (of predicate).

> > The (relational) extension of a predicate is the relation whose body
> > is the set of tuples that make it into a proposition that holds in a
> > given world situation.

> Since you're trying ”to translate” a formal language for Predicate
> Logic into English language

No, I am clearly not:

> > Each query relation expression has a predicate as follows.

The source of my translation is a relation expression. The target of
my translation is a predicate. I don't care how you write the
predicate.

> Note that the terms "world", "situation" and "possible" does not exist
> in the RM.

The concepts do:

> > (This
> > correspondence is typically described as "informal" (and spoken of
> > vaguely if at all) but that is incorrect.)

You cannot set the relation variables without observing the world and
knowing what their predicates (parametrically) say about the the
world. You cannot understand a query or its value without knowing the
named relation predicates and what they (parametrically) say about the
world. (Same for predicate symbols and wffs in predicate logic.) And
the named relation predicates plus all possible situations determine
possible states and so constraints.

> When you write about the meaning you are actually writing about the
> truth value of the
> corresponding proposition.

No, I am not:

> > Each query relation expression has a predicate as follows.

"Meaning" gets used in lots of ways. I am giving a
"predicate" ("parameterized proposition") as "meaning" of a "relation
expression" in the relational model. (In the everyday sense a sentence/
proposition is itself a "meaning"; it merely "has" a truth value. In
predicate logic a predicate symbol has a "meaning" (in a different
sense) that is an interpretation/extension set. And a sentential wff
has a "meaning" (in a different sense) that is a truth value.) I would
agree that the "meaning" (in yet another sense) of a 0-tuple query
result is a truth value. And I would agree that the "meaning" (in yet
another sense) of a query value is the (necessarily true) proposition
that is the conjunction of its present-tuple propositions and its
negated absent-tuple propositions.

> We can also notice that interrogative (query) sentence has no truth-
> value.

> > So by induction every query relation expression value is the
> > extension of its predicate

> > The (relational) extension of a predicate is the relation whose body
> > is the set of tuples that make it into a proposition that holds in a
> > given world situation.

> > A relation's attributes are the parameters
> > of its predicate.

Your comment is specious. A query is a relation expression is a
predicate, is a relation value, is (for 0-tuples) a truth value, is a
(true) proposition (via substituting body tuples into its predicate),
is a request for a relation value, is a request for a truth value, is
a request for a (true) proposition. How we use terms colloquial terms
is irrelevant.

3.

> What does mean the pair (foreign-
> key, primary-key) in terms of database design? What do you design with
> this pair?

> > Constraint expressions
> > constrain updates. They do not constrain valid database values or
> > affect query predicates or result values.

> > Modern normalization/dependency theory says that there is a foreign

> > key on attribute set K from a [source] D into a target F (domestic/

> > foreign) in a database when in all possible world situations ie in all
> > valid database states K forms a key in F and all the subtuple values
> > for K in D are also in F.

> > This could happen for any two database named relations;
> > it's just a relationship that happens to always hold for pairs of
> > values of D and F in that database.

If you wrote out named relation predicates then you would see that SQL
"subtables" and ER "subtyping" involve propositions that are facts/
truths in all states. Like that is_a_s_thing(k1, ...) IMPLIES
is_a_r_thing(k1, ...); ie that (s PROJECT {k1, ...}) SUBSETOF (r
PROJECT {k1, ...}); ie that there is an inclusion dependency on
{k1, ...} from "s" to "r". And that if also {k1, ...} is a key in r
then also there is a foreign key on {k1, ...} from "s" to "r".

Rob confused (changing) parent-child edges in the graph of a variable/
query relation value with those in the graph(s) of the (simultaneously
meta, constant, redundant and operator-irrelevant) foreign key
relation and/or subtable/subtype relation(s). And whether such facts/
truths hold has no bearing on what a query "means". You need to
understand query predicates to understand the details and the
explanation of this.

4.
I expect to not necessarily be clear in a terse post. But you don't
seem to have read closely enough to understand me. You misread me or
you see a homonym and assume a meaning. Instead of trying to
understand the (precise) system I tried to described. I hope things
are clearer now.

philip

[com...@hotmail.com]

Typos.

On Jan 9, 10:29 pm, com...@hotmail.com wrote:
> A query is a relation expression is a
> predicate, is a relation value, is (for 0-tuples) a truth value, is a
> (true) proposition (via substituting body tuples into its predicate),
> is a request for a relation value, is a request for a truth value, is
> a request for a (true) proposition. How we use terms colloquial terms
> is irrelevant.

A query is a relation expression, is a
predicate, is a relation value, is (for 0-attribute values) a truth
value, is a
(true) proposition (via substituting present and absent tuples into

its predicate),
is a request for a relation value, is a request for a truth value, is

a request for a (true) proposition. But how we use colloquial terms
is irrelevant.
philip

[vldm10]

I was busy with other things so that is the reason for this delayed
replay. I don’t think your responses to my questions were precise
enough.

1.
My first question was: What does mean the pair (foreign-key, primary-

key) in terms of database design? What do you design with this pair?

The database design is a very important step in constructing a
database. Therefore, the database theory should include the part that
relates to the database design. So in my opinion, a description of
foreign keys in the terms of relations and predicates is not a theory
about constructing, building and designing. Note that foreign key is
not exclusively term from RM. As far as I know the foreign key is the
construction which comes from COBOL’s applications.

2.
I would like to say that this whole story about "predicates-relations-
statements”, has already been done by Gottlob Frege, 120 years ago.
Frege’s theory is very powerful and complex, so I will explain it here
in the simplest form. According to G. Frege, predicates are applied to
objects and he defines the predicates as follows:

A predicate is any incomplete phrase with specified gaps such that
when the gaps are filled with names of things the phrase becomes a
proposition.

Note that here we have “things” i.e. individuals or entities. That is
why I cannot accept your opinion about entities.

3.
The example that you posted:

Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)

of part Y, and Z units of part X are needed to assemble one unit of
part Y".

is confusing, because it is not clear what are the attributes here and
what is the corresponding entity. (The example seems like it is about
Mereolgy.)
If this is not seeking the meaning of an entity, then it should be
given a definition of meaning. The meaning of a name can be very
complex. (this is related to the names of the attributes)

4.
The following terms are undefined: the world, the situation of the
world, the state of the world, the state of a database, and the states
of affairs. It is widely known that the term “the world” is not
defined in philosophy.
In my papers I defined the state of an entity and relationship as
subject's knowledge.
--

In your sentence: "A body is a set of tuples of name-and-value pairs"
instead of
name-and-value pairs you can put name-and-name pairs, because the
value is in fact name (for this value). So when we assign a value to a
variable, then we can say (semantically) that we "bind" the name of
the value with the name of the variable.

I think that the following paragraph should be revised:

> "Meaning" gets used in lots of ways. I am giving a
> "predicate" ("parameterized proposition") as "meaning" of a "relation
> expression" in the relational model. (In the everyday sense a sentence/
> proposition is itself a "meaning"; it merely "has" a truth value. In
> predicate logic a predicate symbol has a "meaning" (in a different
> sense) that is an interpretation/extension set. And a sentential wff
> has a "meaning" (in a different sense) that is a truth value.)

Vladimir Odrljin

[com...@hotmail.com]

On Monday, March 5, 2012 6:51:50 PM UTC-8, vldm10 wrote:
> On 10 sij, 07:29, com...@hotmail.com wrote:

Vladimir,

> My first question was: What does mean the pair (foreign-key, primary-
> key) in terms of database design? What do you design with this pair?

> > > What does mean the pair (foreign-
> > > key, primary-key) in terms of database design? What do you design with
> > > this pair?

> > > > Modern normalization/dependency theory says that there is a foreign
> > > > key on attribute set K from a [source] D into a target F (domestic/
> > > > foreign) in a database when in all possible world situations ie in all
> > > > valid database states K forms a key in F and all the subtuple values
> > > > for K in D are also in F.
> > > > This could happen for any two database named relations;
> > > > it's just a relationship that happens to always hold for pairs of
> > > > values of D and F in that database.

To understand the answer to your question you have to learn a bunch of
things and unlearn a bunch of things.

All primary keys are (candidate) keys. Picking one as primary has no
more formal meaning than picking the name of an attribute or variable.

The dba gives a predicate for each relation variable. The user puts
into a relation variable the tuples that turn the predicate into a
true statement.

The (natural) join of two relations is always on common attributes.
The result body holds the tuples that make <<the predicate of one> AND
<the predicate of the other>> into a true statement.

Predicates:
COMPONENT(X, Y, Z)
a X is an immediate component (or subassembly) of aY,
and Z units of a X are needed to assemble one unit of a Y
WANT(Y) I want a Y

Variables:
COMPONENT <X part, Y part, Z part> {<leg, pony, 4>, <torso, pony,
1>}
WANT <Y part> {<pony>, <ball>}

What the database says:
a leg is an immediate component (or subassembly) of a pony, and 4
units of a leg are needed to assemble one unit of a pony
AND a torso is an immediate component (or subassembly) of a pony, and
1 unit of a torso is needed to assemble one unit of a pony
AND it is not the case that <a leg is an immediate component (or
subassembly) of a pony, and 7 units of a head is needed to assemble
one unit of a pony>
AND it is not the case that <a wheel is an immediate component (or
subassembly) of a pony, and 18 units of a wheel are needed to assemble
one unit of a pony>
AND it is not the case that ... per any other absent COMPONENT tuple
either
AND I want a pony AND I want a ball AND I don't want a wheel AND I
don't want a leg
AND it is not the case that ... per any other absent WANT tuple either

Query: WANT JOIN COMPONENT
By the definition of JOIN this returns X, Y and Z such that I want a Y
AND a X is an immediate component (or subassembly) of a Y, and Z units
of a X are needed to assemble one unit of a Y.
Result: <X part, Y part, Z part> {<leg, pony, 4>, <torso, pony, 1>
What the query says:
I want a pony AND a leg is an immediate component (or subassembly) of
a pony, and 4 units of a leg are needed to assemble one unit of a pony
AND
I want a pony AND a torso is an immediate component (or subassembly)
of a pony, and 1 unit of a torso is needed to assemble one unit of a
pony
AND
it is not the case that <I want a pony AND a leg is an immediate
component (or subassembly) of a pony, and 3 units of a leg are needed
to assemble one unit of a pony>
AND it is not the case that ... per any other absent query tuple
either

If the relation variable predicates happen to be such that you could
(and did or didn't) declare a foreign key from an attribute set in one
relation variable to another then the tuples in the result will be
limited in a certain unchanging way describable independently of what
tuples are in them at any particular time; the limitation that we call
a foreign key constraint. Nevertheless, the result will still be the
tuples that make <<the predicate of one> AND <the predicate of the
other>> into a true statement. Just declare the keys and foreign keys
and other constraints to avoid update errors.

> So in my opinion, a description of
> foreign keys in the terms of relations and predicates is not a theory
> about constructing, building and designing.

I have tried to inform you. Try:
http://bookboon.com/en/textbooks/it-programming/an-introduction-to-relational-database-theory
http://www.fecundity.com/logic/download.html

> why I cannot accept your opinion about entities.

Several of us have told you that ER is at best a heuristic to
determine predicates.

> In your sentence: "A body is a set of tuples of name-and-value pairs"
> instead of
> name-and-value pairs you can put name-and-name pairs, because the
> value is in fact name (for this value). So when we assign a value to a
> variable, then we can say (semantically) that we "bind" the name of
> the value with the name of the variable.

One can characterize a rational number (a kind of value) as having two
parts, a numerator and a denominator, each an integer (a kind of
value) (not numeral). I characterized a relation, not a relation
variable. A tuple (a kind value) in the body part of a relation (a
kind of value) has name and value pairs (a kind of value) as attribute
parts.

If you want to become informed, I suggest you read the links and try
to understand what I wrote instead of balking.

good luck,
philip

[com...@hotmail.com]

On Thursday, 15 March 2012 14:40:15 UTC-7, com...@hotmail.com wrote:
> > > > > Modern normalization/dependency theory says that there is a foreign
> > > > > key on attribute set K from a [source] D into a target F (domestic/
> > > > > foreign) in a database when in all possible world situations ie in all
> > > > > valid database states K forms a key in F and all the subtuple values
> > > > > for K in D are also in F.
> > > > > This could happen for any two database named relations;
> > > > > it's just a relationship that happens to always hold for pairs of
> > > > > values of D and F in that database.

> COMPONENT <X part, Y part, Z part> {<leg, pony, 4>, <torso, pony, 1>}
> WANT <Y part> {<pony> , <ball>}

Of course this should be:
COMPONENT <X part, Y part, Z int> {<leg, pony, 4>, <torso, pony, 1>}

WANT <Y part> {<pony> , <ball>}

> COMPONENT(X, Y, Z)
> a X is an immediate component (or subassembly) of aY,
> and Z units of a X are needed to assemble one unit of a Y
> WANT(Y) I want a Y

If you want to associate a relation variable with some entities, give an appropriate predicate. Clearly the predicates I gave involve wanted parts, composed/assembled parts, component parts, component/assembly counts, ponies, legs, torsos, balls, units, the number 1, etc.

Regarding foreign keys:

Suppose {K} is a key of WANT.

Suppose that in detail COMPONENT is the breakdown of certain toys, wanted or not, and can sometimes contain Y values not in WANT. Then there is not a foreign key from COMPONENT{Y} to WANT{Y}. (Because COMPONENT{Y} subtuples are not always WANT{Y} subtuples.)

But suppose that in detail COMPONENT is the breakdown of wanted toys. Then there is a foreign key from COMPONENT {Y} to WANT {Y}. (Because COMPONENT{Y} subtuples are always WANT{Y} subtuples.)

Either way, WANT JOIN COMPONENT always means the same thing in terms of WANT and COMPONENT: those X-Y-Z tuples for which WANT(Y) AND COMPONENT(X, Y, Z).

All that there being or not being a foreign key from COMPONENT to WANT on {K} tells you is whether a certain thing is true that FOLLOWS FROM THE PREDICATES anyway. Namely the "foreign key" situation, namely whether the first variable projected on the subtuples is always a subset of the second variable projected on the subtuples and the subtuples form a key of the second variable. You don't need to know this to use the database, you just determine whether the predicates are true or false of every possible tuple for each situation as it arises. (But if you understand in detail what world situations can arise then you can determine this.)

So a join always has a meaning: a statement from the tuples that do and don't make its arguments' predicates simultaneously true. And this meaning is otherwise independent of any constraints. (Foreign key or otherwise.) (The only correlation is that the constraints are always true.)

(For implementation optimization, it is helpful to know the constraints.)

again, good luck,
philip

[vldm10]

On 15 ožu, 23:40, com...@hotmail.com wrote:
> On Monday, March 5, 2012 6:51:50 PM UTC-8, vldm10 wrote:
> > On 10 sij, 07:29, com...@hotmail.com wrote:
>
> Vladimir,
>
> > My first question was: What does mean the pair (foreign-key, primary-
> > key) in terms of database design? What do you design with this pair?
> > > >  What does mean the pair (foreign-
> > > > key, primary-key) in terms of database design? What do you design with
> > > > this pair?
> > > > > Modern normalization/dependency theory says that there is a foreign
> > > > > key on attribute set K from a [source] D into a target F (domestic/
> > > > > foreign) in a database when in all possible world situations ie in all
> > > > > valid database states K forms a key in F and all the subtuple values
> > > > > for K in D are also in F.
> > > > >  This could happen for any two database named relations;
> > > > > it's just a relationship that happens to always hold for pairs of
> > > > > values of D and F in that database.
>
> To understand the answer to your question you have to learn a bunch of
> things and unlearn a bunch of things.
>

We do not understand one another regarding some important issues. I'll
try to explain it using the following simplified scheme:


The Real World (Data) Model


Regarding above schema we can ask the following questions:
1. What stands in this space that is between the real world and Model?
2. How to make a mathematical theory that connects all these pieces?

I think in the future, (new) mathematics will deal extensively with
these two issues.
I also think that you pay attention only to the model. However db also
works with real word objects.
In my model, I connected the real world, with a data model, using the
concepts (and still with many other things).

> All primary keys are (candidate) keys. Picking one as primary has no
> more formal meaning than picking the name of an attribute or variable.
>
> The dba gives a predicate for each relation variable. The user puts
> into a relation variable the tuples that turn the predicate into a
> true statement.
>
> The (natural) join of two relations is always on common attributes.
> The result body holds the tuples that make <<the predicate of one> AND
> <the predicate of the other>> into a true statement.
>
> Predicates:
> COMPONENT(X, Y, Z)
>   a X is an immediate component (or subassembly) of aY,
>   and Z units of a X are needed to assemble one unit of a Y
> WANT(Y) I want a  Y

If Y is name of an attribute, then X cannot be its part, because the
attributes are atomic.

> I have tried to inform you. Try:http://bookboon.com/en/textbooks/it-programming/an-introduction-to-re...http://www.fecundity.com/logic/download.html
>


I appreciate the work of Date & Darwen. Relational model that they
built and implemented is well done.
I also think that your technique in logic is very good. However, there
are some parts of the theory of databases, which in my opinion are not
resolved in the relational model.

> > why I cannot accept your opinion about entities.
>
> Several of us have told you that ER is at best a heuristic to
> determine predicates.
>
> > In your sentence: "A body is a set of tuples of name-and-value pairs"
> > instead of
> > name-and-value pairs you can put name-and-name pairs, because the
> > value is in fact name (for this value). So when we assign a value to a
> > variable, then we can say (semantically) that we "bind" the name of
> > the value with the name of the variable.
>
> One can characterize a rational number (a kind of value) as having two
> parts, a numerator and a denominator, each an integer (a kind of
> value) (not numeral). I characterized a relation, not a relation
> variable.

Characterization of an object is very different from giving the names
of the object. For example, characterization of an object can give a
wrong meaning for that object.

A tuple (a kind value) in the body part of a relation (a
> kind of value) has name and value pairs (a kind of value) as attribute
> parts.
>
> If you want to become informed, I suggest you read the links and try
> to understand what I wrote instead of balking.

Today I released a new paper, which I think resolves some problems in
the theory of databases. If you want to become informed, I suggest you
read the paper at http://www.dbdesign11.com called Semantic databases
and semantic machines.


> good luck,
> philip

Vladimir Odrljin

[James K. Lowden]

On Wed, 4 Apr 2012 16:06:47 -0700 (PDT)
vldm10 <vld...@yahoo.com> wrote:

> However db also
> works with real word objects.

I am not aware of any such DBMS. Every DBMS I've ever seen manages
(let us call them) "objects" that are mere software. They are in no
way "real world objects". It is the designer's job to define those
objects reflective of the real world, and the user's job to maintain
the modelled objects such that accurately reflect the real world. Only
then is the DBMS able to provide logical inferences from the
model that can be meanfully applied to the real world (again, by the
user).

--jkl

[vldm10]

I have not mentioned the DBMS. Please note that the db is very
different from the DBMS. Note also that the db is different from the
data model. So take time for yourself and clarify basic concepts.
Then, I hope, you will understand what it is "a real world
application".

[James K. Lowden]

O Guru, could you please explain the parable of the db? I have
meditated naked on the mountaintop under the stars for a fortnight, yet
comes to me no vision, no wisdom, only this lousy hacking cough.

--jkl

[com...@hotmail.com]

On Wednesday, 4 April 2012 16:06:47 UTC-7, vldm10 wrote:

> We do not understand one another regarding some important issues.

Unfortunately you don't understand my references to many that are basic, simple and common in logic and mathematics.

> I also think that you pay attention only to the model. However db also works with real word objects.

Predicate logic wffs and relational expressions correspond. Each connects the database to the world by its predicate extensions holding the tuples of values giving true propositions. Thus every predicate and relation expression connects the database and the world. Other connection is unnecessary. (Though perhaps useful.) I have explained that a foreign key asserts that certain tuple subsetting occurs and that correspondingly a certain implication holds in the world. (About entities, if you wish). Sorry I haven't been able to make this or much else clear for you. Sorry but your papers are mostly incomprehensible and they misunderstand the RM.

philip

[vldm10]

[vldm10]

Dana utorak, 10. travnja 2012. 00:49:44 UTC+2, korisnik com...@hotmail.com napisao je:

> On Wednesday, 4 April 2012 16:06:47 UTC-7, vldm10 wrote:
>
> > We do not understand one another regarding some important issues.
>
> Unfortunately you don't understand my references to many that are basic, simple and common in logic and mathematics.
>
> > I also think that you pay attention only to the model. However db also works with real word objects.
>
> Predicate logic wffs and relational expressions correspond. Each connects the >database to the world by its predicate extensions holding the tuples of values >giving true propositions.

It seems to me that you claim that the Relational model solves some problems in mathematics and logic.

As I already wrote, “This whole story about "predicates-relations-statements”, has already been done by Gottlob Frege, 120 years ago.” See my message from March 6th 2012.
Frege, in fact, did a lot more. He is the father of "Predicate Calculus" and modern logic. His Predicate logic is not limited by wffs. It is on the level of natural language. The RM is not on the level of natural languages.

>Thus every predicate and relation expression connects the database and the >world. Other connection is unnecessary. (Though perhaps useful.)

Sorry, but I disagree with this claim. One important part of this “connects the database to the world” is semantics. E. Codd hasn’t done anything significant within the field of Semantics.
G. Frege was the founder of Semantics, and many other people have given significant contribution to it.

Another important part related to this “connection” is the logic. Let me mention A. Tarski and his definition of truth.
Tarski worked on this definition for 10 years. Bela von Juhos also gave an important contribution to this definition of truth (where is the truth – in an object or in a meta language?)

E. Codd used truth tables because they work with compound propositions. Note that truth tables are on the intuitive level. In contrast to RM, my data model uses atomic propositions. Therefore the extensions correspond to atomic predicates.
Note that G. Frege used trees for compound propositions, instead of the truth tables.

I also presented definition of the predicate, which is based on G. Frege work:

A predicate is any incomplete phrase with specified gaps such that when the gaps are filled with names of things the phrase becomes a proposition.

Regarding to this definition, it is clear that G. Frege introduces the relation with named attributes, long before E. Codd.

This link between the database and the world, is one of the fundamental questions, which is only partially resolved. Famous mathematician in the last 100 years, have dealt with this subject. Some other sciences as philosophy, cognitive science and linguistics are also dealt with this topic.

So, if your intention is to show that E. Codd's relational model is able to fit into an existing mathematical theory, then I agree with you. But if your intention is to prove that the results that I mentioned above are Codd's contribution, then I'm sorry, I disagree.
There is no doubt that E. Codd results from db theory have lasting value.

>Sorry but your papers are mostly incomprehensible and they misunderstand the >RM.

Here you are much generalized, so that no one sees what you mean. I publish my papers on the user group so that they are public and subject to criticism. Of course I do not think that I am infallible. But the criticism must be PRECISE and CONCRETE.

I'll try to explain my paper with a few extras.
Section 3 defines the truth conditions. It also provides a link between meaning and truth. The truth conditions are often referred too by Frege, Godel, Tarski and Montague. Yet they do not define these terms.
Here I have tried to define the truth conditions in a language that works with entities, relationships, attributes, states and events.
Section 5 is about identification. For example OO approach extensively used identification, which is not defined in OO theory. RM also makes extensive use of identifiers, but there is no theory for them.
Section 7 can be understood if you look at the theory of Abstract State Machine (ASM). As far as I know the two groups at Microsoft Research are working on this. Unlike them, my paper provides a concrete solution.

Vladimir Odrljin