Re: Review of "SPARQL 1.1 Update"

After being snowed in, Christmas, and then being sick, I'm finally
getting to my backlog...

On Tue, Dec 22, 2009 at 6:57 AM, Andy Seaborne <andy.seaborne@talis.com> wrote:
> == Review of SPARQL 1.1 Update
> Version of 18 December 2009
>
> = Overall
>
> 1/ We have
> "SPARQL 1.1 Update"
> "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"
> "SPARQL 1.1 Protocol for RDF"
>
> Somewhere there needs to be an explaination of the three specs that relate
> to this area.  I suggest we have another doc which is a guide to SPARQL 1.1
> documents.

I agree that we need something like this, but it will be pretty short, right?

> For this publication:
> SPARQL 1.1 Update and SPARQL-HTTP need to have some text relating them.

To get the ball rolling, I came up with:

"A related document is SPARQL 1.1 Uniform HTTP Protocol for Managing
RDF Graphs. This other specification employs the HTTP protocol to
perform update operations using standard HTTP methods, such as PUT and
DELETE. While providing a simple and well known API, it is necessarily
restricted in its operations due to the limited methods in the HTTP
protocol. In contrast, SPARQL 1.1 Update permits multiple
modifications in a single operation, and can use complex SPARQL
queries for constructing data to be inserted, or choosing data to be
deleted. Also, the use of an update language facilitates operations
over other APIs, along with allowing other protocols that may have
different properties for maintaining connections."

Suggestions for improvement please?

> 2/ The term "SPARQL-Update" is used frequently but that isn't the name any
> more.
> e.g. Abstract
>
> "This document describes SPARQL-Update"
> ==>
> "This document describes SPARQL 1.1 Update"

Hmmm, I didn't realize this was the name. I thought it was
SPARQL-Update 1.1. The name "SPARQL 1.1 Update" makes me think that
it's an "Update" on "SPARQL 1.1", not that it's an "Update" language.

Mind you, if anyone were ever confused by this then I'm sure that
they'd get over it pretty quickly. I've updated all occurrences.

> 3/ The language is ambiguous and really could do with fixing (or, at the
> very least, noting the fact)

Can you provide pointers to specific sections please?

> 4/ Fix INSERT DATA and DELETE DATA to take GRAPH and not use FROM/INTO.
>  Fixing now will reduce confusion later.

OK. I hadn't thought about the new syntax being applied to DATA, but I
guess this is more consistent. (naysayers?)

Should the WITH modifier be applicable here too? Since "INTO" is no
longer being used for INSERT, then should it still be used with LOAD?
(I'm guessing so).

> = Main review
>
> == Related work
>
> Spec don't need to have a related work section so it is no longer needed
> (and will quickly date and pointing to a wiki from a frozen document is
> unhelpful).
> Remove. Instead link to
> http://www.w3.org/2009/sparql/docs/features/#sparql-update
>
> Add an explaination of relationship to
> "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"
> (and copy the text into SPARQL-HTTP!)
>
> Add an explaination of relationship to
> "SPARQL 1.1 Protocol for RDF"
> if that's where POSTing update requests wil go.
>
> For this publication, at least add text to give the framework via links.
>  Detailed explaination can come later.

I've added links and put some placeholder text in for the time being.

> == 1.2 Document Conventions
>
> Need to discussion PREFIX and BASE somewhere.
>
> Maybe a "structure of an SPARQL Update Request section" that also uses the
> material about multiple operations in one request, defines some terminology:
> Graph store (already described) , operation, request, modify_template and
> other terms used.
>
> Maybe the final section "2 Terminology" depending on how section 6
> (defintions) works out.

Should the descriptions of structure and terminology should be in the
same section? I'd rather keep them separate, but it's hard to describe
the terminology without it relating to the structure of a request, and
vice versa.

I can put this in straight after "Document Conventions". Did you have
anything to say on this section (it's woefully short).

> == 2 Relation to new features in SPARQL 1.1
> Rename as "editors working notes" or "Outstanding Issues" or soethign to
> make clear from the title it's not permanent.

This makes sense. I was confused as to why it was in there as a titled section.

> == 2.3 Property Paths
> [[
> Using property paths in Update seems to lead to quite a lot of complexity
> quite quickly.
> ]]
> Reads as opinion - could do with explanation or remove.
> Can be read as if the problem is paths in the modify_template, which they
> aren't.

I'll remove the editorial comment, but I still think we should resolve
the issue and I can remove it completely. From my previous email:
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0628.html
"As far as I can tell, it's just a new pattern that may appear in a
WHERE clause, and need not be explicitly mentioned. Is there any other
effect we may need to consider?"

So can we close this issue?

> == 3 Examples
>
> (a)
> s/RDF Store/Graph Store/
>
> I suggest placing the examples with the descriptions of each feature.

With each operation having examples attached to it, I'm also wondering
if operations like LOAD and CLEAR need their own examples as well.
They are simple enough to not really need it, but the pattern for all
the other operations is to include an example.

Also, by moving examples to be next to the appropriate features,
section 3 has been emptied. So the section numbers following are all
decremented by 1.

> Example (e)
> "move" by insert-delete.
> Be good to say that explicitly somewhere.
>
> This can be done in a single operation, which is better style if operations
> and not request are atomic in some system.

I've updated it so that the DELETE operation has a more specific
pattern. This variation isn't possible in a single operation, is it?

> == 4 The Graph Store
>
> Add ref to section 6 SPARQL-Update Definition
> even if it's not finished because otherwise sec 4 feels like the defn of
> graph store.

Added.

> The link to RDF datasets should go to the definition box in SPARQL 1.0 Query
> "12.1.2 RDF Dataset"

Changed.

> == 4.1 Note
> No.
> Protocol/Syntax does not allow it.

OK. What about ISSUE-20? I'm working on the assumption that
non-existent and empty graphs are different things, and I note that
you (Andy) expressed the same point of view in the most recent email
discussing it. Are we close to resolving this issue?

> == 4.2
> "In the case of two different update services, "
> and also connection to SPARQL-HTTP.

You mean that I should add a link to SPARQL-HTTP? Do you mean Protocol
1.1, or the HTTP Protocol for Managing RDF Graphs? It looks like you'd
like a link to the latter, but I'd have thought a link to the former
to be more appropriate (since SPARQL 1.1 Update cannot be used on the
latter). I've included a link to Protocol 1.1.

> A system shoudl be able to provide an update service at:
>  http://host/update
>
> and PUT/POST with
>  http://host/update/localgraph
>  http://host/update/?graph=http://host2/remoteGraph

My reading of this section is that it refers to two (or more) separate
services, such as:

http://host/update-1/localgraph
http://host/update-2/localgraph

Where "localgraph" refers to the same graph accessed through these two
separate services. This seems (to me) to be orthogonal to what you're
discussing here.

> == 5.1 Graph Update
>
> 1/
> WITH/FROM/INTO/GRAPH
> 5.1.1 (INTO), 5.1.2 (FROM), and WITH in 5.1.3, 5.1.4, 5.1.5
> We have three mechanisms for the same thing which is confusing.
>
> It's weird it's:
>  DELETE DATA FROM <uri> { :x :p 123 . }
> but equivalent in effect to:
>  WITH <uri> DELETE { :x :p 123 . }
> or
>  DELETE { GRAPH <uri> { :x :p 123 . } }
>
> Shouldn't DELETE DATA use GRAPH?
>  DELETE DATA { GRAPH <uri> { :x :p 123 . } }
> and eliminate FROM and INTO.

Much as I don't like the syntax, I agree that consistency is more
important. To that end, should WITH be supported on INSERT DATA and
DELETE DATA? It's really only convenience, and for these operations it
seems superfluous. But to be really consistent then maybe it should be
added.

> 2/ Ambiguity.
> This sequence of tokens:
>
> WITH <uri>
> DELETE { ?x :p ?v }
> INSERT { ?x :q ?v }
> WHERE { ?x :q 123 }
>
> can be parsed at least 2 different ways:
>
> As two operations:
> WITH <uri>
> DELETE { ?x :p ?v }
> # No WHERE
> # followed by a separate operation
> # No WITH
> INSERT { ?x :q ?v }
> WHERE { ?x :q 123 }
>
> or as
> # All one operation
> WITH <uri>
> DELETE { ?x :p ?v }
> INSERT { ?x :q ?v }
> WHERE { ?x :q 123 }
> # WITH and WHERE included

The use of semicolon to join these was discussed in the past. That
would seem to me to be the most sensible approach. I've put it in for
now, but would appreciate comment.

> [[
> 5.1.1 INSERT DATA
>
> Insert data into a graph:
>
> INSERT DATA [ INTO <uri> ]*
> { triples }
> ]]
>
> That's insert into one or more graphs.  But replace with restricted
> modify_template* anyway.
>
> Same for DELETE

So you're pointing out that the modify_template syntax doesn't allow
the same set of triples to be inserted into (or deleted from) multiple
graphs without restating those triples for each graph? Are you saying
that you're OK with it? It's unfortunate, but I don't see it as a huge
issue.

> 5.1.5 INSERT
>
> [[
> If the WHERE clause is not present, then the insert template is also treated
> as the pattern for the effective WHERE clause. Because a template used in
> this way must also be a valid pattern, it may not contain blank nodes.
> ]]
>
> Isn't INSERT on it's own without WHERE always a no-op?
> If modify_template = pattern, the WITH must changes the default graph for
> both.
> If so, then I suggest banning it.

You're right. I was on auto-pilot when I copied/pasted this.


> [[
> The INSERT operation is similar to the general INSERT/DELETE operation with
> an empty DELETE template.
> ]]
> It is a general operation with an empty DELETE so "similar" is confusing.
>
> What's a "DELETE template" - wouldn't that be the modify_template of a
> DELETE? Terminology needs sorting out.

Sure.

Actually, looking at it, I'm thinking that INSERT can be avoided
altogether if the DELETE line in INSERT/DELETE is made optional.  ie.

[ WITH <uri> ]
[ DELETE { modify_template [ modify_template ]* }; ]
INSERT { modify_template [ modify_template ]* }
WHERE { pattern }

DELETE still needs its own section, since WHERE may be optional for a
DELETE-only operation.

I'm a little in two minds. Formally, I think it's fine to drop INSERT
(am I right?), but for consistency it might be nice to define
INSERT-only to go along with DELETE-only. I've left it in for the
moment (with some modifications), but would like some feedback on
this.

> 5.1.7 CLEAR
>
> [[
> # Remove all triples.
> CLEAR [ GRAPH <uri> ]
> It has the same effect as:
>
> # Remove all triples.
> DELETE [ <uri> ] { ?s ?p ?o } WHERE { ?s ?p ?o }
> ]]
>
> Isn't it
>  [WITH <uri>] DELETE { ?s ?p ?o } WHERE { ?s ?p ?o }
> ?

Corrected.

> == 6 SPARQL-Update Definition
> "Note" - Need for operator
> See "substitute" in SPARQL 1.1 Query.

Put the reference in, and removed the note.

> == B SPARQL-Update Grammar
> Out of date.
> Better to remove it and leave a placeholder note. than to publish
> conflicting information.

Removed for the moment.

I don't trust myself on grammars. I'll have a go at it, but will need
someone to triple check me.

Regards,
Paul Gearon

Received on Thursday, 7 January 2010 18:35:36 UTC