- 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