Re: Cannot make sense of this

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