Re: more on optionals

Geoff Chappell wrote:

>> -----Original Message----- From: Jeen Broekstra
[snip]
>> In the implementation of the language, we have made the decision 
>> to always evaluate optional patterns _after_ all the fixed 
>> patterns have been evaluated. This makes sure the engine behaves 
>> consistently over cases such as the example of Geoff (and other 
>> such cases), and is consistent with the intended meaning of 
>> optional patterns: given that we _know_ a certain x, we want to 
>> know additional properties of that x, but not fail if no such 
>> additional properties exist. To know x, we first have to bind a 
>> value to x, before we can evaluate its additional properties.
> 
> 
> That seems like a reasonable approach - not unlike stratification 
> in a deductive database to deal with negation or aggregation. Of 
> course stratification has its problems - e.g. with negated 
> recursion (which, BTW, drove us to move from a stratification 
> approach to WFS w/RDF Gateway). Does this approach have any such 
> problems - i.e. are there any queries that it can't handle and so 
> rejects as invalid?

Not in SeRQL, but SeRQL does not support recursion, so that may be why
we haven't bumped into such problems. The only 'rejected' queries wrt
use of optionals are cases where two optional path expressions share a
variable that is not bound by a fixed expression (or more precisely:
two optional expressions nested at level N share a variable that is
not bound by an expression at level N-1 or lower) (see [1]). Rejecting
these patterns avoids nondeterministic queries where the order of two
(or more) optionals is the cause of the ambiguity.

Jeen

[1] http://lists.w3.org/Archives/Public/www-rdf-interest/2003Nov/0076.html
-- 
Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31(0)33 46599877  fax. +31(0)33 46599877

Received on Friday, 25 February 2005 08:50:02 UTC