RE: prov-aq review for release as working draft (ISSUE-613)

Hi Paul and Graham,

Thank you for the revised document. Please find my review below.

Best wishes,

Dong.

Questions for reviewers
- Can this be released as a last call working draft? Yes
- Is the name provenance access and query appropriate for the document? Yes
- If not, where are the blocking issues?  None
- If yes, are there other issues to work on?

Section 2.

A REST protocol for provenance querying is defined in Section section 4. Provenance query services<https://dvcs.w3.org/hg/prov/raw-file/b3f397c7b15c/paq/prov-aq.html#provenance-query-services>; also described there is a mechanism for locating a SPARQL query service.
Why mention a SPARQL query service here? So far into the document, I haven’t see the link to a SPARQL service.

Provenance may be presented as a bundle<https://dvcs.w3.org/TR/prov-dm/#component4>,
I’m not sure why we need to promote the use of bundles here instead of documents. I have no problem with provenance returned in a bundle, but don’t think we should recommend bundles over documents (by not mentioned anything about documents).
There is no requirement that a bundle identifier can be dereferenced to access the corresponding provenance, but where practical it is recommended that matters be arranged so this is possible.
I think the reader should be given a reason why this is recommended. However, as far as I understand, if a bundle is returned from a direct access URI, if that URI is not the bundle’s identifier, what would the bundle’s identifier be dereferenced into? Would that be the same provenance content? What if it’s different from the current bundle? My simplistic view is that if we already have a URI for the provenance of a resource, that is sufficient. I yet to see the benefits of having a dereferencible bundle identifier.
If it is the second case, where the provenance content can only be accessed via a service because it is not directly available in some way, it is not practical to follow this recommendation anyway.

In addition, I think the texts that follow on RDF serialisation might be more suitable in a later section. Section 2 seems to me describing the different ways to access provenance content in general, and the discussion about how to deal with a particular serialisation seems to be into a bit the details.

Section 3.1.1

#hasQueryService à #hasProvenanceService, perhaps? So it’s clear about the nature of the service

Example in Section 3.1.2:
Would anchor="http://example.com/resource/content.html be better to show that the anchor can change?

Section 3.2
This is nit-picking but I’m wondering about the case in which a document can have multiple provenance URIs and each refers to the document by a different anchor. Is this possible? If so, how can we deal with multiple anchor links? If not, we may want to make our assumptions explicit.

(though, in simple cases, we anticipate that hasProvenance andhasQueryService link relations would not be used together)
I feel this this is not necessary. A consumer should anticipate both can happen, I think, if it can handle both.

Section 4

I feel that the overview should include an outline/structure of the following subsections as I did not see a clear/natural link to 4.2 when I reached it.

Section 4.1

The service description should be available as RDF
This is a bit too strong. I think the intention is “The service description should at least be available as RDF”, if I’m not mistaken.

Appendix B
Definition rref à Reference?
Some ref links do not resolve


From: pgroth@gmail.com [mailto:pgroth@gmail.com] On Behalf Of Paul Groth
Sent: 10 January 2013 15:13
To: Provenance Working Group WG
Subject: prov-aq review for release as working draft (ISSUE-613)

Dear all,

PROV-AQ is now ready for review. This should be considered as a "last call" working draft version.

You can find the draft to review at:

https://dvcs.w3.org/hg/prov/raw-file/b3f397c7b15c/paq/prov-aq.html


Tim, Simon, Luc, Dong and Stian agreed to review but all comments are appreciated.

Questions for reviewers
- Can this be released as a last call working draft?
- Is the name provenance access and query appropriate for the document?
- If not, where are the blocking issues?
- If yes, are there other issues to work on?

We particularly encourage reviewers to look at Section 5 Forward provenance as this is a new section.

In your review please include ISSUE-613

Thank you,
Paul and Graham

-- your friendly prov-aq editors


--
--
Dr. Paul Groth (p.t.groth@vu.nl<mailto:p.t.groth@vu.nl>)
http://www.few.vu.nl/~pgroth/

Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam