W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: stumbled upon ACTION-200 CONSTRUCT WHERE shortcut...

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 14 Dec 2010 16:48:40 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <14028D8E-2905-418B-8C86-AFC1E11C2B30@deri.org>
To: Steve Harris <steve.harris@garlik.com>
Steve, all,

we discussed this in the TelCo today and there was little/no support for that shortcut in a strawpoll, in fact, greg had some concerns 
that it would rather raise new questions (e.g. since WHERE is normally optional this would raise confusion, etc.). 

My current suggestion, if you don't insist on that shortcut, or nobody else jumps on it, I would thus be to close the ACTION without further action and leave this shortcut out. 

(this discharges ACTION-348, but I leave it open until I have confirmation from Steve...)

Axel

On 13 Dec 2010, at 21:38, Andy Seaborne wrote:

> 
> 
> On 13/12/10 20:12, Axel Polleres wrote:
> > Hi all,
> >
> > I found this old action lying around, haven't found any notes on it, so I thought I just draft something:
> >
> > If we want that still, my suggestion would be to
> >
> > 1) change
> >
> > [9]  ConstructQuery  ::=  'CONSTRUCT' ConstructTemplate DatasetClause* WhereClause SolutionModifier
> >
> > to
> >
> > [9]  ConstructQuery  ::=  ( 'CONSTRUCT' ConstructTemplate DatasetClause* WhereClause SolutionModifier ) |
> >                            ( 'CONSTRUCT' DatasetClause* 'WHERE' ConstructTemplate  SolutionModifier )
> >
> > would that work with the grammar?
> 
> (I haven't time to check it programmatically but looking at it visually...)
> 
> Sort of.
> 
> "yes" in the sense that if the WHERE is mandatory, CONSTRUCT WHERE is a
> unique rule head so LL(1) works unambiguously.
> 
> LALR(1) will, I think, have conflicts and needs checking because the
> ConstructTemplate looks like a graph pattern but is a different rule.
> 
> "no" for some practical considerations:
> 
> 1/ WHERE is optional in the WhereClause form so there is cause for
> confusion (minor - that's a value judgement we would have to make)
> 
> 2/ ConstructTemplate isn't a full graph pattern and parsers may be
> treating it differently internally because the evaluation later is
> different.
> 
> It's hard be certain of the effect of (2) on existing systems. It may
> turn out to be a significant change to existing implementations in an
> area they weren't expecting to work on and the value is small.
> 
> It would be change in ARQ but I don't care and am quite prepared to
> rework the CONSTRUCT form. (I came across a similar effect with DELETE
> WHERE but that was all new code anyway.)
> 
> > 2) add a subsection
> >
> >
> > <div3 id="CONSTRUCTWHERE">
> > <head>CONSTRUCT WHERE</head>
> > <p>In case the construct template is identical to the WHERE clause, i.e. the triples matched by the WHERE clause
> > form the result graph, the CONSTRUCT Query form can be used in an abbreviated version, omitting the template.</p>
> 
> It is not identical.  The treatment of blank nodes is different.  We
> need to be precise.
> 
> > <p>For example, for the same data graph as before, the following query copies all foaf:name triples to the result graph.</p>
> >
> > <pre class=query
> >    PREFIX foaf:<http://xmlns.com/foaf/0.1/>
> >    PREFIX site:<http://example.org/stats#>
> >
> >    CONSTRUCT WHERE { ?person foaf:name ?name }
> > </pre>
> > </div3>
> 
>         Andy
> 
Received on Tuesday, 14 December 2010 16:49:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT