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:04:07 UTC