Re: SPARQL 1.1 Update Review (part 1)

On 28/03/11 19:06, Axel Polleres 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'

Some comments.
Trimmed out 'done' to leave 'open' items.

	Andy


>> == 1.1.1 Language Form

>> [**] First example is bad syntax.
>>
>> INSERT ==>  INSERT DATA
>
> done. made it
>
>   INSERT {<http://example/egbook3>  dc:title  "This is an example title" } WHERE {}
>
>   to keep it an instance of the language form (strictly speaking it still isn't, due to the prefix, but well.
>


INSERT ... WHERE {} is a bit weird.
Better:


PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{<http://example/egbook3>  dc:title  "This is an example title" }

or a real {} clause.

>>
>>
>> [] "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...)
>
>
>> == 1.1.2 Terminology

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

Yes.

Having <b>must</b> in descriptive sections and having a formal section 
is duplication, but he formal section is definitive.


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

On further reflection, I think we ought to allow zero operations as a 
valid (if ineffective but ping) request.  It can help code-generated 
operations.

This is a grammar change.

syntax-update-bad-01.ru
syntax-update-bad-02.ru
syntax-update-bad-03.ru

>> [*] 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?
>
>> == 2 Graph Store

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

>> == 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?
>
>> [**] Does this all tie to the SPARQL protocol?
>>
>
> * Open: not sure what to do here
>
>> == 3 SPARQL 1.1 Update Language

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

"The effect of operations is defined as being the effect is being 
executed in the order given in the request"

>> == 3.1 Graph Update
>> [**] 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.

>> == 3.1.1 INSERT DATA

>> [] Provide an example using GRAPH.
>> Don't rely on fwd reference to 3.1.2
>>
>
> * Open
>
>> [**] "Default graph of the graph store"
>
> * Open? not sure... if that was only about capitalization, then I have changed it.

More than that:

INSERT DATA { GRAPH <g> { <s> <p> <o> } <s1> <p1> <o1> }

mentions GRAPH and also affects the default graph. The text says default 
graph if no mention of a graph.

>> == 3.1.3 DELETE/INSERT
>>
>> 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?

Not the template - usually a problem with nesting or continuing a 
section after a lower nested section.

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

>> [*] Example:
>>
>> Immediately uses WITH.
>
> * Open
>
>>
>> [*] Show an example where the WHERE has multiple matches.
>>
>
> * Open
>
>> == 3.1.4.

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

Not sure why bNodes in DELETE matter but there you go.  Now minor.

>> == 3.1.5

>> 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...
>
>> == 3.1.6 DELETE WHERE

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

>> [**] "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>
>
> BTW, I assumed that LOAD creates a graph when it doesn't exist beforehand.

Good point.

Add [**]

>> == 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)
>
>> == 3.2 Graph Management

>> [] Format similarly to 3.1 with a list mentioning each operation in this section.
>>
>
> * Open
>
>> == 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?
>
>> == 3.2.2 DROP

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

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

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

Online validator: http://www.sparql.org/update-validator.html

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

Received on Tuesday, 29 March 2011 10:48:55 UTC