Update review

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.

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.

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.

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.

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.

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?

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?

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.

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

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

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?

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.

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.

5.1.6 LOAD

Needs to be mentioned in Security Issues section.

5.1.7 CLEAR

Needs to reference ISSUE-20

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.

5.2.1 Graph Creation

Needs to reference ISSUE-20

- Steve

-- 
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 Wednesday, 7 October 2009 11:59:46 UTC