RE: PROV-AQ responses to Dong's review

Hi Graham,

Thank you very much for implementing the changes and the detailed responses! I'm happy with your responses.

I did not realise that there were some badly converted characters in my original email so I included the unclear comments here:

Section 3.1.1
#hasQueryService --> #hasProvenanceService, perhaps? So it’s clear about the 
nature of the service

(Now it should read #has_query_service --> #has_provenance_service)

Appendix B: "Definition ref" --> just simply "Reference" or "Definition"?

Many thanks,

Dong.
________________________________________
From: Graham Klyne [graham.klyne@zoo.ox.ac.uk]
Sent: 11 March 2013 09:57
To: W3C provenance WG; Huynh T.D.
Subject: 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 12:41:59 UTC