# Re: Updated definitions (constraint)

From: Dan Connolly <connolly@w3.org>
Date: Fri, 10 Jun 2005 16:41:07 -0500

Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-Id: <1118439667.12287.533.camel@localhost>
```
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...]
> > 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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:47 UTC