Re: SPARQL 1.1 Update Review (part 1)

On Mon, Mar 28, 2011 at 2:06 PM, Axel Polleres <axel.polleres@deri.org> wrote:
> Hi all,
>
> As I did some edits on Update, and thought along the way I coult also go through Andy's review (part1),
> I addressed many of his comments (took me more time than I expected :-) )
>
> Find below, what's covered by my changes and what probably still needs attention...
> Those not yet addressed are marked with
> '* Open'

Jumping ahead....

>> [] "Here, [] indicates an optional part of the syntax"
>> As ()* and ()+ is used, isn't it clearer to use ()?
>>
>
> * Open: I didn' change that yet, since it'd need a lot of changing from [] to ? (although I agree...)


I like [...] over (...)? but I've gone with the majority.


>> == 1.1.2 Terminology
>>
>> [**] <b>must</b>
>>
>> Only the formal section needs the "must" etc language now.  All mentions in the explanatory parts can be made normal language.
>>
>> There is use of <b>MUST</b>.
>>
>
> Do you mean in section 3? I didn't touch those yet, since somethings, such as e.g. sequence of update requests,
> are not yet mentioned/handled in Section 4.

Section 4 doesn't deal with a number of things that recevied MUST,
MAY, etc, elsewhere in the document. I don't think we can remove them
all. Do you know of specific examples that are not needed?


>> [*] Request is one or more operations.
>>
>> Should we allow zero operations? The empty string? Why not?
>>
>
> * Open: *shrug* no preference from my side, left that 'as is'.


Changed to "zero or more" to match ACTION-431


>> [*] Also used terminology:
>> <uri>
>> mean an absolute IRI according to RFC 3987.
>> Not a relative URI with string "uri".
>
> * Open: Well, anything against changing <uri> to IRIref linking to the SPARQL grammar here?

Added. Also changed all use of URI to IRI. LOAD has a reference to a
URL which I've left alone.


>> [**] Unnamed graph as union.
>>
>> I suggest removing all discussion of union because the doc does not define the actions on a UNION.  What happens when the union is updated? Where do the changes go? Only the union? Which named graph?
>
> * Open: I lef the sentence "Depending on implementation, the unnamed graph may refer to a separate graph, or it could be a representation of a union of other graphs." untouched so far. I think it is important to say something along these lines in the document, although I am not sure whether here and in that way is the best way to to so... If someone has concrete rewording proposals or the majority agrees with Andy's suggestion to drop this, then also the later Note referring to deletion of the default graph in implementations doing that should go.


The union case for the default graph seems to be a common one, and is
useful for querying. Perhaps we need to make a statement about what
happens if an update attempts to modify a default graph that is based
on a union? Should these graphs be treated as read-only?


>> == 2.3 Entailment and Consistency
>>
>> [*]  "An update is completed": request or operation?
>> Only requests matter - an impl could (carefully) do operations in a different order if the effect is the same as the textual order but inconsistency checking is different.
>>
>> If it's request is completed, where does the exception go?
>>
>
> * Open: I am unclear about what to do with this, particularly, what is meant with "inconsistency" here exactly. Logical inconsinstency in terms of e.g. OWL?

I read it as an inconsistency wrt the entailment regime (which may be OWL).

(I say, "I read it as..." because I can't recall if I wrote it or not).


>> [**] Does this all tie to the SPARQL protocol?
>>
>
> * Open: not sure what to do here


This may be done in the protocol, or else the behavior may be left up
to the individual stores. I'm not the one to answer this.



>> [**] Operations are executed in lexical order.
>> See above.
>> The effects are the same as being executed in lexical order.
>> I can see
>> LOAD <x1> INTO GRAPH <u1>
>> LOAD <x2> INTO GRAPH <u2>
>> LOAD <x3> INTO GRAPH <u3>
>> being cleverly done.
>>
>> [*] Operations are executed in lexical order.
>> They aren't :-)
>>
>> Requests are (logically)
>>  INSERT ... WHERE ...
>> and it does the WHERE first but it's later lexically.
>
> * Open: not sure how to address that, any rewording proposals?

Unless I misunderstand something, then I think we may be interpreting
the term "operation" in different ways. I refer to a complete
INSERT/DELETE/WHERE as a single operation, for instance. The ordering
of each individual part of that operation is certainly not lexical. Am
I correct in saying that you (Andy) are referring to each part as an
"operation"? (part = WHERE, or INSERT, or DELETE)

If I'm wrong, can you clarify it for me please? Are you able to give
an example where "operations" are executed in a different order to
their appearance in a request?


>> [**] The fundamental pattern-based operations ... are INSERT and DELETE.
>>
>> The fundamental operation is the INSERT..DELETE..WHERE operation.
>> Either s/operations/actions/ so INSERT and DELETE are actions (but as action is not defined this is not a nice change), or reword with INSERT..DELETE..WHERE being fundamental.
>>
>> Given the activity comment above, defining "action" as an inserting or deleting and using that as the building block should work document-wide.
>>
>
> * Open (somewhat): I did the change s/operations/actions/, but it is local to that paragraph.

This looks like the same issue I was asking about above.


>> [] Provide an example using GRAPH.
>> Don't rely on fwd reference to 3.1.2
>>
>
> * Open

Done



>> Suggestion: Make DELETE and INSERT are 3.1.3.1 and 3.1.3.2 respectively.
>> Suggestion: 3.1.3.1. and 3.1.3.2 are examples, and omit the descriptive text that repeats what went before.
>>
>
> * Open: I tried to make them <div4>, but there's a problem with the numbering then... Does that need to be fixed in the template?

Is this a limit in the documentation levels?

>> [*] Give a simple example of DELETE/INSERT before getting to discussing WITH, USING.
>> Overall, there is a lot of use of WITH/USING and I was left with the feeling this is preferred style or necessary style, but it isn't. Suggest removing from the majority of examples, where it isn't necessary for the point being made, would be clearer.
>
> * Open

I'll remove these.

I prefer WITH since I never use the default graph, though I see that
not having it makes the examples more on point.


>> [*] Example:
>>
>> Immediately uses WITH.
>
> * Open

See above

>> [*] Show an example where the WHERE has multiple matches.
>>
>
> * Open

Done

>> [**] Bad action:
>> Unbound variables in the DELETE clause ==> no effect.
>>
>> To be honest, I'm tempted to suggest that DELETE templates allow and match with unbound variables.  The case of
>>
>> DELETE { ?x foaf:name ?name } WHERE { ?x foaf:mbox_sha1 ?foo }
>> for
>> DELETE { ?x foaf:name ?name } WHERE { ?x foaf:mbox_sha1 ?foo . ?x foaf:name ?name }
>> is reasonably compelling.
>
> * Open: I fixed the example to work (i think) as intended, but changing unbound variables to behave universal seems to bring us pretty much to a similar
>  discuss as we had for bnodes in DELETE... I am unsure whether we want to go down that road at this stage.


Leaving this as Axel did. I agree that it's a similar discussion to
the one we had on blank nodes. The example isn't compelling for me.



>> The WHERE clause does not match.
>>
>> The book has date in 2002? 1948 surely!
>>
>> And it's one "P" in "David Coperfield" by Edmund Wells.
>> http://www.inprint.co.uk/thebookguide/bookshop-skit.htm
>>
>> This example is trying too hard.
>
> * Open: I didn't check the rest of the example...

Fixed it (I think). I agree that it's trying too hard. (I didn't pick
up on the title/author, but now that you've pointed it out it couldn't
be left as it was). The presence of the "SPARQL 1.0 Tutorial" seems
completely out of place as well.



>> == 3.1.7 LOAD
>>
>> [*] s/protocol/URI scheme/
>>
>
> done.

In this case, it's that subset of URIs that are referred to as URLs.
In the case of URLs, then the scheme becomes the protocol, doesn't it?

>> [] Don't mention file: -- it's rather weakly defined and used in practice in ways outside the strict standard. Mentioning it is just trouble.
>>
>
> * Open: didn't want to touch that... Alex/Paul some particulr reason you wanted to have that in?



I have seen it in a lot of places, most likely because it's built into Java. ie.

$ echo 'hello world!' > /tmp/data.txt
$ clojure-repl
user=> (import '[java.net URL] '[java.io InputStreamReader BufferedReader])
user=> (-> (URL. "file:/tmp/data.txt") .openStream InputStreamReader.
BufferedReader. .readLine)
"hello world!"

It's not necessary to include file:, but it seems like a common enough
idiom, and the text only says, "Common forms will be....". But for now
I've taken it out to emphasize http:.



>> [**] "In case no data can be retrieved."
>> What about an empty graph?
>
> * Open: good point! I did the following for the moment, let's see whether that flies with everybody:
>
> <p>In case no RDF data can be retrieved (as opposed to the empty graph being retrieved) from <code>documentURI</code>, the SPARQL 1.1 Update service is expected to return failure. In any other case, it will always return success. If <code>SILENT</code> is present, the result of the operation will always be success. In case the graph named &lt;<strong>uri</strong>&gt; does not exist in the graph store, and the reteived graph is non-empty, it will be created; an empty graph being retrieved will not create a new graph in the graph store.</p>


I'm OK with this.

> BTW, I assumed that LOAD creates a graph when it doesn't exist beforehand.


I presume the same. I added:

"The specified destination graph is created if required."

I chose that wording so that systems that do not support empty graphs
will not be obliged to create a graph if an empty graph is retrieved
from the documentIRI.


>> == 3.1.8
>
>> [**] "far reaching implications"
>> Which are what?
>>
>> Just don't discuss it - the spec is not defining the effect.
>>
>
> * Open: I just didn't want to remove it yet, but I am fine to remove it (along with the comment further above)


That's the kind of opening in the spec that bugs me as an implementor.
I have no personal stake in it, since I don't do unions for the
default graph, but I'm unsatisfied leaving it completely unmentioned.

I'd be perfect happy if it was just called out as being "unspecified".



>> == 3.2 Graph Management
>> [] Format similarly to 3.1 with a list mentioning each operation in this section.
>>
>
> * Open

Done


>> == 3.2.1 CREATE
>>
>> "Stores that do not record empty graphs will always return success."
>>
>> So if the store has graph <g> with triple <s> <p> <o> and the request is
>>
>> CREATE GRAPH <g>
>>
>> what has empty graphs got to do with it?  This sentence is out of place but I don't know what it's place should be.
>>
> * Open: for now made a guess and reworded to
>
> "
> <p>Stores that do not record empty named graphs will always return <em>success</em> on creation of a non-existing graph.</p>
> "
>
> which I think was the intention?

Yes, this was the intention.


>> == 3.2.2 DROP
>> This has a MUST in upper case.  See earlier and the termininolgy says "must".
>>
>
> * Open

Did you mean to mark this as "Open"? It was already done.

>> [**] Editors note in document must be removed before LC.
>>
>
> * Open

This is ISSUE-59, about the use of the copy/move/add shortcuts. We've
had no feedback on them. Do we just leave these features in and take
out the editor's note?


>> == 3.2.3 COPY
>> "Is equivalent to" example
>> includes "GRAPH DEFAULT" in the INSERT which is illegal in a template or pattern.
>>
>
> * Open? ... admittedly still handwaving, but changed this to :
>
>  DROP SILENT (GRAPH <toURI> | DEFAULT);
>  INSERT { ( GRAPH <toURI> | '') { ?s ?p ?o } } WHERE { ( GRAPH <fromURI> | '') { ?s ?p ?o } }
>
>  better?


The construct of:
  ( GRAPH <toURI> | '')
is a bit odd, but I see why you've written it that way. If everyone
else likes this, then I'm OK with it.

>> [**] "If the destination does not exist, it will be created"
>> Didn't we decide that some stores may require explicit CREATE, and that's why we have SILENT?
>
> * Open: Hmmm, we said for INSERT before that it will do implicit CREATE, or no? I am not sure whether I misread
>    "If an operation tries to insert into a graph that does not exist, then that graph must be created."
>  but I read it as implicit create... Honestly, if we make a distinction here, and don't do implicit creation, I am worried the whole formal semantics definition will become trickier, I wouldn't opt for going down that road at this stage.


We decided that those stores that need to create a graph will now need
to create them automatically (and implicitly) on an INSERT into that
graph. However, there is still an expectation on some of  those stores
that they can have an empty graph. Hence the continued need for
CREATE. SILENT is still there in case the graph already exists and you
don't care.


Didn't get to do more than this, but I got a software release out the
door on Friday, so I have more time now.

Regards,
Paul

Received on Tuesday, 5 April 2011 05:36:07 UTC