W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2012

Re: Review prov-aq

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Thu, 26 Apr 2012 13:34:30 +0100
Message-ID: <4F9940D6.9030709@zoo.ox.ac.uk>
To: Olaf Hartig <hartig@informatik.hu-berlin.de>
CC: public-prov-wg@w3.org

Many thanks for this... very helpful comments as usual.

I've applied most of them verbatim.  For a couple I've taken a slightly 
different route that I think respects the substance of the comments.

(This message refers to just non-issue comments, I'm dealing with the raised 
issues separately)


On 20/04/2012 11:12, Olaf Hartig wrote:
> 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 Thursday, 26 April 2012 14:03:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:14 UTC