- From: Paul Gearon <gearon@ieee.org>
- Date: Mon, 18 Jan 2010 15:29:11 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
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