Re: sample query involving disjunction

On Sun, Sep 19, 2004 at 02:04:01 +0100, Andy Seaborne wrote:
> 
> 
> Steve Harris wrote:
> 
> >On Fri, Sep 17, 2004 at 02:42:37AM -0700, Rob Shearer wrote:
> >
> >>A user wishes to find all the people who are either of type dog owner or 
> >>own a
> >> pet who is  a dog.  The common case of no inferencing this is a pretty
> >> realistic  query.)
> 
> It does seem to be a reasonable query.  The contrast we have is between 
> the implementation view and the application writer view.  I'd like to see 
> queries express what the app writer wants.

Yes, I agree in general, but I do have other concerns over disjunction
queries. There are other kinds of queries we have disallowed, or agreed to
make difficult to express in version 1, so I dont have a big problem with
adding another to the list if theres a good reason.

OTOH I'm not religious about OR, I am open to being convinced that the
implementation burdon is worthwhile.
 
> >> Some sample data:
> >>
> >>Rob type Person
> >>Eddie type Person
> >>Eddie type DogOwner
> >>Mitch type Person
> >>Mitch hasPet Fido
> >>Fido type  Dog
> >>
> >>query
> >>
> >>select $x
> >>where ($x type  Person)
> >>     (($x type DogOwner) OR
> >>      (($x hasPet $y) ($y type Dog))
> >>
> >>Is this query correct?
> >
> >
> >Looks good to me, an OPTIONAL equivalent would be:
> >
> >SELECT $x
> >WHERE ($x type Person)
> >OPTIONAL ($x type $typeA)
> >OPTIONAL ($x hasPet $y) ($y type $typeB)
> >AND $typeA = DogOwner || $typeB == Dog
> 
> Steve,
> 
> Would I be right in assuming the AND filters everything from the 
> WHERE/OPTIONAL/OPTIONAL?
> 
> I'm curious as to what happens when expressions involve unbound variables?
> Suppose unbound causes a evaluation error and the query solutiuon is 
> rejected (this is the usual model for 3-state to 2-state logic - undef 
> becomes false, any expression involving undef is undefined itself).  [I 
> would strongly prefer the rule here that does depend on evaluation context 
> wherever possible.]
> 
> If the data is just:
> 
> Rob type Person
> Mitch type Person
> Mitch hasPet Fido
> Fido type Dog
> 
> then one query solution is:
> 
>   ?x=Mitch ; ?y=Fido ; ?typeB=Dog   // second optional clause
> 
> then the expression
> 
>    ?typeA = DogOwner || ?typeB == Dog
> 
> and has ?typeA undefined.
> 
> I think there would need to be a guard function "defined(?x)".  The 
> shortest expression I came up with is:
> 
> AND ( defined($typeA) && $typeA == DogOwner )
>     ||
>     ( defined($typeB) && $typeB == Dog )

In this case I take it that defined(x) is equivalent to SQL's "x IS NOT
NULL"? I was writing that example from a 2-valued logic p.o.v., but had a
question queued at the F2F to mention that we hadn't discussed which way
we were going yet.

In the 2-value case my expression is fine IIUC (modulo the AND being in
the worng place for syntaxes with multiple ANDs), ?typeA = NULL is false,
?typeB = Dog is true, the expression will evaluate as you expect.
 
> This is really testing for which branch the solution when down.
> It took a while to work out (maybe my brian isn't in gear) - I wrote out 
> all the cases and reduced the larger expression.
> 
> And that suggests:
> SELECT $x
> WHERE ($x type Person)
>       [ ($x type $typeA) AND $typeA = DogOwner ]
>       [ ($x hasPet $y) ($y type $typeB) AND $typeB == Dog ]
> AND defined($typeA) || defined($typeB)

> working by having a test to see that the query went down at least one 
> branch.  That is the sort of thing a query optimizer might do with the 
> original OR if the language had OR with the implementation changing to 
> OPTIONAL as a query plan possibility.
> 
> I find the OR query more natural because it was more directly what the 
> question was.

I agree FWIW. However, the action was to find a disjuntion query that
could not be expressed with []'s.
 
> >[OT note] I found using $'s for this query quite distracting.
> 
> Certainly a case for one or (as in XOR!) the other

Yes, I had though that I would be able to switch easily, but it doesnt
appear to be the case - I think the perl part of my brain took over
parsing it :)

- Steve

Received on Monday, 20 September 2004 07:55:02 UTC