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

That's fine by me.

- Steve

On 2010-12-14, at 16:48, Axel Polleres wrote:

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

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Wednesday, 15 December 2010 15:24:06 UTC