Re: RM formalism supporting partial information
Date: Mon, 26 Nov 2007 15:01:57 GMT
Message-ID: <FdB2j.5860$Jy1.3847_at_trndny02>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message
news: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?
>
Consider "david has hair, and the hair must have some color, but I don't know what color".
But both of the examples you gave, and my example above, are "data" rather than "process". I don't know, in advance, that the theory of incomplete data is going to be substantively different from the theory of data in general. So I would tend to agree with your statement concering conceptual and logical layers, until shown otherwise. But I am prepared to be surprised.
The theory of approximate calculations is inherently about the processing of data, not about its preservation in a database, and its use by databae users.
On another subject, there are two places where incomplete data is part of the problem to be solved: incomplete fingerprints and incomplete auto license numbers. Both of these pop up naturally in the field of law enforcement. Received on Mon Nov 26 2007 - 16:01:57 CET