Re: RM formalism supporting partial information

From: JOG <jog_at_cs.nott.ac.uk>
Date: Mon, 26 Nov 2007 06:36:31 -0800 (PST)
Message-ID: <6002a9cb-b0a6-4509-8475-de3b0ea1cd36_at_e4g2000hsg.googlegroups.com>


On Nov 26, 2:06 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> news:9f987d7d-009c-451c-969f-16bade1d5c53_at_s36g2000prg.googlegroups.com...
>
> > On 24 nov, 23:34, Marshall <marshall.spi..._at_gmail.com> wrote:
> > > On Nov 23, 10:56 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > > Exactly, so in that sense it is actually complete, and you can make
> > > > that claim precise. The set of tupels in the answer will be exactly
> > > > the set of tuples that are certain to be in the result of the same
> > > > query over the omniscient database. By the nature of the problem every
> > > > query should actually return 2 sets of tuples: the set of certain
> > > > answers, and the set of possible answers. Your operators should
> > > > therefore not operator on relations but on pairs of relations.
>
> > > It seems to me that anything that we can say about partial
> > > information can be said with total information. In other words,
> > > efforts at making the *system* understand partial information
> > > are merely pushing systemward calculations that could be done
> > > in a system without any understanding of partial information.
>
> > > If so, it seems to me the best we can hope for with such
> > > an effort is some additional convenience. At which point,
> > > any justification for a system with built-in support for
> > > partial information *must* be done in terms comparing
> > > the convenience of queries, processing, etc. with vs.
> > > without the new partial-info primitives. I don't recall having
> > > seen this done however.
>
> > > An analogous situation applies with approximate calculations.
>
> > > I would be interested to hear anyone agree or disagree.
>
> > I largely agree but would add that if done well the support for
> > incomplete information would help and/or force you to be more explicit
> > about what your data means (e.g. in making explicit which CWA where
> > applies) and what the answers to you queries mean (e.g. only the
> > certain answers or also the possible answers, or something else).
>
> I think that in order to be done well the theory of incomplete information
> needs to be split out into two sub theories. I hesitate to name them. One
> would be the theory of storage and retrieval of incomplete information in
> databases and the like. The other would be about the processing of data in
> the face of incomplete information, or approximate information.

I'm not sure I agree David. I can talk about missing data in FOL, just as I can known data, so why encode something like "bob's hair is brown" and "david has hair, but I don't know what colour" by separate mechanisms? I personally think the jump we need to make is realising that missing information (i.e. holes in the data) only makes any sense at the conceptual layer, and that to the logical layer it just generates a different type of proposition. Perhaps that's what your saying anyhow?

>
> This split occured in the area of data in general about 1970, with Codd's
> paper. Database theory is not a general theory of computing, dressed up in
> database clothing. There's no reason why the theory of incomplete
> information should be different.
>
> > -- Jan Hidders
Received on Mon Nov 26 2007 - 15:36:31 CET

Original text of this message