Re: question about combining patterns

On Feb 2, 2005, at 7:34 PM, Seaborne, Andy wrote:
>> is the following query
>>
>> PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
>> PREFIX  ns:  <http://example.org/ns#>
>> SELECT  ?title ?price
>> WHERE
>> {
>>     ( ?x dc:title ?title )
>>     ( ?x ns:price ?price )
>> }
>> AND ( ( ?price < 30 ) || ( ?price > 40 ) )
>>
>> going to fail accordingly to what stated in
>>
>> 	http://www.w3.org/2001/sw/DataAccess/rq23/#CombiningPatterns
>>
>> ?
>>
>> I think so - due the above query has two graph-patterns, and that the
>> constraints by definition do not bind any var - it should fail
>
>
> It should be OK - what about #CombiningPatterns is suggesting this to
> you?

to me it is suggesting that a "basic graph pattern" is a set of 
triple-patterns, which can be combined in 5 possible ways (here called 
blocks):

	-> group pattern (block of blocks)
	-> constraints
	-> optionals
	-> named-graphs
	-> alternatives

Constraints are considered a special kind of block, not part of a basic 
graph pattern - which do not bind variables and are only used to filter 
results. A block containing only constraints is a valid block. The 
first 4 patterns combinations are about a conjunctive combination of 
their blocks' elements (where a set of patterns must all match); while 
the last one (alternatives) is about simple disjunction (where two or 
more possible patterns are tried). Each block contributes to the final 
result/solution.

>
> {
>     ( ?x dc:title ?title )
>     ( ?x ns:price ?price )
> }
>
> is a group of patterns that just generates bindings for ?title and
> ?price these go into the cosntraint.
>
> Variables are NOT scoped by blocks - they are global to the query.  Is
> this the reading you are making?
>
> There is an outer group containing this inner group (redundantly) and
> the AND clause.  The AND applies to the outer group "all solutions are
> such that ?price < 30 || ? price > 40"

yes this part was clear and taken

> The example in that section shows that the query can include {} nesting
> and return the same solutions.  Suggestions for improvement?

any good reason why constraints could not be part of the "basic graph 
pattern" definition?

Constraints should then be evaluated either on any previous (outer 
block) result context and on bindings generated in the block itself 
(i.e. constraints are evaluated in their tree of blocks). This would 
make its processing more deterministic and logical.

>> In other words, in the implementation, while processing the blocks
>> stack one should execute any "binding graph-pattern" first or fail if
>> not possible.
>
> Not sure about "stack" given that variables are in a flat global space.

Even if the spec says that the scope of variables is global to the 
query, in the case of optionals and nested optionals, some sort of 
block-scoping of variables is required (see 5.6 section). This, in a 
way or the other (imagine a scenario of n>3 levels of nesting and 
several combinations of patterns), it would require to keep track of 
which variable is used in which block and its binding - and process it 
accordingly. And order matters - then an implementation needs to 
process blocks in a certain order to gain the correct answer.

Similarly, with constraints blocks, due they are meant to filter 
results and do not bind variables, they are required to be evaluated in 
certain "result context". Which would make the following query invalid

> The order issue is a separate matter - I have been working on a
> generalisation of the optional variables rule that also covers
> constraints to get consistent answers. I have an action item to report
> the ordering and optionals issue.

good to know

> The rule has to be that for constraints, if a variable is used
> elsewhere, that part is executed first.  This naturally follows from 
> the
> declarative interpretation.

this was very easy and systematic to do with RDQL, while now is much 
more tricky due we do have nesting and grouping. And if so, this rule 
should be clearly stated into the spec.

cheers

Alberto

-
Alberto Reggiori, @Semantics S.R.L.
www.asemantics.com

Received on Thursday, 3 February 2005 16:37:10 UTC