PROV-AQ responses to Dong's review

Dong (http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0072.html)

 >>> My responses are prefixed like this.

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.
 >>> I think it's appropriate to mention here as an option.
 >>> Text revised, and added link to SPARQL-SD

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).
 >>> I think this is something we were asked to address by the WG.
 >>> Addressing the specific point, the text has been revised and moved to a 
supporting note, so it's clearly not part of the spec.

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.
 >>> We're describing a possibility here, not recommending use of a 
non-dereferencable URI
 >>> The point I was truing to expose here is that of the provenance is served 
from, say, a dataset named graph used for a bundle, it is possible that the 
bundle URI is not directly dereferencable.
 >>> Personally, I would view a provenance document at a URI as a bundle, so in 
this case the bundle *would* be dereferencable.  But I'm not sure if we can 
claim definitively that a document at a URI *is* a bundle.
 >>> I've reworked the text to try and put the bundle more into context, and 
moved it to a note

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.
 >>> Hmmm, the focus was *meant* to be on the problems of access.  An RDF 
Dataset is NOT a serialization.
 >>> I'm hoping the reworking of the text (section 2, note at end) helps here.

Section 3.1.1

#hasQueryService à #hasProvenanceService, perhaps? So it’s clear about the 
nature of the service
 >>> I'm not sure what is being suggested to change here
 >>> Does the change based on Stian's proposal makes this clearer?


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


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.
 >>> This is possible, but I regard it as something of an edge case.  It's 
similar to the case of multiple HTML <links> elements, but should probably be 
exposed here if this can be done briefly.  IIRC, my response to one of the 
comments from Stian was to put something about this in the section on provenance 
interpretation - if that is done, a cross-ref may be enough?
 >>> Added brief note and cross-reference to section 1.2

(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.
 >>> I agree, but I think this was added in response to a previous comment
 >>> The text here has been revised in response to an earlier comment; no 
further change:
[[
An HTML document header may present multiple provenance-URIs over several 
#has_provenance link elements, indicating a number of different provenance 
records that are known to the publisher of the document, each of which may 
provide provenance about the document (see section 1.3 Interpreting provenance 
records).
]] section 3.2
[[
There may be multiple #has_query_service link elements, and these may appear in 
the same document as #has_provenance link elements (though we do not anticipate 
that #has_provenance and #has_query_service link relations will commonly be used 
together).
]]


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


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.
 >>> The emphasis here has been changed.
[[
In keeping with REST practice for web applications, alternative service 
descriptions using different formats may be offered and accessed using HTTP 
content negotiation. We describe below a service description format that uses 
RDF to describe two query mechanisms.
]] -- section 4

and

[[
The service description presented here may be supplied as RDF (in any of its 
common serializations as determined by HTTP content negotiation), and it may 
contain descriptions of one or more available query mechanisms. Each query 
mechanism is associated with an RDF type, as explained below. (The presentation 
here of RDF service descriptions does not preclude use of non-RDF formats 
selectable by HTTP content negotiation.)
]] -- section 4.1

 >>> That is, the general mechanism applies for service descriptions in any 
format, but this document describes only an RDF format.



Appendix B
Definition rref à Reference?
 >>> I don't understand this comment
Some ref links do not resolve
 >>> Fixed

Received on Monday, 11 March 2013 10:01:50 UTC