From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Thu, 16 Jun 2005 12:15:33 +0100

Message-ID: <42B15F55.6030208@hp.com>

To: Dan Connolly <connolly@w3.org>

CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Date: Thu, 16 Jun 2005 12:15:33 +0100

Message-ID: <42B15F55.6030208@hp.com>

To: Dan Connolly <connolly@w3.org>

CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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

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