Re: SPARQL / Language spec ready for review

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.



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

...


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/


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

Spelling: "intepretted"


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.


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


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

> 
> >>  * 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 10:55:15 UTC