Re: WWW/Internet 2009: 2nd CFP until 21 September

From: Bob Badour <>
Date: Sun, 16 Aug 2009 17:44:29 -0300
Message-ID: <4a886fb1$0$23747$>

paul c wrote:

> Walter Mitty wrote:

>> "paul c" <> wrote in message
>> news:zmJhm.41463$PH1.15652_at_edtnps82...
>>> Mr. Scott wrote:
>>> ...
>>>> Pardon the pun, but your argument appears to be more applicable to
>>>> inapplicable nulls. ...
>>> Oh, here we go again, more twists and turns. I think Darwen said the
>>> record for the number of different kinds of nulls was somewhere in
>>> the twenties.
>> This is one of the more screwy discussions among theoreticians. You
>> have to draw a difference between indication and inference.
>> The only thing that a null INDICATES is that data is missing. The
>> reason why data is missing is either INFERENCE on the part of the
>> reader, or else it's an out of band message (a metamessage) between
>> the writer and the reader.

Except that the manipulation rules for any formalism have to reflect some inferences and not others.

>> There are only two cases that I think are worth distinguishing. The
>> first is, I guess, the inapplicasble null. This one arises from the
>> fact that the number of cells in a table is constrained to be the
>> product of the number of rows and the number of columns, but the
>> number of placeholders needed might be less than that. This case can
>> be obviated by normalization. I'm perhaps in the minority in c.d.t.
>> in saying that there are cases where a design that's less than fully
>> normalized can be a good one.

Being ignorant of the consequences doen't make Walter more open minded than those better informed than he is.

>> The other case worth mentioning is that things are not what they
>> should be. If there's any comprehensive theory on things that get
>> screwed up, I'm unaware of it. Maybe the famous Murphy, of Murphy's
>> law, created such a theory. Theory or no, people whio build systems
>> in the real world try to build systems retain some of their value when
>> things get screwed up.

> Somewhere Date gives a nice little example of the pitfalls when trying 
> to record negative facts.  Some predicates can be very tricky.  One 
> analogy I like has to do with troubleshooting motorcycle charging and 
> electrical systems.  Ususually the prescribed tests for parts like coils 
> and rectifiers involve an electrical continuity test.  These tests will 
> tell you if a part is definitely bad, but they won't tell you if it's 
> definitely good!  So you can't negate that kind of predicate.

One can negate it. "Not definitely bad" is the proper negation not "definitely good". Received on Sun Aug 16 2009 - 22:44:29 CEST

Original text of this message