Review prov-aq

Hello,

Here's my review of the latest revision of prov-aq. I answer the three review 
questions first, before I point out some (mostly editorial) issues in the 
document.

Q1 Is this ready for release as a working draft?

Given the editorial issues listed below are addressed (which shouldn't be too 
difficult), I would say: Yes, it is.

Q2 Is the service specification now meeting expectations?

Very good. I like the simplification. Good job, Paul!

Q3 Are additions or modifications necessary?

Some modifications: For those things that might be a bit more controversial or 
elaborate I raised issues (namely: ISSUE-358 ISSUE-359 ISSUE-360 and 
ISSUE-361). Furthermore, I propose to address the following editorial issues 
(since I consider them non-controversial I didn't raise official issues for 
them; feel free to do so, if you think it's necessary):

1) Subsection 'PROV Family of Specifications' under 'Status of This Document' 
says in the 1st bullet point: "PROV-DM, the PROV data model for provenance 
(this document)," - The part in parentheses should be moved to the PAQ bullet 
point.

2) In the definition of 'Constrained resource' (Sec.1.1):  s/An constrained/A 
constrained/

3) Sec.1.2, para 1:  s/listing restaurants/listing of restaurants/

4) Sec.1.2, para 1:  s/the weather forecast for London/a weather forecast for 
London/

5) The following sentence in Sec.1.2 is strange: "Separate URIs for each 
individual revision would also have target-uris, each denoting the 
specification at a particular stage in its development."  I guess this is meant 
to be:  "... would be target-uris," instead.

6) The first sentence in Sec.1.3 is "Provenance information describes 
relationships between resources, including activities and agents." This 
sentence is confusing: The first part is too general because it seems to 
include all kinds of relationships, not just provenance-related relationships. 
For the second part it is not clear whether the description (or relationships) 
may include activities and agents or activities and agents are considered as 
resources. I propose to remove the whole sentence altogether.

7) The second to last sentence in Sec.2 is a bit strange. I propose to remove 
"either at a URI or within a Service"

8) Sec.3, para 1:  s/If this is known/If this URI is known/

9) Sec.3, para 3:  It's not clear what the word "This" in the last sentence 
refers to.

10) Sec.3.1:  s/If no anchor link/If no anchor parameter/

11) Sec.3.1.1, para 1:  s/about the document/about the resource/

12) Sec.3.2:  s/element specifies an specifies an identifier/element specifies an 
identifier/

13) Sec.3.2 last para is: "If no "anchor" link element is provided then the 
target-uri is assumed to be the URI of the document. It is recommended that 
this convention be used only when the document is static and has an easily-
determined URI."  It should be specified what is meant by "easily-determined 
URI".

14) Sec.5:  s/the URI of a SPARQL endpoint (or, to use the SPARQL specification 
language, a SPARQL protocol service)./the URI of a SPARQL protocol service 
(often referred to as a "SPARQL endpoint")./

15) Sec.5.1:  s/has an target-uri/has a target-uri/

16) Before Sec.5.1.1 I propose to add the following sentence: "The following 
subsections illustrate use cases for querying a SPARQL-based provenance query 
service."

17) Sec.5.2.1, bullet point 1: "For a given resource (target-uri-1) retrieve 
..."  Shouldn't that be "resource-uri" instead of "target-uri-1"?


Best,
Olaf

Received on Friday, 20 April 2012 10:13:02 UTC