W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Comment on Dataset-UNION

From: Polleres, Axel <axel.polleres@deri.org>
Date: Wed, 23 Feb 2011 12:53:45 -0000
Message-ID: <316ADBDBFE4F4D4AA4FEEF7496ECAEF9051D2A60@EVS1.ac.nuigalway.ie>
To: <andy.seaborne@epimorphics.com>
Cc: <public-rdf-dawg@w3.org>
Yes, I agree with the point you raised, the merge was wrong and should be replaced by set-union, the scoping graph issue is an additional issue.

Best,
Axel

----- Original Message -----
From: Andy Seaborne <andy.seaborne@epimorphics.com>
To: Polleres, Axel
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Sent: Wed Feb 23 12:49:45 2011
Subject: Re: Comment on Dataset-UNION



On 22/02/11 20:31, Axel Polleres wrote:
>
> On 22 Feb 2011, at 17:27, Andy Seaborne wrote:
>
>> Dataset-UNION is defined to do an RDF merge - it should be set-union.
>>
>> Graph store:
>>     DG: { _:a :q :r }
>>
>> INSERT { ?x :p 123 . } WHERE { ?x :q :r }
>>
>> then we get:
>>
>> _:a :q :r .
>> _:x :p 123 .
>
> Hmmmmm, right, but don't we have a more fundamental additional problem there?
> i.e. isn't the scoping graph (which is used to evaluate the query) only required to be graph-equivalent to the Dataset/Graph Store...
>
>  From http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#BGPsparqlBNodes

>
> "If DS is the dataset of a query, pattern solutions are therefore understood to be not from the active graph of DS itself, but from an RDF graph, called the scoping graph, which is graph-equivalent to the active graph of DS but shares no blank nodes with DS or with BGP. The same scoping graph is used for all solutions to a single query."
>
> i.e. that would mean, we'd need to say that - unlike for Query - in Update the scoping graph for any graph in the graph store is that same graph?
>
> We probably can - as you suggest - define that in a more precise Definition of Dataset(modify_template,P) which is still fairly hand-waving at this stage
> (what I am a little worried about is whether a strict definition of the scoping graph locks us in with regard to extending SPARQL Update towards entailment at some later stage...)
>
> best,
> Axel
>
>>
>> because bnodes are not equated in a merge, but are renamed apart:
>>
>> [[ http://www.w3.org/TR/rdf-mt/

>> if they do share blank nodes, then it is the union of a set of graphs
>> that is obtained by replacing the graphs in the set by equivalent graphs
>> that share no blank nodes. This is often described by saying that the
>> blank nodes have been 'standardized apart'.
>> ]]
>>
>> it needs to be a set union.  Constant bnodes are treated by naming
>> apart, for and every query solution, but not for bnodes arriving by
>> variable substitution.
>>
>> Dataset(modify_template,P) can handle the renaming apart, the
>> dataset-union can then be a union.
>>
>>          Andy

Even when the scoping graph was the original graph (which I was assuming 
it was), so after template matching, it's the same bNode (by label).

It's the next step, describing the process as "RDF merge" that's the 
problem, as I see it.

Graph store:
      DG: { _:a :q :r }

INSERT { ?x :p 123 . } WHERE { ?x :q :r }
==> ?x=_:a

so we have _:a :p 123 to add.

But the addition to the set, as defined in "Dataset-UNION" is an RDF 
merge, not a set-union.  And at this point, the bNodes are renamed 
apart, hence the _:a :p 123 goes to _:x :p 123 then the triple is 
union'ed into the graph.

	Andy
Received on Wednesday, 23 February 2011 12:55:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT