Re: SPARQL 1.1 Update Review (part 1)

I went through this mail from Paul first to see what is still left from Andy's comments, before I go through Greg's comments...


Open issues still left that we may want to check before LC from my point of view summarised:

1) usage of <strong>must</strong> etc. is still spread over Section 3, but I have no concrete suggestions what to change and where.
I admit that the formal specification in Section 4 and the remarks in Section 3 cannot be kept totally 
apart in the current doc, but don't have resources to do a major restructuring. So, I am afraid that will stay, unless Paul/Alex have resources.

2) I would like to change "<iri>" in the doc's pseudo grammar to IRIRef and link to the actual grammar, unless objections.

3) I rewrote/weakened  the section 2.3 on entailment and consistency... needs to be checked.

4) I wanted to use <div4> in xmlspec, but it seems that leveling doesn't work below <div3> ... who knows how to fix that?

5) overuse of WITH/USING in examples... Paul to remove, as promised?

6) "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."
   Paul to check whether any other "*Open" points need to be resolved before LC. 

details below inline...

Axel


On 5 Apr 2011, at 06:35, Paul Gearon wrote:

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

fine with me, i.e., that's fixed now.

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

That is still open, I see the problem, but I have no concrete suggestions what to change and where.
I admit that the formal specification in Section 4 and the remakrs in Section 3 cannot be kept totally 
apart in the current doc, but don't have resources to do a major restructuring.
 

> >> [*] 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
> 

fine with me, i.e., that's fixed now.

> 
> >> [*] 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.

Hmmm, I actually meant changing "<iri>" to "<code><em><a href="http://www.w3.org/TR/sparql11-query/#rIRIref">IRIref</a></em></code>" anything against that?
The current grammar allows IRIRef, whereas we write now:

"
   <iri> - This refers to an absolute IRI according to RFC3987, and not a relative IRI with string "iri".
"

This sounds like relative URIs should be forbidden, which - by grammar - they aren't. Would it be a problem to just change that do:

  <code><em><a href="http://www.w3.org/TR/sparql11-query/#rIRIref">IRIref</a></em></code> - This refers to an IRI, given in angle brackets or as prefixed name. 


?


> 
> 
> >> [**] 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?

I don't think we need to restrict this, as I don't see consensus on standardising this behavior.
Rather than further specifying this, I'd drop the discussion about it.
As the positions stand, I just left that untouched, and suggest to leave it like that.

> 
> >> == 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).


I have read again over this whole section... I don't like the first paragraph, since entailment regimes do not compute "entailed statements" but rather "entailed answers", to be honest. Can we  weaken this section to:
"
If the store is capable of calculating entailed answers, c.f. SPARQL 1.1 Entailment Regimes, then it is possible for update operations to interact with entailed data. In particular, a DELETE operation may attempt to remove entailed statements without actual effects.

After an update request is completed, a store that performs consistency checking with respect to a particular entailment regime on its graphs may check the new state of the graph store for consistency. If inconsistency is detected, the store may return an error to the request.
"
(I went ahead with that on CVS, let me know if objections)

> 
> 
> >> [**] 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.

I interpret this as: no action required on the Update side for now.

> 
> 
> >> [**] 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?
> 
I changed in the document now:

s/
 The operations of a request are executed in lexical order.
/
 Implementations <strong>must</strong> ensure that operations of a single request are executed in a fashion that guarantees the same effects as executing them in lexical order.
/

hope that solves the issue and consider it done from my side.

> 
> >> [**] 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.

I consider this solved/done from my side with the change done, unless other proposals.

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

Still Open: Can anyone help on that?


> 
> >> [*] 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.

Is this done? I won't further consider it.


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

Leaving this as is. No further action required, I hope.

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

I didn't touch this, but despite the questionable "SPARQL 1.0 Tutorial", I don't consider that an urgent issue, i.e. done for the moment.

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

Well, even if so, the change to IRI scheme is ok, yes? I consider this done.

> 
> >> [] 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".
> 
> changed that to:

"
<note>For services which form the default graph from the unions of other graphs then <code>CLEAR DEFAULT</code> may 
have further implications which we leave unspecified here.</note>
"

consider it done with that.

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

I left that in, but following the resolution explicitly added the words "AT RISK".
 
> 
> >> == 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.


let's leave it, unless explicit objections raised.

> 
> >> [**] "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.

Please check back all the other Open issues in my orignal mail, I will do the same, if I get to it.

Axel


> 
> Regards,
> Paul
>

Received on Wednesday, 20 April 2011 16:27:38 UTC