Further comment on SPARQL 1.1 Test Cases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Further comment on SPARQL 1.1 Test Cases

Rob Vesse
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
Reply | Threaded
Open this post in threaded view
|

RE: Further comment on SPARQL 1.1 Test Cases

Polleres, Axel
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. 
 
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:[hidden email]]
Sent: Freitag, 14. September 2012 01:39
To: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Further comment on SPARQL 1.1 Test Cases

Rob Vesse
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" <[hidden email]>
Date: Thursday, September 13, 2012 11:01 PM
To: Rob Vesse <[hidden email]>, "[hidden email]" <[hidden email]>
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. 
 
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 [[hidden email]]
Sent: Freitag, 14. September 2012 01:39
To: [hidden email]
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:

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
Reply | Threaded
Open this post in threaded view
|

Re: Further comment on SPARQL 1.1 Test Cases

Rob Vesse
In reply to this post by Rob Vesse
Yes of course you can forward to the list, I will CC this to the list myself

Rob

From: "Polleres, Axel" <[hidden email]>
Date: Wednesday, September 19, 2012 4:39 AM
To: Rob Vesse <[hidden email]>
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 [[hidden email]]
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). 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" <[hidden email]>
Date: Tuesday, September 18, 2012 7:48 AM
To: Rob Vesse <[hidden email]>
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 [[hidden email]]
Sent: Freitag, 14. September 2012 17:46
To: Polleres, Axel; [hidden email]
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" <[hidden email]>
Date: Thursday, September 13, 2012 11:01 PM
To: Rob Vesse <[hidden email]>, "[hidden email]" <[hidden email]>
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. 
 
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 [[hidden email]]
Sent: Freitag, 14. September 2012 01:39
To: [hidden email]
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:

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