Re: SPARQL 1.1. BINDINGS + FILTER

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
>>>
>>>
>>>
>>>
>

Received on Wednesday, 2 May 2012 21:08:51 UTC