- 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