Re: Update on Update

On 07/01/2010 8:28 PM, Paul Gearon wrote:
> Andy,
>
> You mention closing a couple of the issues below. I'm not really clear
> on the procedure, but does that have to happen during a meeting?

A question for the chairs, surely?

>
> On Wed, Dec 23, 2009 at 6:30 AM, Andy Seaborne<andy.seaborne@talis.com>  wrote:
>> On 19/12/2009 03:34, Paul Gearon wrote:
>>> ISSUE-27: Can subqueries (ASK, SELECT etc.) be nested inside update
>>> queries?
>>
>> Patterns should be the same as query 1.1 IMO so SELECT subqueries.
>>
>> But at F2F2:
>> ----
>> RESOLVED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY,
>> with each feature 1.1 adds to SPARQL Query being AT RISK for this. This
>> closes ISSUE-27.
>> ----
>
> So the issue gets closed, but the "AT RISK" indicates that these
> features may or may not be included. I'd have thought that closing
> this issue would figure out these features, but apparently not.
>
> While I understand that an implementation will be permitted to build
> on SPARQL 1.1 Query for SPARQL 1.1 Update, this resolution makes it
> appear that the spec won't be doing this.

It puts any new features from SPARQL 1.1. query "at risk".  That means 
it's a warning it might be taken out but for now, all 1.1 features in 
patterns are being done.

See also end of
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0376.html

> That means that we won't be
> able to use a common grammar for the spec (which you - Andy - mention
> below). I recall some of this conversation, but I do find it unusual
> that SPARQL 1.1 Update would only require SPARQL 1.0 Query. Is it
> likely that anyone will want to implement Update while not also
> implementing the new query facilities?

(who is that question to?)

IMHO defining SPARQL 1.1 Update with SPARQL 1.0 WHERE patterns make no 
sense.

If desperate, as SPARQL 1.1 is a superset of SPARQL 1.1 we can have a 
combined grammar and only test for compliance on SPARQL 1.0 patterns. 
But I think that SPARQL 1.1 Update should use SPARQL 1.1 Query and I 
don't know of any reason to the contrary.  There was speculation that 
some systems might implement SPARQL 1.0 patterns but as far as I know it 
was just speculation.  I'd just regard it as a partial implementation of 
SPARQL 1.1 Update anyway.

I strongly prefer that "SPARQL 1.1 Update" is based on "SPARQL 1.1 Query".

...
>>>
>>> ISSUE-21: More complex operations, e.g. CHANGE objects?
>>> Unresolved. Leaving issue in the document. But I think we're not going
>>> to do anything, are we?
>>
>> I'd like to leave this open - get the design done then see if there are any
>> addition syntactic short forms to put in.  Changing a triples object is
>> something that is a perma-thread on jena-dev so theer is a user/application
>> writer expectation here.   I thin it's just change object value - it may be
>> better addressed with a clear and explicit example (or examples) in
>> SPARQL/Update.
>
> I think this is necessary, but is it necessary in SPARQL? I figured
> SPARQL to be a triple-level language. Now that's not adequate for most
> people working with data, but I see object querying and manipulation
> being implemented in a higher level language which may be built on
> SPARQL. (I'm admin for a project that does just this: Topaz).

Wrong kind of object.

I meant object of a triple. S-P-Object.

:book dc:title "Wrong"  ==> :book dc:title "Right"

	Andy

...

>
> Regards,
> Paul Gearon

Received on Thursday, 7 January 2010 23:05:43 UTC