Hi,
Looks good! Thanks for the heads up.
Just one question. What would happen if the query were posed as follows:
SELECT *
WHERE {
BIND (0 AS ?dayID)
VALUES (?dayID ?dayName) {
(0 "Sunday"@en)
(1 "Monday"@en)
(2 "Tuesday"@en)
(3 "Wednesday"@en)
(4 "Thursday"@en)
(5 "Friday"@en)
(6 "Saturday"@en)
}
}
...in other words, a variable used for VALUES is bound outside of the
scope of the VALUES{} block.
Would this give rise to an "already bound exception", or would a join
take place?
Cheers,
Aidan
On 02/05/2012 11:17, Andy Seaborne wrote:
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
