Re: Thinking about MINUS

Marshall wrote:

> On Jan 8, 3:32 am, paul c <toledobythe..._at_oohay.ac> wrote:
>

>>Marshall wrote:...
>>
>>>Ah, but when we are joining, which is to say unifying, two relations,
>>>and the two relations each make different, *incompatible* claims
>>>about the type associated with a particular attribute name, then
>>>I would say that well meets the criteria for being "contradictory."
>>>
>>>...Well, if I have 10 Navel Oranges and 10 Tangerine Oranges and I ask how
>>
>>many Florida Oranges I've got, I would hope the answer would be zero,
>>not "contradiction".

Actually, the example is just imprecise and perhaps suggests a failure to think about type sufficiently. If the only information given is "10 Navel Oranges" and "10 Tangerine Oranges", one can only compare the values lexically. In that case, the number of oranges lexically matching "Florida Oranges" is zero.

However, if the above is an imprecise/informal description of a predicate like "I have a Quantity of Fruit of each Cultivar" then one cannot even express the question "Where did the fruit come from?" or "How many of the orange fruit came from Florida?" given only the predicate above.

This raises the question: What is the data type of the value "Navel Oranges" used above? Or perhaps the value wasn't even used directly and the better question is: What is the data type of the value "10 Navel Oranges" used above?

> Back to the original idea, which was what happens when you
> join two relations with an attribute name in common but different
> types for that attribute. Bob suggested using a union type, which
> is sound, however I prefer calling it a type error.

It is not an either/or thing. The resulting value is as I described, and if that value violates a constraint like "There are no union types", then it raises an error. However, how does one express the constraint if one does not recognize the value in the first place?

> (Also note that if we use the union type solution, the result will
> always be empty, which is a signal that the operation doesn't
> really do anything interesting.)

Do I understand correctly that your position is: "Contradictions lack interest" ?

> If we use a name in two different scopes, and use it differently
> in those two scopes, and we intend to merge the two scopes
> together, we need to resolve that.

Please note that the above provides additional context to explain the constraint. Whether it is an error depends on context.

  One of the things join
> does is merge two namespaces, namely the attribute namespace
> of each relation.

I disagree. The join operation necessarily operates within a single namespace. Different invocations of the join operation may operate within separate namespaces, however.

Can you imagine a single proof or lemma in mathematics where the symbol x exists within multiple namespaces? In fact, one could look at a lemma as primarily introducing a separate namespace. As soon as one writes "Let x represent...", one defines the namespace of x.

> Well, I'm not explaining it very well. Hope to get more sleep tonight
> than last night.

I hope I get more sleep tonight than last night too--hopefully at least as much sleep as I got this afternoon! :P Received on Tue Jan 09 2007 - 05:22:30 CET