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

This action is now closed.

Axel

On 15 Dec 2010, at 15:23, Steve Harris wrote:

> 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:28:41 UTC