W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: Update changes

From: Paul Gearon <gearon@ieee.org>
Date: Mon, 18 Jan 2010 15:29:11 -0500
Message-ID: <a25ac1f1001181229g20d51184o59489b67473c31f3@mail.gmail.com>
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:

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:59 UTC