- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 02 May 2012 11:17:39 +0100
- To: bn@kasabi.com, aidan.hogan@deri.org, sallen@apache.org
- CC: public-sparql-dev@w3.org
Hi guys, cc: public-sparql-dev I thought you might like to know what's going on: The WG hasn't completed it's discussion yet but the working proposal is: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0076.html and thread except that the word DATA will be VALUES. Note the slight change in syntax to make the one variable/several variables cases a little clearer. For the filter use cases, the setting of variables needs to move into a {} block for scoping reasons. so: SELECT * { VALUES ?x { :x1 :x2 } ?x rdfs:label ?label . } SELECT * WHERE { VALUES (?dayIDCheck ?dayName) { (0 "Sunday"@en) (1 "Monday"@en) (2 "Tuesday"@en) (3 "Wednesday"@en) (4 "Thursday"@en) (5 "Friday"@en) (6 "Saturday"@en) BIND (0 AS ?dayID) FILTER (?dayIDCheck = ?dayID) } Outstanding issues include exactly what happens to BINDINGS at the end of a query - one proposal to the group is to keep the concept (for the federated query use case) but adopt the same word/syntax as VALUES. Andy On 02/05/12 10:49, Benjamin Nowack wrote: > Hi, > > Just wanted to let you know that we (Kasabi/Talis) have a similar use > case to [1] and would benefit from BINDINGS as a placeholder mechanism > for parametrised queries, à la: > > [[[ > SELECT ?person WHERE { > ?person ex:name ?name . > FILTER(REGEX(?name, ?value)) > } > BINDINGS ?value {('John')} > ]]] > > > (We don't need a formal response, just wanted to report the use case.) > > Cheers, > Benji > > [1] > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Mar/0018.html > >
Received on Wednesday, 2 May 2012 10:18:13 UTC