- From: Polleres, Axel <axel.polleres@siemens.com>
- Date: Tue, 25 Sep 2012 14:51:59 +0200
- To: "andy.seaborne@epimorphics.com" <andy.seaborne@epimorphics.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
> We are talking about syntax not execution semantics as in
> 4.2.3 which is about template substitution.
Well, yes, but 4.2.3 defines how skolemization (i.e. "fresh" bnode creation) works.
If we want fresh bnodes to be scoped over a whole SPARQL update request, i.e. over all operations,
(I hadn't thought about this problem before) we need to probably add some
editorial clarification here.
If we want this behaviour, i.e. if people agree that they want
INSERT DATA {GRAPH <g1> {_:b1 :p :o } GRAPH <g2> {_:b1 :p :o } }
to behave like
INSERT DATA {GRAPH <g1> {_:b1 :p :o } } ;
INSERT DATA {GRAPH <g2> {_:b1 :p :o } }
We should make this clear by changing 4.2.3 as follows:
s/
Here, skì(TriplesTemplate) stands for replacing any blank nodes
occurring in the TriplesTemplate with a new blank node
unique for ì
and different from any blank nodes used in DS or in GS.
/
Here, skì(TriplesTemplate) stands for replacing any blank nodes
occurring in the TriplesTemplate with a new blank node
*unique to the current update request and ì,*
and different from any blank nodes used in DS or in GS.
/
> It is per parser run (the grammar defines requests, not operations).
I had designed the update semantics definitions so far rather
having "per operation" in mind than "per parser run" in mind,
but I think that the above "fix" can catch both...
...probably then also adding a resepctive variant of the proposed
insert-data-same-bnode test case would make things clearer.
Any other opinions/support/objections?
Best,
Axel
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
> Sent: Dienstag, 25. September 2012 12:40
> To: public-rdf-dawg@w3.org
> Subject: Re: FW: Further comment on SPARQL 1.1 Test Cases
>
>
>
> On 25/09/12 10:02, Polleres, Axel wrote:
> > Hi Andy,
> >
> > Working on my part... Some remarks:
> >
> > 1) Think I spotted a small typo (missing "refer") in
> >
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#grammarB
> NodeLabels
> > and have some more clarifying suggestions there
> >
> > s/
> > Blank node labels are scoped to the SPARQL Request String
> in which they occur.
> > Use of the same blank node label in a request to the same
> blank node.
> > Fresh blank nodes are generated for each request; blank
> nodes can not be referenced by label across requests.
> > /
> > Blank node labels are scoped to the SPARQL *query or update
> operation string* in which they occur.
> > *Different* use*s* of the same blank node label in a query
> or update operation *refer* to the same blank node.
> > Fresh blank nodes are generated for each request; blank
> nodes can not be referenced by label across requests.
> > /
> >
>
> "SPARQL Request String" is a formally defined piece of
> terminology to cover update and query.
>
> "refer" edit done.
>
> > The reason for not speaking about a *request* but rather an *update
> > operation* is that Given the semantics of updates
> > http://www.w3.org/TR/sparql11-update/#def_datasetQuadPattern
> > The skolemization, i.e. blank node creation is "per operation", not
> > "per request", thus, the same blank node used across
> different operations within a single request is not
> necessarily the same.
>
> We are talking about syntax not execution semantics as in
> 4.2.3 which is about template substitution.
>
> > That is:
> >
> > INSERT DATA {GRAPH <g1> {_:b1 :p :o } GRAPH <g2> {_:b1 :p :o } }
> >
> > (which inserts the same bnode in two graphs) is IMO *not*
> the same as
> >
> > INSERT DATA {GRAPH <g1> {_:b1 :p :o } } ;
> > INSERT DATA {GRAPH <g2> {_:b1 :p :o } }
> >
> > (which inserts two different bnodes into the two graphs)
>
> why?
>
> Document-scope is a clear and systematic policy.
>
> It is per parser run (the grammar defines requests, not operations).
>
> Andy
>
> >
> > Axel
> >
> >> -----Original Message-----
> >> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
> >> Sent: Freitag, 21. September 2012 12:00
> >> To: public-rdf-dawg@w3.org
> >> Subject: Re: FW: Further comment on SPARQL 1.1 Test Cases
> >>
> >> Parts relating to editing of rq25 done.
> >>
> >> Andy
> >>
> >> On 20/09/12 09:27, Andy Seaborne wrote:
> >>>
> >>>> Summarizing, unless anybody disagrees, I suggest the following:
> >>>>
> >>>> * adapt editorial suggestion 1) as above in Update
> >>
> >> (not done - in the update doc)
> >>
> >>>> * amend remark 10 in
> >>>>
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlGrammar
> >>>> as suggested above in 2)
> >>>
> >>> Yes
> >>
> >> Done
> >>
> >> (longer form used that mentions query and update)
> >>
> >>>
> >>>> * Reply to Rob that shared blank nodes across
> >> QuadPatterns within
> >>>> the same insert are allowed and
> >>>> behave as per test case basic-update/manifest#insert-05a
> >>>
> >>> Yes
> >>
> >> (This needs to be done.)
> >>
> >>>
> >>>> * Optionally, we could add a variant of
> >>>> basic-update/manifest#insert-05a to the test
> >>>> suite that explicitly covers Rob's example.
> >>>
> >>> OK.
> >>> But we than need to let everyone that has submitted test
> >> results about
> >>> the change.
> >>>
> >>>
> >>>
> >>> I think adding a brief note on id scoping is in order as
> >> well: Expand
> >>> 19.6 with
> >>>
> >>> """
> >>> Blank node labels are scoped to the request in which they occur.
> >>> Use of the the same label referrers to the same blank node. Blank
> >>> nodes and fresh blank nodes are generatedA blank label can
> >> be used for
> >>> each request; blank nodes can not be referenced by label across
> >>> documents (requests)
> >>>
> >>> Additionally, the same blank node can not be used in two
> different
> >>> basic graph patterns in a SPARQL Query or a SPARQL Update
> >> pattern (the
> >>> WHERE clause).
> >>>
> >>> The same blank node can occur in different QuadData and
> QuadPattern
> >>> clauses.
> >>> """
> >>
> >> Done - with link as suggested by Axel.
> >>
> >>>
> >>> Andy
> >>>
> >>>>
> >>>> Best,
> >>>> Axel
> >>>>
> >>>>
> >>>> 1.
> >>>>
> >>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0163.h
> >>>> tml
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
> >>>> Sent: Mittwoch, 19. September 2012 20:03
> >>>> To: Polleres, Axel
> >>>> Cc: public-rdf-dawg-comments@w3.org
> >>>> Subject: Re: Further comment on SPARQL 1.1 Test Cases
> >>>>
> >>>>
> >>>> Yes of course you can forward to the list, I will CC this
> >> to the list
> >>>> myself
> >>>>
> >>>> Rob
> >>>>
> >>>> From: "Polleres, Axel" <axel.polleres@siemens.com>
> >>>> Date: Wednesday, September 19, 2012 4:39 AM
> >>>> To: Rob Vesse <rvesse@dotnetrdf.org>
> >>>> Subject: RE: Further comment on SPARQL 1.1 Test Cases
> >>>>
> >>>>
> >>>>
> >>>> Hi Rob,
> >>>>
> >>>> I realiszed that I sent this to you only offlist.
> >> Hope it is
> >>>> ok for you if I fwd your suggestions with the WG list?
> >>>>
> >>>> thanks,
> >>>> Axel
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
> >>>> Sent: Dienstag, 18. September 2012 18:05
> >>>> To: Polleres, Axel
> >>>> Subject: Re: Further comment on SPARQL
> 1.1 Test
> >>>> Cases
> >>>>
> >>>>
> >>>> Hi Axel
> >>>>
> >>>> Perhaps if the group were to amending the
> >> following
> >>>> text from 3.1.1 INSERT DATA
> >>>>
> >>>> Variables in QuadDatas are disallowed in
> >> INSERT DATA
> >>>> requests (see Notes 8 in the grammar
> >>>> <http://www.w3.org/TR/sparql11-query/#sparqlGrammar> ).
> >> That is, the
> >>>> INSERT DATA statement only allows to insert ground
> triples. Blank
> >>>> nodes in QuadDatas are assumed to be disjoint from the
> >> blank nodes in
> >>>> the Graph Store, i.e., will be inserted with "fresh" blank nodes.
> >>>>
> >>>>
> >>>> And add additional text something like
> >> the following:
> >>>>
> >>>>
> >>>> Per Note 10 in the grammar blank node
> identifiers
> >>>> may be reused across graph blocks in QuadData but users
> >> should note
> >>>> that distinct fresh blank nodes will be generated for each
> >> usage in
> >>>> each block.
> >>>>
> >>>>
> >>>> That's a little clunky but I'm sure the
> >> WG can come
> >>>> up with something a little more flowing that gets the
> >> clarification
> >>>> across, it's primarily just a case of referring back to
> >> that note in
> >>>> the main query document.
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Rob
> >>>>
> >>>> From: "Polleres, Axel"
> >>>> <axel.polleres@siemens.com>
> >>>> Date: Tuesday, September 18, 2012 7:48 AM
> >>>> To: Rob Vesse <rvesse@dotnetrdf.org>
> >>>> Subject: RE: Further comment on SPARQL
> 1.1 Test
> >>>> Cases
> >>>>
> >>>>
> >>>>
> >>>> Hi Rob,
> >>>>
> >>>> Would you have a specific editorial
> >>>> suggestion for a respective explaining text which we could
> >> add to the
> >>>> Update document?
> >>>>
> >>>> Thanks,
> >>>> Axel
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Rob Vesse
> >>>> [mailto:rvesse@dotnetrdf.org]
> >>>> Sent: Freitag, 14.
> >> September 2012 17:46
> >>>> To: Polleres, Axel;
> >>>> public-rdf-dawg-comments@w3.org
> >>>> Subject: Re: Further
> comment on
> >>>> SPARQL 1.1 Test Cases
> >>>>
> >>>>
> >>>> Hi Axel
> >>>>
> >>>> Yes this answers my specific
> >>>> question but I still think it may be worth the group adding some
> >>>> clarifying text to the specification to make the
> distinction clear
> >>>>
> >>>> Rob
> >>>>
> >>>>
> >> From:
> >>>> "Polleres, Axel" <axel.polleres@siemens.com>
> >>>> Date: Thursday, September 13,
> >>>> 2012
> >>>> 11:01 PM
> >>>> To: Rob Vesse
> >>>> <rvesse@dotnetrdf.org>, "public-rdf-dawg-comments@w3.org"
> >> <public-rdf-dawg-comments@w3.org>
> >>>> Subject: RE: Further
> comment on
> >>>> SPARQL 1.1 Test Cases
> >>>>
> >>>>
> >>>>
> >>>> Hi Rob,
> >>>>
> >>>> (note that
> this is not a
> >>>> formal reply, but just quickly:)
> >>>>
> >>>> > 2 - The
> >> restriction does
> >>>> not apply to updates
> >>>>
> >>>> holds.
> >>>>
> >>>> SPARQL1.0 forbade (and
> >>>> SPARQL1.1 still forbids this blank nodes to be shared
> >> across BGPs, cf.
> >>>>
> >>>> http://www.w3.org/TR/sparql11-query/#grammarBNodeLabels
> >>>>
> >>>> The group didn't see a
> >>>> reason to put this restriction on QuadPatterns in the head of
> >>>> DELETE/INSERT statements in Update (which are different
> >> from BGPs in the WHERE clause).
> >>>>
> >>>> Hope this
> >> clarifies matters,
> >>>> pleases let us know if this answers your request or
> >> whether you still
> >>>> expect a formal group reply,
> >>>>
> >>>> Axel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Rob Vesse
> >>>> [mailto:rvesse@dotnetrdf.org]
> >>>> Sent: Freitag,
> >> 14. September
> >>>> 2012 01:39
> >>>> To:
> >>>> public-rdf-dawg-comments@w3.org
> >>>> Subject: Further
> >> comment on
> >>>> SPARQL 1.1 Test Cases
> >>>>
> >>>>
> >>>> I am working
> >> towards getting
> >>>> dotNetRDF back to as close to 100% compliance with the
> >> current state
> >>>> of the SPARQL 1.1 Query and Update specifications as
> possible and
> >>>> have run into one test case which is confusing to me
> >> because it seems
> >>>> as odd with SPARQL 1.0 behavior.
> >>>>
> >>>> This is
> >> syntax-update-53.ru:
> >>>>
> >>>>
> >>>> PREFIX :
> >>>> <http://www.example.org/>
> >>>> INSERT DATA {
> >>>>
> GRAPH<g1> {
> >>>> _:b1 :p :o }
> >>>>
> GRAPH<g2> {
> >>>> _:b1 :p :o }
> >>>> }
> >>>> Currently my
> >> implementation
> >>>> rejects this on the grounds that the same blank node is
> reused in
> >>>> different graph patterns. It was my understanding that the 1.0
> >>>> specification forbade this and there are in fact a
> >> selection of 1.0
> >>>> tests that specifically check that a parser rejects such queries.
> >>>> So I assume
> one of three
> >>>> things must be true:
> >>>> 1 - This
> restriction has
> >>>> been removed in SPARQL 1.1 (if so where does the spec
> state this?)
> >>>> 2 - The
> >> restriction does not
> >>>> apply to updates
> >>>> 3 - The test case
> >> is incorrect
> >>>> I would
> appreciate some
> >>>> feedback on this specific test case but also that the
> >> working group
> >>>> would please make sure the test suite is all up to date
> >> and accurate
> >>>> (sorry to complain yet about this yet again but it
> really makes it
> >>>> hard to check an implementation if you have to check for
> >> each failing
> >>>> test whether the test case is actually correct)
> >>>> Rob
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
Received on Tuesday, 25 September 2012 12:54:51 UTC