Re: RM formalism supporting partial information

On Nov 16, 8:31 am, Jan Hidders <hidd..._at_gmail.com> wrote:
> On 15 nov, 20:11, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
> > I'm sure your time is precious and I don't want to be presumptuous,
> > but have you digested much of the document? Do you have any
> > particular comments on the operators, such as the information
> > comparison operator which gives a partial ordering and a concept of
> > information equivalence?
>
> It's actually not a partial order, but a preorder because it is not
> antisymmetric.

I didn't know partial order had that more specific meaning. Nor did I know that the term preorder was available for what I wanted to say. Thanks for pointing that out.

> It's also a bit strange in that it says that the
> following relation bodies (for simplicity the tuples are unlabeled)
> all have the same information:
> - { }
> - { ({}, {}) }
> - { ({a}, {}) }
> - { ({}, {b}) }

I don't think that's correct. According to the definitions only the first two have the same information. I'll name the attributes x1 and x2.

From your middle two examples we have

    r1 = { (x1={}, x2={}) }
    r2 = { (x1={a}, x2={}) }

Then taking various interpretations of projections...

    I(proj({},r1)) = {}
    I(proj({},r2)) = {}

    I(proj({x1},r1)) = {}
    I(proj({x1},r2)) = { (x1=a) }

    I(proj({x2},r1)) = {}
    I(proj({x2},r2)) = {}

    I(proj({x1,x2},r1)) = {}
    I(proj({x1,x2},r2)) = {}

For all subsets X of {x1,x2}, I(proj(X,r1)) is a subset of I(proj(X,r2)) so r2 --> r1.

However, it is not true that r1 --> r2.

> It's also not clear to me why you take in the definition all
> projections over all subsets of the header. Why project at all?

The information preorder operator is defined on *any* pair of mvrelations.   ie they do not need to have the same header.

Note however that it would be generally be meaningless to test whether one interpretation is a subset of another unless they have the same header. Doing projections before the interpretation ensures they can be compared using the subset preorder.

Note that the projection operator is unusual in that it will happily add attributes to a mv-relation as well as remove them! Note that if an attribute is added you can be assured that the interpretation of the projection is empty.

> But far more problematic is that you don't give any intuition for what
> this "information content" means. Just having an elegant definition
> and some cute mathematical properties is not enough. Is the
> information content what the "real meaning" of the nested relation is?

Yes it is.

Intuitively the information content can be regarded as the set of all conventional propositions that can be "read out" of the mv-relation, for all possible projections.

Eg

    r =
    {

        (names={fred, bill}, cars={c1}),
        (names={}, cars={c2})

    person(fred).
    person(bill).
    owns_car(fred,c1).
    owns_car(bill,c1).
    car(c1).
    car(c2).

> But if the real meaning is a flat relation, then why bother at all
> with nested relations?

The objective is to accommodate partial information and yet stay within the confines of 2vl by thinking of the information content as the interpretation over all possible projections.

Note BTW that none of the operators increase the cardinality of a set of values of a tuple for a given attribute. Therefore the entire theory holds for the special case where we constrain as follows:

    for every tuple t, and attribute a of t, |t(a)| <= 1

which is analogous to relations with nulls.

> > The union and intersection operators I defined appear to have nice
> > properties and a straightforward interpretation. This seems to
> > contrast with outer intersection and outer union. Does that suggest
> > there could be something useful in the approach?
>
> As is probably clear by now, I'm still not really convinced that this
> interpretation is really so straightforward.
Received on Fri Nov 16 2007 - 02:51:11 CET