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

RE: Further comment on SPARQL 1.1 Test Cases

From: Polleres, Axel <axel.polleres@siemens.com>
Date: Fri, 14 Sep 2012 08:01:37 +0200
To: "rvesse@dotnetrdf.org" <rvesse@dotnetrdf.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-ID: <9DA51FFE5E84464082D7A089342DEEE801463BD0468B@ATVIES9917WMSX.ww300.siemens.net>
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 Friday, 14 September 2012 06:02:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 06:02:12 GMT