Re: Date and McGoveran comments on view updating 'problem'

vadimtro_at_gmail.com wrote:
> On Dec 8, 2:59 pm, paul c <toledobythe..._at_oohay.ac> wrote:

>> Thanks.  Although the relational lattice has seemed a fuzzy to me (no
>> doubt that's my fault as usually takes me years before I feel confident
>> in a mathematical topic), I gather that this example is about "insert"
>> to JOIN.  

Oh no, I didn't mean RL is fuzzy, rather my understanding is fuzzy. I'd say the more formal the definitions, the better, except that the more numerous and detailed the concepts are, the harder they are for somebody like me who thinks math is important and fundamental but is relatively inexperienced in math logic. I gather that lattices are a way to encompass various algebras, not just D&D's, but in general I don't have the experience to make very many useful comments about RL.

Because, a
> mathematician would certainly label all these view update discussions
> and ad-hock rules as "fuzzy".

Not being a mathematician, I can't argue with that, but at least until I can make more sense of view updating I'd perhaps agree that Date's rules might be a solution that over-simplifies the problem. I didn't find what McGoveran said to be fuzzy, eg., literally incoherent. Even if I don't yet see all the implications of McGoveran's points, they didn't strike me as adhoc, even if this sounds like talking out of both sides of my mouth. (I say Date, not D&D, because I gather Darwen also has objections to Date's rules.)

Since you are freely operating within
> D&D system of <AND>, <OR>, <NOT> operations, it is not much of
> difference to adopt RL; in fact join and negation are the same! The
> difference between D&D system and RL is that the authors didn't really
> reinforce their algebra with axioms to allow any manipulations.
...

I thought they didn't need to do that (because Frege, Russel, Codd and many others had already done that work)! Maybe we are at cross-purposes and you are talking about manipulations that D&D don't admit.

> (Sometime ago I mentioned how these both systems fit together).
> ...

Regarding join and negation being the same in RL & D&D, I vaguely remember being intrigued by the lattice union when you (I think) brought it up here more than a year ago and then sometime later you (I think) changed the definition from one that resembled projection from multiple operands to one that retained the attributes in the operands.

 From my (incomplete) reading of D&D, I'd say D&D downplay their <OR>, mentioning it mainly only in the contexts of inserting to a base and defining so-called "union-compatible" views. In their definition, it is a mere one-word change in the D&D formal definition to make <OR> similar to or even the same as what I thought the RL union was, but it seemed to me that doing so would disturb the parallel between their operators and the 16 dyadic boolean operators, which would undermine the rest of their foundation, eg, using de Morgan's laws to deal with the closed-world-assumption. That to me is a big thing to give up.

I'm not sure what the current RL meaning for union is, but discarding the traditional <OR> interpretation/connection also drops something I think they don't mention much (I'm not sure if they mention it at all), the usefulness of material implication for constraints, such as "Part P3 must be Red". In D&D's algebra, this can be defined as a relation expression with a form something like (<NOT> condition) <OR> (value) where condition looks something like <P# 'P3'> and value something like <COLOUR 'Red'>. Logically, that can be <AND>'ed with any result of their algebra. I take it this is all courtesy of the heritage they built on. I'm not saying RL can't do similar (I don't know enough to know how) and I'm not saying that an implementation shouldn't have shortcuts or optimizations, I'm just saying that the D&D <OR> is needed for this ability (if Codd's closure is assumed). When it comes to mathematical philosophy, I'm in a bit over over my head but I believe that kind of ability amounts to the effect of treating data design as a way of proving a theorem.

(Another maybe unrelated comment I have about the D&D <OR> is that I sometimes wonder if it is overloaded in a way that is different from the usual programming meaning of 'overloaded'. The usual meaning is that the same operator is applied to different kinds of things. But D&D define "INSERT" through UNION and UNION through <OR> at the same time as   they allow a view to involve <OR>. They are careful to always require the <OR>'ed operands to have same headings, so perhaps they aren't overloading in the sense I mean. Still it is a subtlety that sometimes trips me up when trying to write predicates down - I can't escape feeling that <OR> here is applied to the same things (relations) in different ways, one way for insert to a base and another when looking at a union view - that's what I mean by overloading. Maybe the answer is to simply think of the D&D algebra being used in different ways at different times, eg., 'user' language versus definition language, but it still makes me wonder if McGoveran was right when he said that users might have to distinguish between views and bases.) Received on Tue Dec 09 2008 - 17:46:57 CET