Re: sample query involving disjunction

Jos De_Roo wrote:

> SteveH 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. (In the common case of
>>>no inferencing this is a pretty realistic  query.)
>>>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
>>
>>[OT note] I found using $'s for this query quite distracting.
> 
> 
> :)
> 
> Using a capability for multiple queries in the same request
> that would simply be
> 
> SELECT ?X
> WHERE  {?X a :Person . ?X a :DogOwner}
> 
> SELECT ?X
> WHERE  {?X a :Person . ?X :hasPet ?Y . ?Y a :Dog}
> 
> 
> returning
> (:Eddie) a q:Answer. 
> (:Mitch) a q:Answer. 
> 
> 

Jos - right! - this is the way I have implemented it, like "UNION ALL" in
SQL (no duplicate suppression).

For a query of the form of "A & ( B | C )" (shared pattern A) some
combined query can do better than the expansion "(A&B) | (A&C)" but this
is in the realm of compiler techniques and it would be quite
easy to spot common patterns across the two queries because they have to
use the same variable names.

In the local case, one query or two is, maybe, not significant.  Across
the web it is significant: either the client needs to send two parallel
requests (client libraries raely do provide async I/O by default) or incur
additional latency by serialised issuing of the requests.  And the query
engine isn't given information it might use to optimize with.

	Andy

Received on Sunday, 19 September 2004 13:07:38 UTC