- From: Polleres, Axel <axel.polleres@siemens.com>
- Date: Tue, 25 Sep 2012 15:36:40 +0200
- To: "andy.seaborne@epimorphics.com" <andy.seaborne@epimorphics.com>
- CC: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
> Just say "with a new blank node" - it's globally unique over
> all time - outside of request, operation or data anywhere, anywhen.
The rationale behind my wording is that
A) is a new bnode for each solution tuple, so it depends on μ
B) we want 2 bnodes in different request to be different, since the scope is just the request string.
So, it's "unique to the current update request and μ"
Axel
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
> Sent: Dienstag, 25. September 2012 15:02
> To: Polleres, Axel
> Cc: public-rdf-dawg@w3.org
> Subject: Re: FW: Further comment on SPARQL 1.1 Test Cases
>
>
>
> On 25/09/12 13:51, Polleres, Axel wrote:
> >> 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.
> > /
>
> Just say "with a new blank node" - it's globally unique over
> all time - outside of request, operation or data anywhere, anywhen.
>
> >
> >
> >> 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.
>
> It does not need a change- if the parser interprets _:label
> document-wide, per operation is safe because the generated
> template bNode has to be unique-in-time as well.
>
> Else, later, you can get a clash. Opps.
>
> Andy
>
> >
> > 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 13:40:19 UTC