From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Fri, 19 Oct 2007 14:36:19 +0100

Message-ID: <4718B2D3.3010602@hp.com>

To: Francis McCabe <frankmccabe@mac.com>

CC: public-rdf-dawg-comments@w3.org

Date: Fri, 19 Oct 2007 14:36:19 +0100

Message-ID: <4718B2D3.3010602@hp.com>

To: Francis McCabe <frankmccabe@mac.com>

CC: public-rdf-dawg-comments@w3.org

Frank, Thank you for your comments. They resonate with other comments we have received and the working group has decided on some editorial changes in this area. The full set of editorial changes is available in the editors' working draft: http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#convertGraphPattern > This is a quote from the june 14th edition of the SPARQL document > > Let SP := list of algebra expressions for sub-patterns of the group > Let F := all filters in the group (not in sub-patterns) > Let G := the empty pattern, Z, a basic graph pattern which is the > empty set. > > for each algebra sub-expression SA: > If SA is an OPTIONAL, > If SA is of the form OPTIONAL(Filter(F, A)) > G := LeftJoin(G, A, F) > else > G := LeftJoin(G, A, true) > Otherwise for expression SA, G := Join(G, SA) > > 1. The variable SP is not mentioned again in the algorithm, and > presumably is not needed? > 2. if SA is an algebra expression (as opposed to a pattern > expression), then presumably it cannot be of the form OPTIONAL > anything ... as one of the purposes of the algrebafication (sic) is > to eliminate optional clauses > 3. On the other hand, immediately prior to this is the suggestion > that this is a recursive algorithm: > > A group pattern is mapped into the SPARQL algebra as follows: first, > convert all elements making up the group into algebra expressions > using this transformation process recursively, then apply the > following transformation: > > which implies that algebrafication (sic again) has already taken place. Your points 1-3 have been addressed by being clearer on the recursive process. It starts at what was step 0, marking this as the start of "Transform(syntax form)" The step 4 you quote from becomes: ----------- Let FS := the empty set Let G := the empty pattern, Z, a basic graph pattern which is the empty set. For each element E in the GroupGraphPattern If E is of the form FILTER(expr) FS := FS set-union {expr} If E is of the form OPTIONAL{P} Then Let A := Transform(P) If A is of the form Filter(F, A2) G := LeftJoin(G, A2, F) else G := LeftJoin(G, A, true) If E is any other form: Let A := Transform(E) G := Join(G, A) If FS is not empty: Let X := Conjunction of expressions in FS G := Filter(X, G) The result is G. ----------- which explicitly mentions "transform()", and not implicitly refer to such a thing in text, so it is clearer how the recursion happens and removes the confusion about the fact that when the subterms are converted and the current group is not, there are parts that that are is a tree of algebra forms and parts that syntax elements. The pseudo-code above more clearly shows the partial algebra and partial abstract syntax elements through the mentioning of "Transform(P)" etc. > 4. What exactly, is implied by: > > Let F := all filters in the group (not in sub-patterns) > > Does this mean that all FILTER(constraint) expression should be > wrapped into a big conjunction prior to determining what to do with > them? The way the SPARQL operator "&&" is defined in the 3-state logic (true, false, error) so that two filters in a group, FILTER(E1) FILTER(E2), yield the same solutions is the same as E1 && E2. The redrafted text above now says "conjunction" and turns a set of filters into a single expression. > All in all, this section could do with some rigor. This should not be > impossible. > > Frank McCabe I hope these changes address your comments. If they do, please could you can help our comment tracking by replying to this message stating that you are satisfied with this response. Andy -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 EnglandReceived on Friday, 19 October 2007 13:36:47 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:52:09 UTC
*