W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2007

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

From: Ogbuji, Chimezie <OGBUJIC@ccf.org>
Date: Tue, 2 Oct 2007 08:16:04 -0400
Message-ID: <2702D0EBA4F0A749968E52E8644184EA2887FB@CCHSCLEXMB59.cc.ad.cchs.net>
To: andy.seaborne@hp.com, "Lee Feigenbaum" <lee@thefigtrees.net>
cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
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:

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
    { ?book dc:title ?title . 
        { ?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)

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

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



Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England


Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2007).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and

Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.
Received on Tuesday, 2 October 2007 12:19:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:52 UTC