Re: SPARQL / Language spec ready for review

Change log for this set of comments, starting threading from here:

Dave Beckett wrote:
> Reading
>   $Revision: 1.90 $ of $Date: 2004/10/06 15:45:49 $
> 
> I've chopped off a lot of things either that are merged,
> you said you will revisit, or I don't care about.  
> 
> I have 1 pending MUSTFIX.

Done - see v1.91+ and description of change in:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0067.html

> 
> 
> 
> DaveB said:
> 
>>suggest removing see also, old material.  It's not ToC.
> 
> 
> it's also likely to be removed at publication time.
> 
> 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

AFS: Done: v1.93.

> 
> ...
> 
> 
> 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/

AFS: done v1.93

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

v1.93:
"nor available to any query"

> 
> Spelling: "intepretted"

v1.93
> 
> 
> 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?

AFS: Suggest you write an email to the discussing the pros and cons of the change.

> 
> I see the grammar has changed again from BRQL and CommaOpt now
> infects DESCRIBE and FROM additionally.

AFS: Should do.  Uniformity.

> 
> 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.

Please send as a separate email to the list.

Legacy is from general community expectations.

> 
> 
> 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.
> 
> 
> 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

Done as noted in reply to previous comments.

> 
> 
> 
>>>>Definition: Target graph
>>>>
>>>>"The target graph of a query."
>>>>
>>>>Ok, this must be a sketch.  Especially with the current discussion of
>>>>graphs.  Maybe expand a little,  "... to which a query may be applied".
>>>>I recall that we discussed these words and ended up pruning them.
>>
>>
>>Nack. I'm leaving the formal definition issues to Andy
> 
> 
> Pending, just words
> 
> 
>>>>Commas, die
>>
>>Nack. still in grammar
> 
> 
> See above.
> 
> DaveB said:
> 
>>>>12.2 Extending Value Testing
>>>>placeholder text.
> 
> 
> EricP:
> 
>>Nack. placeholder response. you (DaveB) may want to revisit in case
>>you had comments here.
> 
> 
> Looks fine
> 
> 
> 
>>>>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.
> 
> 
> 
>>>> * 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*

AFS: An issue related being derived from two grammars that have been used in 
prototypesa nd which do run thorugh parser generators.

> 
> 
>>>> * 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.
> 
> 
> 
>>>> * 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.
> 
> Dave

Received on Thursday, 7 October 2004 15:00:08 UTC