Re: SPARQL Update 1.1 review part1

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 03:33:49 UTC