W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2012

Re: 2 New INSERT DATA test cases (was: Test case proposal in the context of RV-10: insert-data-same-bnode)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Mon, 01 Oct 2012 12:38:26 +0100
Message-ID: <506980B2.9010801@epimorphics.com>
To: public-rdf-dawg@w3.org

On 01/10/12 12:17, Polleres, Axel wrote:
> Dear Olivier,
> Thanks for joining the discussion!
> The test cases were created under the understanding that bnodes are scoped
> over the whole request (cf. clarifying rewording in Update and draft response
> to RV-10) [1,2]. If there's no agreement here, then we have to change the
> definitions in Update, and apparently, implementations which passs the
> Suggested test cases would need to be changed.
> As for your suggested additional case, I think this is a tricky one:
>> INSERT  { GRAPH :g1  { _:b :p :o } } WHERE {}; INSERT  {
>> GRAPH :g2  { _:b :p :o } } WHERE {}
> According to my reading of our definitions, this depends on whether we view
> the two empty mappings returned by the two WHERE clauses as identical or
> Different, since the skolem function sk in
> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetQuadPattern
> is unique to the request and the mapping (this behaviour is analogous to CONSTRUCT)

In a SPARQL Construct different bNodes are generated for each occurrence 
of a solution mapping even in the same query.

If the WHERE matches with two empty rows:

row1 = {}
row2 = {}


CONSTRUCT { _:a :p :o }

generates two triples with two different bNodes as subjects.

So within the same WHERE clause the same-by-value binding generates 
different bNodes.

Therefore only (2) makes sense to me.  Defining in terms of operations 
is enough.

Received on Monday, 1 October 2012 11:38:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:07 UTC