Re: DAWG Agenda - Tues 2 Oct 2007 @ 14:30 UTC

Ogbuji, Chimezie wrote:
> I agree with Andy's suggested changes.  They clarify the recursion and fix the problem with introducing filters to the inner expression of an OPTIONAL.  However, I have some additional suggestions.  First, I think we should sketch a proof for the statement "This step does not alter the solutions a SPARQL algebra pattern will generate when evaluated; it merely reduces the expression complexity.".  I think some (minimal) justification for this would be appropriate, like so:

Thanks for looking over Andy's proposal.

> Groups of one graph pattern (not a filter) become join(Z, A) and can be replaced by A. The empty graph pattern Z is the identity for join.
> 
> ** Proposed additional text **
> Proof (sketch):
> 
> I.  Join({{}},A)
> II.  { merge(?0, ?a) | ?0 in ?0 and ?a in A, and ?0 and ?a are compatible }
> III. { merge(?0, ?a) | ?0 in ?0 and ?a in A }
>    .. this follows from a lack of common variables in ?0 and A ..
> IV.  { ?0 set-union ?a | ?0 in ?0 and ?a in ?a }
> IV.  A
>    .. this follows from set union / empty set tautology .. 
> 
> In addition, I added a new optional-filter test (http://www.w3.org/2001/sw/DataAccess/tests/data-r2/optional-filter/manifest#dawg-optional-filter-004) which exercises the expectation that a FILTER inside an OPTIONAL does not corrupt the entire solution even upon failure.  I needed this for the sake of seeing if we can't simplify the definition of Diff (which seems akward) but keep the same semantics.  More in a seperate email.  The test query is below:
> 
> PREFIX  dc: <http://purl.org/dc/elements/1.1/>
> PREFIX  x: <http://example.org/ns#>
> SELECT  ?title ?price
> WHERE
>     { ?book dc:title ?title . 
>       OPTIONAL
>         { ?book x:price ?price . 
>           FILTER (?price < 15 && ?title = "TITLE 2") .
>         } .
>     }
> 
> The input data is the same as the other tests.  From the current definitions of LeftJoin and Diff, all the book titles should be returned (without any ?price bindings)

Yes, this looks good to me. I was surprised to see that this wasn't 
already tested in optional-filter.

We'll look at it as a group in a bit during our teleconference.

Lee


> Chimezie (chee-meh) Ogbuji
> Lead Systems Analyst
> Thoracic and Cardiovascular Surgery
> Cleveland Clinic Foundation
> 9500 Euclid Avenue/ W26
> Cleveland, Ohio 44195
> Office: (216)444-8593
> ogbujic@ccf.org
> 
> 
> 
> 
> -----Original Message-----
> From: public-rdf-dawg-request@w3.org on behalf of Seaborne, Andy
> Sent: Mon 10/1/2007 10:58 AM
> To: Lee Feigenbaum
> Cc: 'RDF Data Access Working Group'
> Subject: Re: DAWG Agenda - Tues 2 Oct 2007 @ 14:30 UTC
>  
> 
> 
> 
> Lee Feigenbaum wrote:
>> We've got one important issue to do surrounding the bugs that Andy has 
>> identified in the SPARQL algebra.
>>
> ...
>> 2. Algebra bugs (and fixes) in rq25
>>
>> See AndyS's summary and detailed messages:
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JulSep/0179.html
>>
>> We need to decide how to fix these bugs as a group.
> 
> To give us a concrete proposal: I've put some proposed changes text into 
> section 12.2.1 of rq25. There are two blocks and are marker with a dotted box 
> to distinguish them.
> 
> http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#convertGraphPattern
> 
> 	Andy
>

Received on Tuesday, 2 October 2007 14:01:33 UTC