Re: WWW/Internet 2009: 2nd CFP until 21 September
Date: Sun, 16 Aug 2009 17:44:29 -0300
paul c wrote:
> Walter Mitty wrote: >
>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>>> 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 - 15:44:29 CDT