Re: Proposed: SPARQL grammar is complete as-is

* Eric Prud'hommeaux <eric@w3.org> [2011-01-03 12:16-0500]
> * Andy Seaborne <andy.seaborne@epimorphics.com> [2011-01-03 16:25+0000]
> > 
> > 
> > On 03/01/11 16:04, Eric Prud'hommeaux wrote:
> > >Per a new years resolution to minimize LC comments, I implemented
> > >the latest grammar with some variations:
> > >   http://www.w3.org/mid/20110102043945.GA10306@w3.org
> > >
> > >Some of the changes were editorial (extra parens, factoring
> > >RelationalExpresion and Aggregate for readability) but there
> > >were several more substantial issues:
> > >   If "SELECT … { … } BINDINGS … { … }" works, shouldn't other
> > >   reporting forms also allow BINDINGS?
> > 
> > I noticed that change - OK for CONSTRUCT and DESCRIBE.
> 
> I'd think the same logic would apply to ASK (and to subselect, but
> I'll argue that below).
> 
> > I couldn't think of a use case for sub-SELECT and in fact thought it
> > was confusing.
> > 
> > The original idea of BINDINGS was to support streaming variable
> > bindings for the federated query.  Sub-SELECT does not fit this.
> > 
> > Do you have a use case in mind?
> 
> +
> I think the federated query motivation still applies to subselects;
> in "Provenance of Microarray Experiments for a Better Understanding
> of Experiment Results", we exploit SPARQL Federation, connecting a
> database of experimental data to a Diseasome endpoint. If my Diseasome
> query included a subselect (I only want to match diseases which don't
> have a zillion (say five) indicators), I'd like to write that
> subselect directly rather than writing some code to unify locally.
> 
> ½-
> Sticking the BINDINGs clause at the end of the query allows the engine
> to stream results of some queries as it parses each binding. We lose
> that in subselect (unless streaming the subselect results internally
> offers you some advantage).
> 
> +
> I like using BINDINGs in subselects for getting my head around (i.e.
> debugging) aggregate queries as it puts the pre-aggregated result set
> directly in my face. I use this for didactic and testing purposes:
>   http://swobjects.svn.sourceforge.net/viewvc/swobjects/branches/sparql11/tests/sparql11/groupBy-f-having-f.rq?revision=1264&view=markup

Andy reminded me to remind you guys that the above wasn't adopted and
that I still wanted some mechanism to inject bindings into subselects.
I believe the simplest and most effective is just to treat a subselect
just like a select, i.e. to allow the BINDINGS clause in the same place.


> > >   If QuadData doesn't preclude variables, do we need it and
> > >   QuadPattern (they are currently identical)?
> > 
> > See "@@Other notes" in rq25.xml:
> > 
> >     * QuadData and QuadPattern
> > 
> > The notes in the grammar will say that QuadData must exclude
> > variables but in the interests of not duplicating a substantial part
> > of the grammar just to change the term rule to exclude variables, we
> > just make QuadData.
> 
> ahh, roger that. Yes, I suppose having a handle like "QuadData" is
> clearer than enumerating the productions which require a QuadData.
> +1
> 
> > In implementation terms, it can be a flag to say whether variables
> > are allowed or not.
> > 
> > >
> > >   Why must e.g. "INSERT DATA" and "NOT EXISTS" have exactly one
> > >   space in them, instead of behaving like other tokens, separated
> > >   by   [ \t\r\n]* ( "#" [^\r\n]* [ \t\r\n]* )*   ?
> > 
> >     * INSERT DATA, DELETE DATA, DELETE WHERE, NOT IN as tokens
> > 
> > Again, the grammar notes will say that while these are written in as
> > single space, they should be WS*/comment separated.
> > 
> > (I hope this this makes the implementers life easier for the
> > operations INSERT-DELETE vs INSERT DATA case, and DELETE, DELETE
> > WHERE, DELETE DATA).  Done as it is in the gramamr, each operation
> > has a token that identifies the operation so it matches the update
> > language better.)
> 
> +1 on the language choice.
> 
> Re specification, I'd rather write that explicitly in the grammar as
> it allows people to cut and paste the results of our engineering labor.
> 
> 
> > >I sent this message to note these issues in the grammar completeness
> > >thread. Specific replies to the proposed modifications would probably
> > >best reference<http://www.w3.org/mid/20110102043945.GA10306@w3.org>  .
> > 
> > Here works better for me (mildly).
> > 
> >  Thanks for the comments,
> 
> quite welcome, thanks for the investment in the grammar and my comments.
> 
> 
> >  Andy
> > 
> > >
> > >
> > >* Andy Seaborne<andy.seaborne@epimorphics.com>  [2010-12-31 13:19+0000]
> > >>
> > >>
> > >>On 23/12/10 12:09, Steve Harris wrote:
> > >>>On 2010-12-23, at 11:58, Andy Seaborne wrote:
> > >>>>>
> > >>>>>I had an action to look at including CONSTRUCT WHERE { ... } for commonality with DELETE WHERE. I've not done anything about that, but it looks to me like it could be included as:
> > >>>>>
> > >>>>>'CONSTRUCT WHERE' GroupGraphPattern SolutionModifier
> > >>>>
> > >>>>See discussion:
> > >>>>http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0462.html
> > >>>
> > >>>I completely forgot that.
> > >>>
> > >>>In that case, modulo the stuff I've already mentioned, I think it's OK.
> > >>>
> > >>>- Steve
> > >>
> > >>In the spirit of facts, and not mere guesswork, I went back and
> > >>checked on the implications of a "CONSTRUCT WHERE" short form.  It's
> > >>doable: my fears were unfounded.
> > >>
> > >>Based on the discussion around DELETE WHERE, I have only considered
> > >>a BGP or construct template for the WHERE clause.  No FILTER, no
> > >>other graph patterns.
> > >>
> > >>It's not quite like DELETE WHERE because of FROM/FROM NAMED.
> > >>
> > >>It can be done by only changing the rule for CONSTRUCT:
> > >>
> > >>[9]    ConstructQuery    ::=
> > >>  'CONSTRUCT'
> > >>  (
> > >>    # The original rule
> > >>    ConstructTemplate DatasetClause* WhereClause SolutionModifier
> > >>    |
> > >>    # The short form.
> > >>    DatasetClause* 'WHERE' '{' TriplesTemplate? '}' SolutionModifier
> > >>  )
> > >>
> > >>It may be possible to tidy this up.
> > >>
> > >>In the short form WHERE is mandatory - this enables the parser to
> > >>know it's skipped the template in the full form.
> > >>
> > >>Therefore, I think we should put this in.  The extra editing is
> > >>quite small - adding a short para and example query to the CONSTRUCT
> > >>section.
> > >>
> > >> Andy
> > >>
> > >
> 
> -- 
> -ericP

-- 
-ericP

Received on Tuesday, 8 February 2011 15:04:58 UTC