- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 01 Oct 2012 12:38:26 +0100
- 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 = {} then 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. Andy
Received on Monday, 1 October 2012 11:38:54 UTC