Re: NULLs

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 8 Jan 2008 02:10:12 -0800 (PST)
Message-ID: <d59c6aeb-4598-4110-8532-5ef3a4bcb9b3_at_k39g2000hsf.googlegroups.com>


On Jan 8, 1:56 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> news:17031909-5d14-42ac-a7fd-4a81b3cf709f_at_p69g2000hsa.googlegroups.com...
>
>
>
>
>
> > On Jan 8, 7:50 am, Hugo Kornelis
> > <h..._at_perFact.REMOVETHIS.info.INVALID> wrote:
>
> > > And finally, I think that the closed world assumption will be a hard
> > > sell for businesses. I found this definition "Closed world assumption:
> > > if you cannot prove P or ~P from a knowledge base KB, add ~P to the
> > > knowledge base KB." athttp://cs.wwc.edu/~aabyan/Logic/CWA.html. If I
> > > understand this correctly, this implies that, if a knowledge base holds
> > > information about a person with ID XP55303, but no information
> > > whatsoever about the birthdate of this person XP55303, this person does
> > > not have a birthdate at all and hence can not exist.
>
> > > Most businesses will (unless legally prohibited) gladly do business with
> > > persons who refuse to state their date of birth - as long as they can
> > > wave a valid credit card. Telling a customer she doesn't exist is bad
> > > for business. Ergo, most businesses choose the Open World assumption.
>
> > The above formal definition of the CWA above is compatible with
> > missing information when the intensional definition is stated
> > appropriately. Eg
>
> > P = it is known to HR department that Alice is 25 years old.
>
> > If P cannot be proven from the DB, then we deduce ~P.
>
> I'm with you right up to this point. The problem is that, in practical
> terms,
> people confuse ~P with the following:
>
> Q=it is known to the HR department that Alice is not 25 yars old.
>
> Note that Q is not the same as ~P.

Yes, but isn't it better to highlight the issue rather than ignore it?

If a DBA is trained to think the CWA must formally be enforced everywhere by suitable intensional definitions, then it is more likely that the DB schema will be properly documented, and an astute user will be able to interpret queries correctly. Contrast this with a casual, informal near enough is good enough approach where relation and attribute names are regarded as sufficient documentation of intension definitions.

To my way of thinking the *simplest* overall approach to deal with missing information is to be careful with the intensional definitions, and always assume 2VL and CWA. The simplest approach is generally best for a challenged user. Received on Tue Jan 08 2008 - 11:10:12 CET

Original text of this message