Re: Updated definitions (constraint)

Dan Connolly wrote:
> 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?

Constraints are "matched" (a bad word) like any pattern - with the solution 
needing to make the thing thing true.

For patterns that means "match", coming down to the basic graph pattern being a 
subgraph of the target graph.

For constraints, it comes down to evaluating the expression and seeing if it 
evaluates to (Effective Boolean Value) true.

EBV: http://www.w3.org/2001/sw/DataAccess/rq23/#ebv

Constraints can't have other pattern inside/below them.  They are expressions in 
the structure of F&O.  But constriants do occur in groups along side the other 
patterns.  In a group, all the group elements have to "pass" a solution for the 
groiup to match a solution.

 Andy

> 
> 
> 
>>----
>>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.
> 
> [...]
>

Received on Thursday, 16 June 2005 11:15:42 UTC