On 02/05/12 17:19, Aidan Hogan wrote:
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?
Hi Aiden,
As with any proposal the fine details will need to be sorted out as the
spec gets written and test cases generated.
In this case, I'd expect it work as a join.
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)
}
==>
(join
(extend ((?dayID 0))
(table unit))
(table (vars ?dayID ?dayName)
(row [?dayName "Sunday"@en] [?dayID 0])
(row [?dayName "Monday"@en] [?dayID 1])
(row [?dayName "Tuesday"@en] [?dayID 2])
(row [?dayName "Wednesday"@en] [?dayID 3])
(row [?dayName "Thursday"@en] [?dayID 4])
(row [?dayName "Friday"@en] [?dayID 5])
(row [?dayName "Saturday"@en] [?dayID 6])
))
because
{ BIND ...
has a implicit empty BGP that became the (table unit) above). VALUES is
like any element of a group graph pattern and is joined into the overall
group result just like, for example, a { SELECT ... } subquery.
And you should be able to write the reverse:
WHERE {
VALUES (?dayID ?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)
}
joins are commutative
Andy
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
