- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Thu, 3 Feb 2005 17:37:07 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
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