Re: Update review

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/