Re: SPARQL Update 1.1 review part1

On 2/8/2011 11:24 AM, Paul Gearon wrote:
> On Tue, Feb 8, 2011 at 9:58 AM, Lee Feigenbaum<lee@thefigtrees.net>  wrote:
>> On 2/7/2011 10:38 PM, Paul Gearon wrote:
>>>
>>> Alex originally dealt with Axe's review, but I am going over it now.
>>>
>>> I have a question about Axel's point 27:
>>>
>>>
>>> On Thu, Sep 30, 2010 at 6:10 PM, Axel Polleres<axel.polleres@deri.org>
>>>   wrote:
>>>>
>>>> 27)
>>>> "Using a new blank node in a delete template will lead to nothing being
>>>> deleted, as the new blank node cannot match anything that already exists."
>>>>
>>>> this seems to contradict resolution
>>>> http://www.w3.org/2009/sparql/meeting/2010-03-09#resolution_2
>>>> I haven't seen any resolution overriding that, but I might have missed
>>>> that. Even if we decided to override that resolution, it is not entirely
>>>> clear to me what "new" blank node means exactly here.
>>>
>>> Here is a copy of the resolution that Alex mentions:
>>>
>>> "Blank nodes in DELETE templates act as "wild cards", effectively as
>>> variables bound to all RDF terms; the same blank node cannot be used
>>> in the WHERE clause and the template, or in multiple BGPs"
>>>
>>> Unfortunately, I was not at this meeting, and it's something that I
>>> missed when the minutes came around. I find this to be an unfortunate
>>> decision, as it effectively makes the template part of the WHERE
>>> clause. To illustrate, the operation:
>>>
>>> DELETE { [] :p ?x }
>>> WHERE { ?x :q :z }
>>>
>>> Is going to be effectively the same as:
>>>
>>> DELETE { ?a :p ?x }
>>> WHERE { ?x :q :z . ?a ?p ?o }
>>
>> Right, this was the goal of the resolution. Can you explain your concern?
>
>
> It brings some of the operation of the WHERE clause into the DELETE
> clause. In general, the WHERE clause provides bindings by doing a
> query on the data, while the DELETE clause is a template that
> describes triples/quads based on those bindings. The above approach
> allows the DELETE clause to participate in the query, which blurs the
> operations between the two clauses.
>
> The syntax also seems misleading. I expect that users being introduced
> to this would expect [] to bind only to blank nodes. I know that blank
> nodes in WHERE clauses have always bound to anything, but until now
> templates (ie. in CONSTRUCT queries) have always used [] to refer to
> blank nodes. So this is another case where the DELETE template is
> taking on some of the semantics of the WHERE clause.
>
>> From a practical perspective, this means that the parse/transformation
> code needs to update the query portion of this operation based on the
> template. I can usually keep them separate, and this is an exception
> that doesn't seem to have any benefit.
>
> Given that it's easy to express a "wildcard" with a variable and an
> update to WHERE, then I don't see any benefits to this semantics.
> Instead I see it as an annoying exception.

Hi Paul,

I do think that the Working Group considered this issue pretty 
thoroughly when the decision was made. See, for example:

* 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0428.html 
(email summarizing the possibilities; also see subsequent thread)

* http://www.w3.org/2009/sparql/meeting/2010-03-09#Blank_Nodes_in_Delete 
(telecon discussion that led to the resolution)

I'm not inclined to revisit this decision at this point in time. Please 
let me know if you see something significantly new and would like the 
working group to consider it.

Lee

>
>>> (ignoring the existence of the ?p and ?o)
>>>
>>> I'm really uncomfortable with this. Is it set in stone?
>>
>> Like all decisions, we can revisit it if there is new information that was
>> not originally considered, but the later we get in the process, the higher
>> the bar for substantive new information to cause us to change a decision
>> should probably be.
>
> It's not a large part of the Update document, and it's easy for me to
> change either way. The document doesn't currently match the
> resolution, so I'm supposed to update it right now. However, it's not
> a change I like making for the above reasons, which is why I would
> like the resolution revisited.
>
> Regards,
> Paul Gearon
>

Received on Tuesday, 15 February 2011 15:09:50 UTC