Re: SPARQL Update 1.1 review part1

Lee,

1)
> I don't think this is the case at all. The reason we chose USING instead
> of FROM was not ambiguity but the fact that
> 
> DELETE { ... } FROM g WHERE { ... }
> 
> wouldn't do at all what it sounds like it does.


Hmmm, while I still think it originally arose also from the syntactic ambiguity 
with DELETE FROM which is no longer there, after some research, I guess you're right, 
I just checked and DELETE FROM disappeared before we had this discussion in detail. 

Anyways, as mentioned

>  I can *live* with sticking with USING, but it causes me a significant stomach pain.


2)
As for NAMED vs. ALL NAMED, the same applies, I can live with it, so if no one else 
finds it ambiguous, ok to stick with NAMED alone here.

Axel


On 6 Oct 2010, at 23:33, Lee Feigenbaum wrote:

> On 10/6/2010 11:02 PM, Axel Polleres wrote:
> >> I'm pretty sure we've been over this already and made the decision that
> >> the negatives of FROM/FROM NAMED (very misleading with what it means)
> >> were stronger than the negatives of new keywords (USING/USING NAMED). I
> >> don't think we ought to put an editorial note in here unless we actually
> >> ARE discussing it, and as far as I can tell that discussion reached a
> >> conclusion many months ago unless there is new inforomation.
> >
> > Let me try to objectively assess this:
> >
> > The "new information" here is, as far as I recall, that this decision was taken when FROM really
> > caused some abiguity, i.e. when we still were discussing having DELETE FROM in the syntax.
> > Now that this isn't the case any more, we have DELETE { GRAPH ... } ,
> 
> I don't think this is the case at all. The reason we chose USING instead
> of FROM was not ambiguity but the fact that
> 
> DELETE { ... } FROM g WHERE { ... }
> 
> wouldn't do at all what it sounds like it does.
> 
> Lee
> 
> >
> > <chairthat-off>
> > my personal opinion, is that I think that this makes the situation
> > different, since the ambiguity is no longer an issue and that the additional
> > keyword USING looks
> > strange to people familiar with SPARQL query, who would expect FROM here.
> >
> > I can *live* with sticking with USING, but it causes me a significant stomach pain.
> > </chairthat-off>
> >
> > Axel
> >
> >
> > On 6 Oct 2010, at 17:29, Lee Feigenbaum wrote:
> >
> >> On 10/6/2010 3:21 PM, Axel Polleres wrote:
> >>>>> 24) Can someone help me when the USING syntax was agreed? It seems
> >>>> that, since we no longer have DELETE FROM/INTERST INTO (since we now
> >>>> use GRAPH patterns to indicate the affected graphs), there is no need
> >>>> anymore to avoid FROM and FROM NAMED, so I strongly suggest to switch
> >>>> back to FROM/FROM NAMED also in update queries.
> >>>>>
> >>>>> IMHO, USING just creates more confusion than it solves ... another
> >>>> new keyword, and not easy to explain to anyone why FROM and FROM NAMED
> >>>> don't work here the same way that they work in Query...
> >>>>
> >>>> IIRC, decision was let to editors and Paul made the change.
> >>>> Is that a major issue for you, Axel ?
> >>>
> >>> Frankly, I don't like it, since as we removed DELETE FROM, it seems
> >>> unnecessary to introduce a new keyword.
> >>> would be good to mark with an editor's note:
> >>>
> >>> "The group is currently discussing whether own keywords USING/USING
> >>> NAMED are necessary, or whether FROM/FROM NAMED can just be used
> >>> analogously to SPARQL1.1 Query"
> >>
> >> I'm pretty sure we've been over this already and made the decision that
> >> the negatives of FROM/FROM NAMED (very misleading with what it means)
> >> were stronger than the negatives of new keywords (USING/USING NAMED). I
> >> don't think we ought to put an editorial note in here unless we actually
> >> ARE discussing it, and as far as I can tell that discussion reached a
> >> conclusion many months ago unless there is new inforomation.
> >>
> >> Lee
> >>
> >>
> >>>
> >>>> 25) - 27)
> >>>
> >>> should be marked at least in the document with TODOs, if still open?
> >>>
> >>>
> >>>>> 28)
> >>>>> "If no data is to be inserted, then no graph will be created, even
> >>>> if another dataset would result in data being inserted."
> >>>>>
> >>>>> Why do we need that? A store may decide to drop empty graphs
> >>>> anyways, so this seems to be redundant and introduce an extra burden for
> >>>>> graph aware stores that they have to check whether the insert has
> >>>> any results before creating the graph.
> >>>>
> >>>> I don't see the issue here.
> >>>> Why would stores check something ?
> >>>
> >>> What I am saying is that this sentence can safely be dropped. I think it
> >>> is ok to insert an empty graph in that case, or
> >>> to drop that empty graph immediately. I.e., what you write here is more
> >>> restritive then what is said in section 3.1, I
> >>> would rather simply reformulate this to:
> >>>
> >>> "If no data is to be inserted, an empty graph MAY be created, see
> >>> section 3.1 Graph update."
> >>>
> >>>
> >>>>> 29)
> >>>>> "If a graph must be created regardless of the data to be inserted"
> >>>>> -->
> >>>>> "If the user intends to create a graph regardless of the data to be
> >>>> inserted"
> >>>>
> >>>> Used "If an operation intends to create a graph regardless of the data
> >>>> to be inserted"
> >>>
> >>> note that if you do the above suggested reformulation, this one is void
> >>> and should be removed.
> >>>
> >>>
> >>> 30)
> >>>
> >>> we can resort this in the next version.
> >>>
> >>>>> 31)
> >>>>> "Refer also to the final INSERT example, which demonstrates multiple
> >>>> operations, including a DELETE."
> >>>>>
> >>>>> is this a TODO or what should this sentence tell the reader?
> >>>>> maybe better:
> >>>>>
> >>>>> "For another example involving DELETE, we refer the reader also to
> >>>> the final example in the following section, which demonstrates
> >>>> multiple operations, combining an INSERT with a DELETE."
> >>>>
> >>>> Done - rephrased to:
> >>>>
> >>>> "Another example of<code>DELETE</code>, is provided in the<a
> >>>> href="#example_h">final example</a>  in the following section, which
> >>>> demonstrates multiple operations, combining an<code>INSERT</code>
> >>>> with a<code>DELETE</code>."
> >>>
> >>> too many commas here, I think:
> >>>
> >>> "Another example of<code>DELETE</code>  is provided in the<a
> >>> href="#example_h">final example</a>  in the following section
> >>> which demonstrates multiple operations combining an<code>INSERT</code>
> >>> with a<code>DELETE</code>."
> >>>
> >>>
> >>>>> 33) Section 4.1.8 CLEAR
> >>>>>
> >>>>> I think "ALL NAMED" would be clearer than "NAMED"
> >>>>
> >>>> I'd rather keep NAMED, and I think that's explicit enough (also
> >>>> defined in the formal model).
> >>>
> >>> hmmm, I find ALL NAMED really more intuitive, to be honest... shall we
> >>> put that up for discussion in a separate mail?
> >>>
> >>>
> >>> 37) see 33) ...
> >>>
> >>> I think non of these prevent us from publishing, i.e. if you can address
> >>> them or add editor's notes, great, but not critical as long as we don't
> >>> forget them... but would you mind putting all remaining issues we
> >>> couldn't agree upon or which are left as TODO up for discussion in a
> >>> separate email to the group?
> >>>
> >>> thanks,
> >>> Axel
> >>>
> >>>
> >>> On 3 Oct 2010, at 06:06, Passant, Alexandre wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Document was not yet ready for review, but I incorporated most of your
> >>>> change, see below (a few TODOs left).
> >>>> Will send the request for review soon, just going through it one last
> >>>> time.
> >>>>
> >>>> Alex.
> >>>>
> >>>> On 30 Sep 2010, at 23:10, Axel Polleres wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> sorry for the late review due to traveling/non-connectivity... (also
> >>>> working on remaining actions such as update test vocabulary, etc.)
> >>>>>
> >>>>> Now I realise that my print version I had for review is based on an
> >>>> old version and will only list those comments still valid.
> >>>>> I will check on the new parts in a part 2 of this review.
> >>>>>
> >>>>> ==================
> >>>>>
> >>>>>
> >>>>> Section 1:
> >>>>>
> >>>>> 1) We use both terms "RDF Store" and "Graph Store" in the document,
> >>>> but only the latter is formally defined. I'd recommend to use "RDF
> >>>> Store" uniformly (or Graph Store, since it seems to be in use quite
> >>>> long already, but I like "RDF store" more) unless those terms are
> >>>> menat to be really different. If so, we need to define what we mean by
> >>>> RDF Store.
> >>>>>
> >>>>> Also, I'd suggest to *always* link to the definition, when the terms
> >>>> *graph store* or *rdf store* are used.
> >>>>
> >>>> Done - replaced uniformly to Graph store
> >>>>
> >>>>>
> >>>>> 2) "The reuse of the SPARQL syntax, in both
> >>>>> style and detail, reduces the learning curve for developers and
> >>>>> reduces implementation costs."
> >>>>>
> >>>>> I think this sentence doesn't add anything and recommend to delete it.
> >>>>>
> >>>>
> >>>> Done
> >>>>
> >>>>> 3) "For the rationale behind this language, see the original SPARQL
> >>>> New Features and Rationale document."
> >>>>>
> >>>>> This doc is not rec track, I don't think we should reference it in a
> >>>> rec track doc. opinions?
> >>>>
> >>>> That's just a reference, as we do reference other non-REC not non-W3C
> >>>> documents.
> >>>> However, it may be more suited in the overview document that on the
> >>>> Update one.
> >>>> I'd suggest to keep it there and remove when the overview document is
> >>>> there
> >>>>
> >>>>>
> >>>>> 4) "This document is related to these other specification documents:"
> >>>>> -->
> >>>>> "This document is related to the following other specification
> >>>> documents:"
> >>>>>
> >>>>
> >>>> Done
> >>>>
> >>>>> 5) "SPARQL 1.1 Update is not:
> >>>>>
> >>>>> * A replacement for RSS or Atom, which
> >>>>> may be used to advertise changes."
> >>>>>
> >>>>> RSS and Atom should both be included in the informative references
> >>>> of the document.
> >>>>
> >>>> Actually, I'm not sure that sentence is required (esp. as they are now
> >>>> more things to advertise changes in RDF graphs, so the list is
> >>>> incomplete).
> >>>> If no objects, I'll remove it.
> >>>>
> >>>>>
> >>>>>
> >>>>> 6) "Language forms are show as:
> >>>>> [...]
> >>>>> [] indicates [...]"
> >>>>> -->
> >>>>> "Language forms are show for instance as follows:
> >>>>> [...]
> >>>>> Here, [] indicates [...]"
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 7)
> >>>>> "Italics indicate an item is some syntax element derived from SPARQL
> >>>> Query. BOLD indicates literal text."
> >>>>> -->
> >>>>> "Italics indicate syntactic items derived from the SPARQL Query
> >>>> grammar. BOLD indicates language keywords."
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> Note that this is actually still not 100% consistent, since you also
> >>>> use italics for new grammar elements specific to update.
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 8)
> >>>>> "Examples are shown as:"
> >>>>> -->
> >>>>> "Examples are shown as follows:"
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 10)
> >>>>> In section 1.2.2
> >>>>>
> >>>>> "The following terms are also used in this document, and are defined
> >>>> in the SPARQL 1.1 Query Language"
> >>>>> -->
> >>>>> The following terms are also used in this document as defined in the
> >>>> SPARQL 1.1 Query Language
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> in the bullet list following this sentence, use fixed width Italic
> >>>> font for the non-terminals from the grammar productions
> >>>>> (TriplesBlock, ConstructTriples, GroupGraphPattern)
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> Section 2:
> >>>>>
> >>>>> 11) Section 2.1
> >>>>>
> >>>>> http://www.w3.org/2009/sparql/track/issues/37 is closed.
> >>>>>
> >>>>> for Alex (re: his last mail), as far as I remember, we simply
> >>>> resolved this a non-issue, since the semantics should be clear.
> >>>>> Check http://www.w3.org/2009/sparql/meeting/2010-08-03#resolution_4
> >>>>> Paul also agreed that it shouldn't have any problems, but wanted to
> >>>> add some explaining words.
> >>>>> I assume that the only issue would be when the SERVICE queried in an
> >>>> update operation is the same as the
> >>>>> service updated, but even that seems to be a non-issue, since this
> >>>> is just the standard behavior.
> >>>>> As I see it in the notes, Steve mentioned "feedback effects" in the
> >>>> meeting, maybe he can clarify?
> >>>>>
> >>>>> In total, I'd hope Section 2 can simply be dropped entirely.
> >>>>
> >>>> Done - ISSUE-37 closed, and section dropped + see last e-mail on the
> >>>> topic for clarification
> >>>>
> >>>>>
> >>>>> Section 3:
> >>>>>
> >>>>> 12)
> >>>>> "Like an RDF Dataset operated on by SPARQL"
> >>>>> -->
> >>>>> "Like an RDF Dataset operated on by the SPARQL1.1 Query Language [ref]"
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 13)
> >>>>> "A Graph Store need not be authoritative for the graphs it contains."
> >>>>>
> >>>>> *authoritative* is not defined anywhere. Either define it, or drop
> >>>> that sentence all-together
> >>>>
> >>>> Rephrased to:
> >>>>
> >>>> "A Graph Store needs not be authoritative for the graphs it contains,
> >>>> i.e. there can be local copies of RDF graphs defined elsewhere on the Web.
> >>>> (I cannot see how to define authoritative more clearly, imo it speaks
> >>>> for itself but suggestion is welcome if not clear enough)
> >>>>
> >>>>>
> >>>>> 14)
> >>>>> "A formal definition for graph stores and how SPARQL 1.1 Update
> >>>> affects them is described in the SPARQL 1.1 Update Definition section."
> >>>>> -->
> >>>>> "A formal definition for graph stores and how SPARQL 1.1 Update
> >>>> affects them is described in the SPARQL 1.1 Update Formal Model section."
> >>>>> (and fix the anchor, which doesn't work at the moment)
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 15)
> >>>>> "[...]It is recommended that such deployment scenarios are avoided."
> >>>>> The whole paragraph would benefit from clearer wording, but that
> >>>> last sentence is totally unclear to me. What now is to be avoided exactly?
> >>>>> This needs clarification, IMO
> >>>>
> >>>> Done - I rephrased the paragraph to
> >>>>
> >>>> "In the case of two different update services, whose respective graph
> >>>> stores contain graphs with the same names, there is no presumption
> >>>> that the updates done through one service will be propagated to the
> >>>> other, as the store are independant entities.
> >>>> The behaviour of these services with respect to each other (such as
> >>>> automatic syncronisation after updates) is implementation dependent."
> >>>>
> >>>> However, I cannot see why it should be avoided, so I dropped that last
> >>>> sentence.
> >>>>
> >>>>>
> >>>>> 16)
> >>>>> "An implementation must target SPARQL queries on updated graphs if
> >>>> the SPARQL and
> >>>>> SPARQL 1.1 Update end points are the same."
> >>>>>
> >>>>> also not clear to me what that should say. esepacially what "must
> >>>> target" means here?
> >>>>> plus, should the *must* be bold here, i.e. is the RFC sense meant here?
> >>>>
> >>>> It means that if you've got a single endpoint for query and update,
> >>>> queries should be ran on the updated graphs.
> >>>> But that's imo obvious, I removed it.
> >>>>
> >>>>>
> >>>>> 17)
> >>>>> "If the store is capable of calculating entailed statements"
> >>>>> -->
> >>>>> "If the store is capable of inferring entailed statements, cf.
> >>>> SPARQL1.1 Entailment Regimes [ref]"
> >>>>>
> >>>>
> >>>> Done
> >>>>
> >>>>> 18)
> >>>>> "[...] resulting in the statements not being affected."
> >>>>> -->
> >>>>> "[...] resulting in the statements not being affected of deletions."
> >>>>>
> >>>>
> >>>> Done
> >>>>
> >>>>> 19)
> >>>>> "If an inconsistency is detected, the store should raise an exception."
> >>>>>
> >>>>> not clear to me what "raise an exception" means.
> >>>>
> >>>> Done
> >>>> Based on text from the entailment doc, I rephrased to
> >>>> "may generate an error or warning" (also note should ->  may)
> >>>>
> >>>>>
> >>>>> Section 4:
> >>>>>
> >>>>> 20) The last paragraph before section 4.1 should reference SPARQL1.1
> >>>> Protocol
> >>>>
> >>>> Done - rephrased
> >>>>
> >>>> "This document does not stipulate the exact form of the result, as
> >>>> that will be dependent on the interface being used, for instance the
> >>>> HTTP or a programatic API"
> >>>>
> >>>> =>
> >>>>
> >>>> "This document does not stipulate the exact form of the result, as
> >>>> that will be dependent on the interface being used, for instance the
> >>>> SPARQL 1.1 protocol via HTTP or a programatic API"
> >>>>
> >>>>>
> >>>>> 21)
> >>>>> "The INSERT DATA operation adds some triples, which are inline in the
> >>>>> request, into a graph"
> >>>>> -->
> >>>>> "The INSERT DATA operation adds some triples, given inline in the
> >>>>> request, into a graph"
> >>>>>
> >>>>
> >>>> Done
> >>>>
> >>>>> likewise:
> >>>>>
> >>>>> "The DELETE DATA operation removes some triples, which are inline in
> >>>>> the request."
> >>>>> -->
> >>>>> "The DELETE DATA operation removes some triples, given inline in
> >>>>> the request, if the respective graph contains those."
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 22)
> >>>>> for both DELETE DATA and INTERST DATA an example of
> >>>> insertion/deletion on a named graph would be good.
> >>>>
> >>>> There is one covering both in the DELETE DATA section.
> >>>> I've just added a link to it from the INSERT DATA section to make it
> >>>> more apparent.
> >>>> (note also that I included graphs before / after for all examples)
> >>>>
> >>>>>
> >>>>> 23)
> >>>>> on DELETE DATA, I have two questions:
> >>>>> a) it should be mentioned what happens if I try to delete triples
> >>>> not existent in that graph (I guess nothing, and still return with
> >>>> success, just as for DELETE, right? but I think we also have to
> >>>> mention it for DELETE DATA)
> >>>>
> >>>> Already there:
> >>>>
> >>>> (1) in the DELETE/INSERT section "Deleting triples that are not
> >>>> present, or from a graph that is not present will have no effect and
> >>>> will result in success. "
> >>>> (2) in the DELETE one "The DELETE operation is similar to the
> >>>> DELETE/INSERT operation without an INSERT section."
> >>>>
> >>>> You think it needs emphasis ?
> >>>>
> >>>>> b) it should be mentions what happens if graph_triples contains bnodes.
> >>>>>
> >>>>> concerning b), I am not sure whether we have discussed this in
> >>>> particular in the context of DELETE DATA, but
> >>>>> please note resolution
> >>>> http://www.w3.org/2009/sparql/meeting/2010-03-09#resolution_2
> >>>>> I haven't found any later resolutions on this, but I am not sure
> >>>> whether we intended this behaviour on DELETE DATA.
> >>>>> since actually it means that one can encode a query deletion into
> >>>> DELETE DATA, by using bnodes:
> >>>>>
> >>>>> e.g. if we follow this resolution here, then
> >>>>> DELETE DATA { [] :p [] }
> >>>>> has the same behaviour as:
> >>>>> DELETE WHERE { ?S :p ?O }
> >>>>>
> >>>>> if I see it correctly. If the editors think the same, than I am
> >>>> afraid we have to reopen the issue of bnodes in DELETE clauses, IMO.
> >>>>> (actually, we didn't really ever have an ISSUE on that open, as far
> >>>> as I can see it now.
> >>>>>
> >>>>
> >>>> @@TODO - will check in more details later w/ Paul
> >>>>
> >>>>> 24) Can someone help me when the USING syntax was agreed? It seems
> >>>> that, since we no longer have DELETE FROM/INTERST INTO (since we now
> >>>> use GRAPH patterns to indicate the affected graphs), there is no need
> >>>> anymore to avoid FROM and FROM NAMED, so I strongly suggest to switch
> >>>> back to FROM/FROM NAMED also in update queries.
> >>>>>
> >>>>> IMHO, USING just creates more confusion than it solves ... another
> >>>> new keyword, and not easy to explain to anyone why FROM and FROM NAMED
> >>>> don't work here the same way that they work in Query...
> >>>>
> >>>> IIRC, decision was let to editors and Paul made the change.
> >>>> Is that a major issue for you, Axel ?
> >>>>
> >>>>>
> >>>>> 25)
> >>>>> "Any remaining portions of the GroupGraphPattern which are not
> >>>> assigned a dataset will be matched against the graph specified in the
> >>>> WITH clause, if present, or the default graph otherwise."
> >>>>> -->
> >>>>> "Any remaining portions of the GroupGraphPattern which are not
> >>>> assigned a dataset will be matched against the graph specified in the
> >>>> WITH clause, if present, or the default graph of the graph store
> >>>> otherwise."
> >>>>>
> >>>>> ??? not sure here... actually, it seems that the default *dataset*
> >>>> to be used for the query part could be different from the *graph
> >>>> store*, or do we fix that to be the same (I think for update it would
> >>>> make sense, but I also remember we had some discussions around that...)
> >>>>> anyways, this needs clarification... also with respect to whether
> >>>> WITH also scopes the WHERE part.
> >>>>>
> >>>>> In cae I had missed any discussions on this, I apologies and would
> >>>> kindly ask the editors for the resp. pointers.
> >>>>
> >>>> @@TODO - will check in more details later w/ Paul
> >>>>
> >>>>>
> >>>>> 26)
> >>>>> similarly:
> >>>>> "if omitted, the INSERT or DELETE clauses applies to the graph
> >>>> specified by the
> >>>>> WITH clause, or the default graph if no WITH clause is present."
> >>>>> -->
> >>>>> "if omitted, the INSERT or DELETE clauses applies to the graph
> >>>> specified by the
> >>>>> WITH clause, or the default graph of the graph store if no WITH
> >>>> clause is present."
> >>>>
> >>>> @@TODO - will check in more details later w/ Paul
> >>>>
> >>>>>
> >>>>> 27)
> >>>>> "Using a new blank node in a delete template will lead to nothing
> >>>> being deleted, as the new blank node cannot match anything that
> >>>> already exists."
> >>>>>
> >>>>> this seems to contradict resolution
> >>>> http://www.w3.org/2009/sparql/meeting/2010-03-09#resolution_2
> >>>>> I haven't seen any resolution overriding that, but I might have
> >>>> missed that. Even if we decided to override that resolution, it is not
> >>>> entirely clear to me what "new" blank node means exactly here.
> >>>>
> >>>> @@TODO - will check in more details later w/ Paul
> >>>>
> >>>>>
> >>>>> 28)
> >>>>> "If no data is to be inserted, then no graph will be created, even
> >>>> if another dataset would result in data being inserted."
> >>>>>
> >>>>> Why do we need that? A store may decide to drop empty graphs
> >>>> anyways, so this seems to be redundant and introduce an extra burden for
> >>>>> graph aware stores that they have to check whether the insert has
> >>>> any results before creating the graph.
> >>>>
> >>>> I don't see the issue here.
> >>>> Why would stores check something ?
> >>>>
> >>>>>
> >>>>> 29)
> >>>>> "If a graph must be created regardless of the data to be inserted"
> >>>>> -->
> >>>>> "If the user intends to create a graph regardless of the data to be
> >>>> inserted"
> >>>>
> >>>> Used "If an operation intends to create a graph regardless of the data
> >>>> to be inserted"
> >>>>
> >>>>>
> >>>>> 30) Section 4.1.4, Example 2
> >>>>>
> >>>>> "An example to remove all statements about anything with a first
> >>>> name of "Fred" from the graph http://example/addresses. No WHERE
> >>>> clause is present, meaning that the template also serves as the
> >>>> pattern to be matched."
> >>>>> -->
> >>>>> "An example to remove all statements about anything with a first
> >>>> name of "Fred" from the graph http://example/addresses. No DELETE
> >>>> template is present, meaning that the WHERE clause also serves as the
> >>>> template."
> >>>>>
> >>>>> BTW, this example is for DELETE WHERE and not for DELETE.
> >>>>
> >>>> Done - I changed it to another DELETE example (w/ USING).
> >>>> I also fixed the text to fit with the next example
> >>>>
> >>>>> I ask myself whether we really need separate DELETE and DELETE WHERE
> >>>> sections... it seems perfectly fine to
> >>>>> change the grammar in the beginning of section 4.1.4 as follows:
> >>>>>
> >>>>> [ WITH<uri>  ]
> >>>>> DELETE { modify_template [ modify_template ]* }
> >>>>> [ USING [NAMED]<uri>  ]*
> >>>>> WHERE GroupGraphPattern
> >>>>>
> >>>>> -->
> >>>>>
> >>>>> [ WITH<uri>  ]
> >>>>> DELETE [{ modify_template [ modify_template ]* }]
> >>>>> [ USING [NAMED]<uri>  ]*
> >>>>> WHERE GroupGraphPattern
> >>>>>
> >>>>> i.e. making the modify_template optional... and remove section 4.1.6
> >>>> over all (maybe keeping some of the examples for section 4.1.4)
> >>>>>
> >>>>
> >>>> In that case, you allow WITH<uri>  DELETE WHERE { } ?
> >>>> and DELETE USING<>  WHERE {} ?
> >>>>
> >>>> I'm fine with that, but we may have to think of implications of this
> >>>> change.
> >>>> For instance, I cannot see how the 2nd will be used. (USING is useless
> >>>> here)
> >>>>
> >>>> But merging would make sense, will think of it
> >>>>
> >>>>> 31)
> >>>>> "Refer also to the final INSERT example, which demonstrates multiple
> >>>> operations, including a DELETE."
> >>>>>
> >>>>> is this a TODO or what should this sentence tell the reader?
> >>>>> maybe better:
> >>>>>
> >>>>> "For another example involving DELETE, we refer the reader also to
> >>>> the final example in the following section, which demonstrates
> >>>> multiple operations, combining an INSERT with a DELETE."
> >>>>
> >>>> Done - rephrased to:
> >>>>
> >>>> "Another example of<code>DELETE</code>, is provided in the<a
> >>>> href="#example_h">final example</a>  in the following section, which
> >>>> demonstrates multiple operations, combining an<code>INSERT</code>
> >>>> with a<code>DELETE</code>."
> >>>>
> >>>>>
> >>>>> 32)
> >>>>> section 4.1.6 ... see above, should be merged into 4.1.4
> >>>>>
> >>>>
> >>>> Cf previous comment
> >>>>
> >>>>> 33) Section 4.1.8 CLEAR
> >>>>>
> >>>>> I think "ALL NAMED" would be clearer than "NAMED"
> >>>>
> >>>> I'd rather keep NAMED, and I think that's explicit enough (also
> >>>> defined in the formal model).
> >>>>
> >>>>>
> >>>>> 34)
> >>>>> "but is a clearer expression of emptying a graph."
> >>>>>
> >>>>> I think this should be dropped.
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 35)
> >>>>> Why don't we have SILENT for LOAD?
> >>>>
> >>>> Probably because we didn't specify return status of the LOAD clause.
> >>>> I've added:
> >>>>
> >>>> "<p>In case no RDF data can be 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.</p>"
> >>>>
> >>>> + support for SILENT
> >>>>
> >>>> In the previous sentence, should we mention GRDDL, etc. ? I don't
> >>>> think we already discussed that, but some store allow to LOAD
> >>>> XHTML+RDFa or GRDDL-ed data (4store through librdf IIRC ?)
> >>>>
> >>>>
> >>>>>
> >>>>> 36) Section 4.2.2
> >>>>> "This DROP operation"
> >>>>> -->
> >>>>> "The DROP operation"
> >>>>
> >>>> Done
> >>>>
> >>>>>
> >>>>> 37) in Section 4.2.2 as well, a similar risk remark should be added
> >>>> here as in Section 4.1.8
> >>>>> particularly, I would be interested what DROP means if the default
> >>>> graph is the union of the named graphs.
> >>>>> what does DROP DEFAULT actually mean.
> >>>>>
> >>>>> Again NAMED should be replaced by ALL NAMED, i think this is clearer
> >>>>
> >>>> Same answer as for 33)
> >>>>
> >>>>>
> >>>>>
> >>>>> a detailed review of Section 5 will follow in part 2
> >>>>
> >>>> Can you wait that I commit with the formal model ?
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Axel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Dr. Alexandre Passant
> >>>> Digital Enterprise Research Institute
> >>>> National University of Ireland, Galway
> >>>> :me owl:sameAs<http://apassant.net/alex>  .
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>

Received on Thursday, 7 October 2010 04:18:56 UTC