Re: more closed-world chatter

On 4 mai, 16:25, paul c <toledobythe..._at_oohay.ac> wrote:
> 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.)
paul
I am a worried that the question you have raised brings quickly to the computing model involved in the interval based representation of sets and away from the logical underlying issues.
> p
Received on Fri May 04 2007 - 21:52:07 CEST