Re: Proposed: SPARQL grammar is complete as-is

* 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


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

Received on Monday, 3 January 2011 17:16:42 UTC