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

Re: Cannot make sense of this

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


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:

 > 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}
          Let A := Transform(P)
          If A is of the form Filter(F, A2)
              G := LeftJoin(G, A2, F)
              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.


Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received 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