Re: Updated definitions (constraint)

Picking up a thread from weeks ago...

On Thu, 2005-05-19 at 11:43 +0100, Seaborne, Andy wrote:
[... see www-archive for the rest...]
> > Suggest rather adding
> > Constraint Pattern above and:
> > 
> > Definition: Value Constraint
> > 
> > A Value Constraint is a boolean-valued expression of variables
> > and RDF Terms.
> > 
> > Definition: Constraint Pattern
> > 
> > A Constraint Pattern is a pair of a Value Constraint
> > and a Graph Pattern. S is a solution for a Constraint
> > Pattern (C, GP) iff C(S) is true and S is a solution for GP.
> 
> Hmm ... thinks ...
> 
> How about defining a value constraint C as accepting S if C(S) is true?

I was thinking that constraints worked kinda like GRAPH
in the abstract syntax: there's a whole tree of pattern-foo
below them; all that gets evaluated, and for any solutions that
make it out of there, they get checked against the constraint.

But re-reading your message about the abstract syntax
in sparqlx.rnc ...
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0473.html

I see a possibility that constraints are always leaves
in the abstract syntax, i.e. they never dominate another
graph pattern. I guess I can see how that works.
Can you confirm that this is what you've got in mind?


> ----
> Definition: Value Constraint
> 
> A Value Constraint is a boolean-valued expression of variables
> and RDF Terms.
> 
> For constriant C, a solution S matches C is C(S) is true.
> ----
> 
> The problem is that we have used the term "matches" - a solution causes a 
> pattern to match and it's a bit odd using "match" but using the same work seems 
> better.
> 
> Tieing to a pattern does not work out completely:
> 
> Example 1:
> 
> SELECT WHERE
> {
>    ?x rdf:type :foo
>    :y :q ?v
>    { ?x :p ?v } UNION { FILTER ?v < 3 }
> }
> 
> either the triple { ?x :p ?v } is in the graph or the filter is true.
> 
> Example 2:
> 
> SELECT * WHERE {
>    { ?x :p ?v }
>    { FILTER ?v < 3 }
> }
> 
> where the FILTER is in a group of one, no pattern in the group.
> 
> Otherwise, it might be better to have a grammar to require FILTER to be 
> associated with a pattern of some kind.  Something like:
> 
>      pattern constraint*
> 
> [unchecked if that grammar change works]
> 
> but now we have order in the query and this is syntactically illegal:
> 
> SELECT * WHERE {
>      FILTER ?v < 3
>      ?x :p ?v
> }
> 
> and the UNION example also fails.
> 
> Our filters are not quite general patterns:
>    1/ Evaluation is according to XPath/XQuery F&O rules
>    2/ May be n-ary
> 
> you don't write binary operators as
>     (?x 3) math:lessMath ?result
> which is what it woudl be for the generalization to n-ary
> 
> Constraints may be implemented as graph patterns - but they may not.
[...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 10 June 2005 21:41:10 UTC