Re: SPARQL / Language spec ready for review

Reading
http://www.w3.org/2001/sw/DataAccess/rq23/
$Revision: 1.92 $ of $Date: 2004/10/07 14:45:41 $

The main change I see is to fix 4.3 which does so to my satisfaction.
The remaining points from my email
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0065.html
marked 'pending' below can be addressed by the editors now or later,
at their choice.

I support publishing the WD at this point.  I'd encourage other
reviewers to give a go/no-go soon so we can get this out for public
review.

Dave

----------

> 2.2
> Definition: Query Variable
> "Let V be the set of all query variables.  V and T are disjoint."
> 
> T should be RDF-T after the rewriting

pending

> Definition: Triple Pattern
> "let T be a member of theset of triple patterns :=
>     (RDF-U union RDF-B union V) x (RDF-U union V) x (RDF-T union V)"
> 
> spelling - s/theset/the set/

pending

> 2.3
> grammar: "There are is a bNode " -> "There is a bNode"
> "nor to any query." -> "nore in any query."
> 
> Spelling: "intepretted"

pending


> 2.4 Multiple Matches
> 
> EricP said:
> > Nack. Do you mean the example query?
> > [[
> > PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
> > SELECT ?name, ?mbox
> > WHERE
> >     ( ?x foaf:name ?name )
> >     ( ?x foaf:box ?mbox )
> > ]]
> > Commas are still allowed in the select string.
> > [[
> > 'select' 'distinct'? <VAR> ( CommaOpt <VAR> )*
> > ]]
> 
> 
> Yes and what is the WG process for getting rid of such things?
> 
> I see the grammar has changed again from BRQL and CommaOpt now
> infects DESCRIBE and FROM additionally.
> 
> I see it as like this.  Say I was explaining this to users: 
> 
>   In SPARQL you can use commas if you like between variables in a
>   SELECT, DISTINCT or FROM but not between parts of triples or for
>   lists of triples.  Except for arguments in extention functions
>   where commas are required and cannot be omitted.
> 
> This is inconsistent and silly to put in a language with no legacy
> users.  Don't pre-load the grammar with what might be syntactic sugar
> before this is even a WD.  I vote absent except for extension
> functions arguments.  See later.


pending

> 4.2
> still has "Multiple OPTIONAL blocks" despite OPTIONAL not
> defined or used as a keyword.
> 
> EricP said:
> > 1.83:
> > I updating the wording according to how I saw the rules:
> > [[
> > If a new variable is introduced in an optional block (and can therefor
> > be bound in that block) then it can not be mentioned in a subsequent block.
> > ]]
> > and added an explanatory note:
> > [[
> > The purpose of this rule is to enable the query processor to process
> > the query blocks in arbitrary (or optimized) order. If a variable was
> > introduced in one optional block mentioned in another, it would be
> > used to constrain the second. Reversing the order of the optional
> > blocks would reverse the blocks in which the variable was was
> > introduced and was used to constraint. Such a query could give
> > different results depending on the order in which those blocks were
> > evaluated.
> > ]]
> > Does that clarify?
> 
> I'd prefer to not have these as notes but inline text.  If the
> purpose of the main text body isn't clear (it wasn't), the extra text
> should be there.  Implementation notes might be appropriate at some
> point.

pending


> EricP:
> > 
> > >> 4.3 Optional Matching
> > >>
> > >> Definition: Initial Binding
> > >>
> > >>   "The result of a query stage,QS = (GP, VC), with an initial binding
> > >>   B, has Query Result where all the bindings in B are valid (the graph
> > >>   pattern and any value constraints in QS).
> > >>
> > >>   B extended with addition bindings given by matching subst(GP, B)
> > >>   and constraining with VC."
> > >>
> > >> VC is used here, never defined.  Presumably refers to Value Constraint
> > >> However Query Stage was earlier (partially) defined as QS: GP x VR
> > >>
> > >> grammar: "has [a] Query Result", "B [is] extended with addition[al] .."
> > >>
> > >> MUSTFIX: More substantially; after several re-readings, I don't
> > >> understand this definition.  Can I ask for some more explanation
> > >> please?
> > >>
> > >>
> > >> Definition: Graph Pattern - Optional Match
> > >>
> > >>   "An optional match of QS, with initial binding B, the match of QS
> > >>   with initial binding B if there exists at least one solution, and is
> > >>   B otherwise."
> > >>
> > >> grammar: "binding B, [is] the match..."
> > >>
> > >> That seems to define an optional match of a query stage, not of a
> > >> graph pattern.  Is the definition title correct?
> > 
> > 
> > Nack. I'm leaving the formal definition issues to Andy
> 
> OK, this is a pending MUSTFIX


The change in 1.93 works for me.

In some future version maybe you might add in the definition of
optional match, GP1 matches G.


> > >> A. SPARQL Grammar
> > >>
> > >> Some of my previous comments in [1] still apply such as:
> > >>  * Die CommaOpt
> > 
> > 
> > Nack. Ahh, not an assertion that it didn't match the language, but
> > instead that the language should be changed. revist after publication.
> 
> See above.

pending

> > >>  * Use FOO+ not FOO FOO? for one or more
> > 
> > 
> > Nack. those aren't equivilent. maybe you mean "FOO FOO*"? 
> 
> I did
> 
> > If so,  please point out instances.
> 
> Deleting CommaOpt gives a couple in ReportFormat.
> 
> also:
> 
> TriplePatternList ::= TriplePattern TriplePattern*

pending

> > 
> > >>  * OPTIONAL keyword
> > 
> > Nack. Again, now realizing that those were appeals to change the
> > language. Unless there were clear indications that we should do so by
> > the working group, I don't consider those bugs in the spec per se.
> 
> Here's a clear indication. The syntax with the most support at F2F3
> after several straw polls and discsussions:
>   http://www.w3.org/2001/sw/DataAccess/ftf3-brs#qlsyn
> had no OPTIONAL keyword or optional commas.

pending

> > >>  * A ::= B with only one use of A (all non-terminals) should be inlined
> > 
> > Nack. sorry, don't follow. Is this a rule of EBNF?
> 
> It's extra junk in the grammar to have non-terminals with only 1 use.
> Unless this is used to explain some point - not at present, since
> there are no grammar actions.
> 
> Here are some of the non-terminals with one use deserving removal:
>     	FromSelector 	   ::=    	URI
> 
>     	PatternElement1    ::=    	SingleTriplePatternOrGroup
> 					| PatternElementForsm
> 
>     	SingleTriplePatternOrGroup ::= 	TriplePattern | ExplicitGroup
> 
> I'm not proposing removing things like WhereClause since that clearly
> matches the structure of the query language and makes the Query
> non-terminal readable.

pending

Received on Thursday, 7 October 2004 14:55:29 UTC