From: Francis McCabe <frankmccabe@mac.com>

Date: Fri, 19 Oct 2007 08:44:43 -0700

Message-Id: <DF2744E8-9B9E-4D38-9570-60B5E7C73863@mac.com>

To: andy.seaborne@hp.com

Date: Fri, 19 Oct 2007 08:44:43 -0700

Message-Id: <DF2744E8-9B9E-4D38-9570-60B5E7C73863@mac.com>

To: andy.seaborne@hp.com

Andy: Yes thank you. It is both clearer and what I had thought must be the answer :) I have a couple of additional comments, but I will raise them in a separate issue. Frank On Oct 19, 2007, at 6:36 AM, Seaborne, Andy wrote: > 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 England > >Received on Friday, 19 October 2007 16:09:00 UTC

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