Re: Update changes

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.
>>
>> Anyone who is swapped in on update -- please review these changes so
>> that we can decide on publishing the update document on Tuesday.
>
> The document looks OK for publishing in this cycle.
>
>        Andy

That being the case, I'll leave it alone and put your suggestions into
the next cycle.

>> Lee
>>
>> Paul Gearon wrote:
>>>
>>> I've updated the Update document with the following:
>>>
>>> - Added a Terminology section.
>
> This should be a top-level section, not 1.2.2.
>
> I presume this will grow over time e.g merge with Graph Store

Ah, OK. I see that this is the case in many of the other documents. I
actually took this lead from section 1.2.4 of rq25.xml:
  http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#docTerminology

>>> - Removed the "Property Paths" section now that issue 38 has been
>>> resolved.
>
> and also "2.2 Basic Federated Query" is a time permitting feature.

I didn't see that as formally recognized, but I'm pretty sure that
time does not permit, right?

>>> - 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?

Second, how do you define "reject"? 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.

>>> The working copy is at:
>>> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml
>
> Issue 19 is mentioned twice (3.2 and A)

OK, I'll leave it in the Security section only.

> Issue 21 is now closed.
>
> The References section is not ours.

I haven't even looked at this. Are you saying it was copied/pasted
from another document?

Regards,
Paul Gearon

Received on Monday, 18 January 2010 20:29:51 UTC