Re: more closed-world chatter

From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 04 May 2007 14:25:19 GMT
Message-ID: <jnH_h.159449$aG1.54991@pd7urf3no>

Jon Heggland wrote:
> paul c wrote:
>

>>Bob Badour wrote:
>> ...
>>>>Ie., is it a logical mistake to allow the query in the first place?
>>>
>>>No, it is not a logical mistake. Equality evaluates to false for
>>>values of disjoint types. Because 3 is not in your type, the
>>>comparison evaluates to false.
>>
>>Thanks, I feel better now.  Still, I'd like to know I could paraphrase
>>that query a little more formally, say using D&D <AND>.  But the
>>stipulation "It is required that if <A,T1> is in Hr1 and <A,T2> is in
>>Hr2, then T1 = T2" stymies me, eg., if pricedomain={1,2} and
>>anotherdomain={3}, it seems that <AND> isn't defined.

>
>
> Yes, so your query would fail on a type mismatch in A. If it is
> desirable for such a query to succeed (with an empty result), /and/ to
> be equivalent to an <AND>, I believe the (declared) type of the Price
> attribute in the result would have to be a common supertype of the Price
> types in the operands. And that may be slightly counter-intuitive if you
> formulate the query as a RESTRICT.
>
> But why are you unhappy about treating such a query as an error? It can
> be caught at compile-time, and isn't all that different from the error
> I'd expect if I declare a variable of type Price and try to assign it
> the value "red".
> ...

My reason is that I would like, at least on paper, to separate the aspects of an engine that strictly reflect the formal definition of say, D&D Appendix A, from the aspects that reflect taste or preference.

I can see that one layer, if you will, of an implementation, whether compiler or interpreter, could show a notion of exceptions and many users would find the result not "all that different" from one that produced the equivalent of "false". Probably this just reflects a phobia of mine that I think of as "exception creep". Whereas a slightly different interpreter might let the query ride and pass it as is to an engine.

This is perhaps not very clear, but the best I can do at the moment.

>>(I realize I could get the "false" answer suggested if only one side of
>>the <AND> used the "Items" attribute

>
>
> The Price attribute, you mean? Then the <AND> would be a product, and
> the result empty ("false"?) only by virtue of the Items relation being
> empty. I don't see how this helps in any way.

Sorry, I should have said the Price attribute ...

(Aside - it appears to me that you and Bob B are more or less on the "same page" when it comes to the advantage of sub-typing in dealing with my question. I don't mean to sound as if I'm rejecting that, just questioning whether I am forced to either implement it or to embed elementary exceptions in an engine, ie., forced to implement at least one of them. Also, for some reason I can't explain very well, I seem to view types or domains in a very mechanical way meaning that if a user can define a type that user could also re-define a type which might invalidate all of an existing db's "propositions". Logical limits seem quite important to me and I find both your comments helpful.)

p Received on Fri May 04 2007 - 09:25:19 CDT