W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

Editorial changes in Update (was: SPARQL Update Editorial issue/ SPARQL Grammar [...])

From: Polleres, Axel <axel.polleres@siemens.com>
Date: Mon, 9 Jul 2012 09:54:45 +0200
To: "steve.harris@garlik.com" <steve.harris@garlik.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <9DA51FFE5E84464082D7A089342DEEE8013E03C66F64@ATVIES9917WMSX.ww300.siemens.net>
Hi all,

Following our discussions, I have made the following editorial fixes Update, pls check:


1) I have updated Table 1 to mention the GRAPH keyword, where it was missing:

1513c1513
< <td> <code>LOAD (SILENT)?</code> <em>IRIref</em><sub>from</sub> <code>INTO</code> <em>IRIref</em><sub>to</sub></td>
---
> <td> <code>LOAD (SILENT)?</code> <em>IRIref</em><sub>from</sub>
> <code>INTO GRAPH</code> <em>IRIref</em><sub>to</sub></td>
1519c1519
< <td> <code>CLEAR (SILENT)?</code> <em>IRIref</em></td>
---
> <td> <code>CLEAR (SILENT)? GRAPH</code> <em>IRIref</em></td>
1543c1543
< <td> <code>CREATE (SILENT)?</code> <em>IRIref</em> </td>
---
> <td> <code>CREATE (SILENT)? GRAPH</code> <em>IRIref</em> </td>
1549c1549
< <td> <code>DROP (SILENT)?</code> <em>IRIref</em></td>
---
> <td> <code>DROP (SILENT)? GRAPH</code> <em>IRIref</em></td>


2)

Moreover, I have changed wording in the paragraph that explains the order of execution of statements within a request (since someone pointed me at the fact that the word "lexocal order" would be misleading in this context):

289c289
< <p>A request is a sequence of operations and is terminated by EOF (End of File).  Multiple operations are separated by a ';' (semicolon) character. A semicolon after the last operation in a request is optional. Implementations &MUST; ensure that operations of a single request are executed in a fashion that guarantees the same effects as executing them in lexical order.</p>
---
> <p>A request is a sequence of operations and is terminated by EOF (End
> of File).  Multiple operations are separated by a ';' (semicolon)
> character. A semicolon after the last operation in a request is
> optional. Implementations &MUST; ensure that the operations of a
> single request are executed in a fashion that guarantees the same
> effects as executing them sequentially in the order they appear in the
> request.</p>


best regards,
Axel

> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com]
> Sent: Monday, 9 July 2012 8:51 AM
> To: SPARQL Working Group
> Subject: Re: SPARQL Update Editorial issue/ SPARQL Grammar
> suggestion in the context of Update (LOAD INTO iri vs. LOAD
> INTO GRAPH iri)
>
> +1
>
> On 5 Jul 2012, at 15:15, Lee Feigenbaum wrote:
>
> > I generally think that having "WHERE" optional in the query
> language is a little silly, so would not be in favor of
> adding new optional keywords in the same way...
> >
> > Lee
> >
> > On 7/5/2012 9:18 AM, Polleres, Axel wrote:
> >> Thanks Andy,
> >>
> >> Fair points... Any other opinions? I wouldn't want to risk
> another LC for update and, in case we see implementations to
> allow skipping "GRAPH" later on, a future WG could still
> standardize that without Backwards compatibility problems, right?
> >>
> >> So, I'll just do the editorial fix in
> >> http://www.w3.org/TR/sparql11-update/#mappingRequestsToOperations
> >>
> >> Best,
> >> Axel
> >>
> >>
> >>
> >> --
> >> Dr. Axel Polleres
> >> Siemens AG Österreich
> >> Corporate Technology Central Eastern Europe Research &
> Technologies
> >> CT T CEE
> >>
> >> Tel.: +43 (0) 51707-36983
> >> Mobile: +43 (0) 664 88550859
> >> Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com
> >>
> >>
> >>> -----Original Message-----
> >>> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
> >>> Sent: Thursday, 5 July 2012 3:07 PM
> >>> To: public-rdf-dawg@w3.org
> >>> Subject: Re: SPARQL Update Editorial issue/ SPARQL Grammar
> >>> suggestion in the context of Update (LOAD INTO iri vs. LOAD INTO
> >>> GRAPH iri)
> >>>
> >>> As a change it seems OK but it's rather late in the cycle.
> >>> Can we legitimately reply to comments making suggestions saying
> >>> "sorry - it's late" if we ourselves are fine tuning things.  It's
> >>> not broken.
> >>>
> >>> This would require a new LC for Update, in my opinion, because
> >>> implementations would be changed.
> >>>
> >>>>>   Update:
> >>>>>     mark the GRAPH keyword optional in Section 3.1.4 LOAD,
> >>>>> 3.1.5 CLEAR, 3.2.1 CREATE, 3.2.2 DROP
> >>> and it is a material change to the update doc itself (I
> don't think
> >>> the grammar being in query means that we can use that when
> >>> update-only language syntax is changed).
> >>>
> >>> And inline ...
> >>>
> >>> On 05/07/12 11:01, Polleres, Axel wrote:
> >>>> Sorry, missed something here:
> >>>>
> >>>>> The implied changes would be:
> >>>>>
> >>>>>   Query:
> >>>>>
> >>>>      only the suggested grammar change (since GraphRef is
> >>> only used by Update-relevant
> >>>>      grammar productions and thus doesn't otherwise affect
> >>> the query document, as far as I can see)
> >>>>      [...]
> >>>>
> >>>>
> >>>> Cheers,
> >>>> Axel
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Polleres, Axel
> >>>>> Sent: Thursday, 5 July 2012 11:52 AM
> >>>>> To: public-rdf-dawg@w3.org
> >>>>> Subject: SPARQL Update Editorial issue/ SPARQL Grammar
> >>> suggestion in
> >>>>> the context of Update (LOAD INTO iri vs. LOAD INTO GRAPH iri)
> >>>>>
> >>>>> A student of mine just pointed me to a small thing which I
> >>> wanted to
> >>>>> ask your opinions on:
> >>>>> For  DROP, CLEAR, CREATE, and LOAD  the GRAPH keyword is
> >>> obligatory,
> >>>>> i.e. you have to write:
> >>>>>    DROP GRAPH iri
> >>>>>    LOAD INTO GRAPH iri
> >>>>> ...
> >>>>> but can't simply write
> >>>>>    DROP iri
> >>>>>    LOAD INTO iri
> >>>>>
> >>>>> The student realized this, since we have some example in
> >>>>> http://www.w3.org/TR/sparql11-update/#mappingRequestsToOperati
> >>>>> ons in Table 1 where we forgot the GRAPH keyword...
> >>> Editorial - fix it regardless, - in any case, theyshould use the
> >>> full forms for clarity.
> >>>
> >>>>> Couldn't we make 'GRAPH' optional here, just as 'WHERE' is
> >>> optional
> >>>>> in WhereClause, i.e. change the GraphRef production
> >>>>>
> >>>>> s/
> >>>>>   [46]  GraphRef  ::=  'GRAPH' iri /
> >>>>>   [46]  GraphRef  ::=  'GRAPH'? iri /
> >>>>>
> >>>>> This would seem to be a minor, but handy change and still
> >>> possible as
> >>>>> long as we are still before LC publication for the grammar
> >>> along with
> >>>>> the Query document: I think making the GRAPH keyword
> OPTIONAL here
> >>>>> would still be a minor enough change for Update to call it
> >>>>> "editorial", since it doesn't invalidate anything from the LC
> >>>>> version.
> >>>>>
> >>>>> The implied changes would be:
> >>>>>
> >>>>>   Query:
> >>>>>
> >>>>>   Update:
> >>>>>     mark the GRAPH keyword optional in Section 3.1.4 LOAD,
> >>>>> 3.1.5 CLEAR, 3.2.1 CREATE, 3.2.2 DROP
> >>>>>
> >>>>>
> >>>>> Please note that the GRAPH keyword is already optional in
> >>> ADD, MOVE,
> >>>>> COPY, cf.
> >>>>>
> >>>>>     [45]  GraphOrDefault  ::=  'DEFAULT' | 'GRAPH'? Iri
> >>>>>
> >>>>> So, I think this minor change would make the Update
> language more
> >>>>> coherent, or would there be any problems with it?
> >>>>>
> >>>>> Best regards,
> >>>>> Axel
> >>>>>
> >>>>> --
> >>>>> Dr. Axel Polleres
> >>>>> Siemens AG Österreich
> >>>>> Corporate Technology Central Eastern Europe Research &
> >>> Technologies
> >>>>> CT T CEE
> >>>>>
> >>>>> Tel.: +43 (0) 51707-36983
> >>>>> Mobile: +43 (0) 664 88550859
> >>>>> Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
>
> --
> Steve Harris, CTO
> Garlik, a part of Experian
> 1-3 Halford Road, Richmond, TW10 6AW, UK
> +44 20 8439 8203  http://www.garlik.com/
> Registered in England and Wales 653331 VAT # 887 1335 93
> Registered office: Landmark House, Experian Way, NG2 Business
> Park, Nottingham, Nottinghamshire, England NG80 1ZZ
>
>
>
Received on Monday, 9 July 2012 07:55:16 GMT

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