From: Dan Connolly <connolly@w3.org>

Date: Fri, 10 Jun 2005 16:41:07 -0500

To: andy.seaborne@hp.com

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

Message-Id: <1118439667.12287.533.camel@localhost>

Date: Fri, 10 Jun 2005 16:41:07 -0500

To: andy.seaborne@hp.com

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...] > > 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 C29EReceived 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
*