Re: Update review

Excellent.

Looks like this addresses all the concerns I had, I don't think  
there's much value in me rereading the document, but I'm happy to.

- Steve

On 15 Oct 2009, at 10:43, Simon Schenk wrote:

> Am Mittwoch, den 07.10.2009, 12:58 +0100 schrieb Steve Harris:
>> General Points
>>
>> Somewhere this document needs to say that update operations lean on
>> SPARQL algebra, and how to resolve WHERE {} clauses w.r.t SPARQL/ 
>> Query.
>
> Done in section 6.
>
>> Lots of parts of this document assume a particular outcome of
>> ISSUE-20, ideally alternative designs would be shown, but at least  
>> the
>> relevant sections should highlight this. I've tried to point out the
>> obvious ones, but I may have missed some.
>
> Should all marked in notes.
>
>> I think that other reviewers might do better to wait for future
>> revisions, as it stands there is not enough clearly finished content
>> to warrant reviewing.
>>
>> All the red HTML errors need to be fixed.
>
> Done modulo XML-rec changes, as agreed in last telco.
>
>> 2.2 Aggregate functions
>> 2.3 Service Description
>> 2.4 Negation
>> 2.5 BGP extensions of different entailment regimes
>> 2.6 Basic Federated Query
>> 2.7 Property Paths
>> 2.8 Query Language Syntax
>>
>> These are all either "time permitting", or have no text in them, so  
>> it
>> might be better if these sections were removed in the first draft.
>
> Removed the empty ones, kept the rest in section 2, which has been
> renamed to "Relation to new features in SPARQL 1.1"
>
>> The examples in 3c,d,e have no timezone, it's not required in XSD,  
>> but
>> it might be clearer with a timezone specifier, the examples in  
>> SPARQL/
>> Update 1.0 have timezones.
>
> Done.
>
>> I think in these examples a description of the possible outcomes  
>> would
>> make them more useful. E.g. in 3b, what happens if the DELETE fails  
>> to
>> match anything?
>
> Done.
>
>> 4 The Graph Store
>>
>> "A Graph Store is a repository of RDF graphs managed by a single
>> service." - what does "service" mean in this instance, I imagine it's
>> not a service in the HTTP sense?
>>
>> "Unlike an RDF dataset, named graphs can be added or deleted to a
>> graph store." does that imply that unnamed graphs cannot be added or
>> deleted?
>
> Yes, because they cannot be identified.
>
>> 4.2 SPARQL/Update Services
>>
>> "SPARQL/Update requests are a sequence of operations." - SPARQL/ 
>> Update
>> requests need to be defined. there's a kind of description in 5, but
>> it's not really sufficient.
>
> Added a note.
>
>> "If two different update services are managing their respective graph
>> stores share
>> a common graph..." - it sounds like this might contradict the first
>> para of 4?
>>
>> "An implementation must target SPARQL queries on updated graphs if  
>> the
>> SPARQL and
>> SPARQL/Update end points are the same." - how can you tell? Should
>> that be SPARQL/Query? Sounds to be at odds with 4.
>
> No contradiction.
> For clarification added
> "A Graph Store need not be authoritative for the graphs it contains."
> to 4 and modified 4.2 as follows:
> "If two different update services are managing their 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"
>
>> "Multiple operations can be packed into requests." - Using HTTP
>> pipelining, or just lexically? Again, need definition of request.
>>
>> "The operations of a request are executed in order given." - lexical
>> order? or some other?
>
> Clarified as follows:
> "Multiple operations can be packed into requests. The operations of a
> request are executed in lexical order."
>
>> 5.1 Graph Update
>>
>> "Graph update operations change existing graphs in the Graph Store  
>> but
>> do not create or delete them." - that depends on the outcome of
>> ISSUE-20, doesn't it?
>
> Added note mentioning dependence on ISSUE-20 and marking this  
> behaviour
> at risk.
>
>> 5.1.* would all be clearer with examples, <i>template</i> and
>> <i>pattern</i> isn't really clear enough, and it shouldn't be
>> necessary to read the grammar to broadly understand what these
>> requests look like. Suggest you move/copy/reference the examples in
>> section 3, for now at least. Ideally there would be more examples  
>> here.
>
> Done by referencing examples.
>
>> 5.1.4 DELETE and 5.1.5 INSERT
>>
>> The semantics need explaining. E.g. if multiple INTO clauses are  
>> used,
>> is the WHERE pattern required to match for all graphs, or one graph,
>> or just the graphs that will be inserted/deleted? It's not clear.
>
> Clarification:
>
>> 5.1.6 LOAD
>>
>> Needs to be mentioned in Security Issues section.
>
> Done.
>
>> 5.1.7 CLEAR
>>
>> Needs to reference ISSUE-20
>
> Done.
>
>> 5.2 Graph Management
>>
>> "The default graph in a Graph Store always exists." - earlier in the
>> doc it says that there can be zero or one default graph.
>
> Fixed to one for now and added a not to 4 marking this behaviour at
> risk.
>
>> 5.2.1 Graph Creation
>>
>> Needs to reference ISSUE-20
>
> Done.
>
> Cheers,
> Simon
>
>
> -- 
> Simon Schenk | ISWeb | Uni Koblenz
> http://isweb.uni-koblenz.de
> http://www.uni-koblenz.de/~sschenk
> Five sentences policy: http://five.sentenc.es/

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 15 October 2009 12:12:26 UTC