ErwinSmout

Which is the reason why you shouldn't write outer joins.

My DBMS is sufficiently expressive, thank you.

Placing this in its context of things said previously, "The DBMS doesn't read your mind before interpreting relations.", "Which is why the real interpretation happens outside the DBMS.", "Unfortunately, computer programs mean what they actually do", it is entirely irrelevant.

The meaning of what a DDL script does is that it asserts/ensures the (non-)existence of database objects in the database. This has absolutely nothing to do with the intended interpretation that the designer attaches to those of the database objects that are base tables/relations/relvars and derived ones in his design.

I thought it was the database designer. But OK, maybe that's just semantics and I'm not very good at those.

The DBMS doesn't read your mind before interpreting relations.

Which is why the real interpretation happens outside the DBMS.

And which is also why the DBMS needs "help" from its users when deciding whether TUPLE{} represents "The shop is closed" and should go in THE_SHOP_IS_CLOSED rather than "The alarm is set" and should go in THE_ALARM_IS_SET.

It interprets relations according to its own data integrity enforcement rules.

If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state), completely devoid of any form of "interpretation" in the sense of "human interpretation", I agree. Hell, it's why those things were called "computers". They compute. Nothing more.

"If two relations have identical designs, the difference can only be encoded in the relation (and possibly attribute) names,"

True, though the (and possibly attribute names) part seems dubious to say the least. Different attribute names makes the designs non-identical, no ?

in violation of the IP [information principle].

This interpretation of the IP is outright absurd.

One, the "I" in "IP" was obviously intended to cover only ever the [end-]user's own business information. The "information" that is being "hidden" under this absurd interpretation is the mapping that applies from relation names to intended interpretation. That information is never part of the [end-]users "genuine business information". How could it ? The mapping in question arises only when the models are being developed. As long as no computers are involved, no information models and no mapping, but the "genuine business information" stays the same.

Two, the relation names are present as a value of an attribute in a tuple in a relation. In the catalog that documents the structure of the database that will contain the [end-]users "genuine business information".

As such, it is inaccessible to the DBMS, which cannot rely on the RPs [relation predicates] to accept/reject tuples as correct/incorrect.

Not sure what is intended here. Is it claimed that because "table names are inaccessible to the DBMS", it is impossible for the DBMS to enforce declared constraints ? Ouch. The SQL REFERENCES clause ought to suffice to counter that.

Users--with little, or no help from the DBMS--must ensure that the correct tuples are inserted in the proper relation.

So they must know the mapping from relation names to intended interpretation. That is not an insurmountable problem. Hundreds of thousands of developers have already been doing that [or something extremely similar] since before databases even existed.

Moreover, because information is not represented explicitly (as data values), relational operations lose it: if you UNION the two relations, you get users that either viewed or downloaded items, or both.

Then don't union the two together. (It is alas left unclear whether the usage of the term UNION here refers to invocations of that relational operator on the two relations in the original design (in which case the "loss of information" is (a) intentional and (b) not really loss of information because the original relations have not magically disappeared by computing the union), or in the sense of blindly mergeing the two tables together at the schema level without adding an indication of view vs. download. In which case it's just a stupid design mistake even my cat probably wouldn't commit.)

No, the real meaning of a relation is the intended interpretation it was given when it was designed (and which is also the criterion by which the database user decides whether a tuple should be present or not, thus by which the database user decides which updates to carry through).