Re: Update changes

On 18/01/2010 20:29, Paul Gearon wrote:
> On Mon, Jan 18, 2010 at 4:45 AM, Andy Seaborne<andy.seaborne@talis.com>  wrote:
>>
>>
>> On 18/01/2010 2:05 AM, Lee Feigenbaum wrote:
>>>
>>> Thanks, Paul.
....
>>>> - Included reference to RFC 2119 terminology and added emphasized
>>>> SHOULD and OPTIONAL comments.
>>>> - Added note on discussion of blank nodes in DELETE templates.
>>>> - Added note on discussion of INSERTs creating new graphs.
>>>> - Added note on ambiguity around DELETE/INSERT and DELETE statements.
>>>> - Added note on need to mention partially completed LOAD operations.
>>>> - Added OPTIONAL description for graph management operations (for the
>>>> sake of stores that don't support named graphs).
>>
>> Rather that picking out one feature that is optional, maybe better to simple
>> note a service can reject any operation it does not wish to perform.
>
> I have a few questions about that....
>
> First, shouldn't we require a minimal set of operations that make a
> system Update compliant? Is a system compliant if it can parse the
> operations, but refuses to do anything with them?

I think we should spec (and provide a test suite for) SPARQL Update 
without profiles, subsets or anything else.  Systems that implement some 
of it often (SPARQL query experience) do so for reasons of lack of time 
(and an intent to complete sometime or to implement what they need 
first) or some system specific issue.  That does not lead to clearcut 
subsets.

> Second, how do you define "reject"?

The protocol returns 500 - QueryRequestRefused

(not my favourite use of 500 but that's what we have at the moment)

 > Does it report an error, or just
 > do nothing? I presume that it should return something to the client to
 > indicate that nothing was done. However, for graph operations like
 > this, I think it is OK to silently ignore the CREATE and DROP
 > operations if a store doesn't support named graphs (though some stores
 > might want to provide a warning for this). Either way, I see the
 > rejection of triple-based operations like INSERT and DELETE as being
 > different to not doing anything with CREATE and DROP when a store
 > doesn't support named graphs. So I'd like to see some description of
 > what is supposed to happen in each case.

	Andy

Received on Tuesday, 19 January 2010 13:54:27 UTC