Re: Proposed definition of ExprMultiSet

On 08/03/2010 2:20 PM, Steve Harris wrote:
>>>
>>> I think the above all match what I would expect, but...
>>>
>>>> -- Different query OPTIONAL part - now has ?p
>>>>
>>>> 1 PREFIX : <http://example/>
>>>> 2
>>>> 3 SELECT ?x (sum(?v) AS ?C)
>>>> 4 WHERE
>>>> 5 { ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> :T
>>>> 6 OPTIONAL
>>>> 7 { ?x ?any ?v}
>>>> 8 }
>>>> 9 GROUP BY ?x
>>>> 10 ORDER BY str(?x)
>>>>
>>>> -----------
>>>> | x | C |
>>>> ===========
>>>> | :x1 | 3 |
>>>> | :x2 | 9 |
>>>> | :x3 | 5 |
>>>> | :x4 | 0 |
>>>> -----------
>>>>
>>>> The case where ?v is "Z2 and "x" have been skipped.
>>>
>>> For this one I would expect:
>>>
>>> -----------
>>> | x | C |
>>> ===========
>>> | :x1 | 3 |
>>> | :x2 | 9 |
>>> -----------
>>
>> You're right - there's errors in the eval of fn:numeric-add.
>>
>> We need to define what happens if agg(..) is an error.
>>
>> An alternative is,
>>
>> -----------
>> | x | C |
>> ===========
>> | :x1 | 3 |
>> | :x2 | 9 |
>> | :x3 |   |
>> | :x4 |   |
>> -----------
>>
>> which retains the group row (to distinguish from no key).
>
> Yes, I wrote that first, then changed it. I think that the version with
> the removed rows is closer to the rest of SPARQL, as error rows are
> removed in (sub-)queries. It's also possible to prevent this, in many
> cases at least, with creative use of COALESCE, but I know you're not a fan.

FILTERs remove errors but SELECT expressions just don't bind that slot 
if the expression fails.

SELECT (1/0 AS ?v) {}

is one row, no bindings as currently spec'ed.

Projection and extension go together - neither changes overall 
cardinality in the multiset (project may collapse two elements to one 
and teh cardinality is then the sum of the two).

I have tried to keep separate the operations of removal of rows, row 
creation and also from row extension.

 Andy

Received on Monday, 8 March 2010 16:02:33 UTC