Re: Example updates

On Thu, Dec 3, 2009 at 6:33 AM, Andy Seaborne <andy.seaborne@talis.com> wrote:
>
>
> On 03/12/2009 10:57, Steve Harris wrote:
>>
>> On 3 Dec 2009, at 01:44, Paul Gearon wrote:
>>
>>> On Wed, Dec 2, 2009 at 6:32 AM, Steve Harris <steve.harris@garlik.com>
>>> wrote:
>>>>
>>>> On 1 Dec 2009, at 21:06, Paul Gearon wrote:
<snip/>

>>>>> (3) Or using GRAPH instead of INTO:
>>>>>
>>>>> WITH <source>
>>>>> INSERT { GRAPH <destination> { ?s ?p ?o } }
>>>>> WHERE { ?s ?p ?o }
>>>>
>>>> So, in this case wouldn't INSERT ... FROM be a perfectly reasonable
>>>> thing to
>>>> write? It would have the same meaning as in SELECT, wouldn't it?
>>>
>>> I'm not sure where you're going here.
>>>
>>> Are you suggesting using FROM to indicate what the WHERE clause should
>>> be resolved against? If so, then sure. However, the advantage of WITH
>>> is that it also applies to INSERT and DELETE where no graph is
>>> supplied. In that case, the word "FROM" isn't appropriate. WITH is a
>>> little more general, even if it's not very pretty.
>>
>> Ah, I see, I think.
>>
>> ...
>
> Having a "apply to this particular graph" form is a good idea but it needs
> scoping - I prefer an explicit scope form: how about:
>
> USING <a>
> {
>   DELETE
>   INSERT
>   WHERE
> }
>
> When looking at abbreviated DELETEs combined with WITH, the forward scope of
> the qualification needs to be considered and this makes explicit what it is.
>
> ((Similar issues for the backwards scope of WHERE  - this proposal doesn't
> help that one.))

I was going to respond that it's the same sort of thing that we see
with WHERE, but you obviously see that.  :-)

I do agree with you in general, but not here. Given the way that
SPARQL already attaches WHERE to SELECT and FROM NAMED, plus we're
looking to attach HAVING in there as well, then I think the precedent
has been set. What you're suggesting here is not really consistent
with the way the rest of the language is structured, so I wouldn't
want to use this explicitly scoped approach (unless there is no way
around it).

Alternatively, we can go back and start scoping SPARQL all the way
through (wouldn't that solve Holger's LET issues?). :-)  This
"backward compatible" requirement can get awfully tiresome.

Wasn't someone looking at an XML representation of SPARQL queries? ;-)

Regards,
Paul Gearon

Received on Thursday, 3 December 2009 17:21:15 UTC