Re: PROV-AQ updates

Oleg,

Thank you very much for this.  They are all very useful and constructive 
comments, most of which I've adopted as proposed.

Does the rewording of section 4 para 3 work for you?

I've deferred adding your suggestion for section 6 (incremental discovery), and 
made an issue of it, as I think I may detect a slight change of intended 
meaning.  I'd like to discuss this with my co-editor.

Individual responses below...

On 07/01/2012 16:18, Olaf Hartig wrote:
> Hello,
>
> I finally found the time to read the documents, in particular PROV-AQ. I like
> it very much!!
>
> In what follows, you find several comments and suggestions. Since all of them
> are minor, I didn't raise issues. If you think some of them should be raised,
> let me know which.
>
> * Sec.3: "Provenance information may be provided by several parties other than
> the provider of the original resource, ..." -- It's not entirely clear what
> "the original resource" is. More precisely, what is lacking in this sentence
> is the relationship between "the original resource" and the provenance
> information. I propose to write: "Provenance information about a resource may
> be provided by several parties other than the provider of that resource, ..."

Thanks, that's much better!  Done in working copy.

> * Sec.3: "Once provenance information information is retrieved, one also needs
> to know how to locate the view of that resource within ..." -- This sentence
> contains "information" twice. More importantly, it's not clear what "that
> resource" refers to in this sentence. Hence, I propose to begin the sentence
> as follows: "Once provenance information about a resource is retrieved ..."

Ditto, thanks.

> * Sec.3.1: "When used in conjunction [...] this HTTP header field indicates
> that provenance-URI is the URI of some provenance information associated with
> the requested resource and that the associated entity is identified as entity-
> URI." -- Since there may be multiple entities associated with the requested
> resource (and, thus, multiple entity-URIs), I guess the implicit assumption of
> this sentence is the following: The entity referred to in a Link header field
> (via anchor="entity-URI") is the entity which is used for the requested
> resource in the provenance information referred to in the same Link header
> field. If that's correct, then we may want to make this assumption explicit by
> extending the sentence as follows: "... and that the associated entity is
> identified *within the referenced provenance information* as entity-URI."

Ditto, thanks.

> * Sec.3.1.1 contains the TODO "It needs to be checked as to whether it is
> useful." -- I'm not sure how the usefulness may be checked but the proposal
> looks sound and reasonable to me.

Thanks.  More generally, I think that something that Paul and I need to do 
before the next public release is work through these annotations and dismiss 
some of them.

> * Sec.3.1.1: "There may be multiple provenance-service link header fields, and
> these may appear in the same document as provenance links ..." -- What does
> "the same document" refer to? Furthermore, I don't understand how a
> provenance-service link may appear as a provenance link.

That's a cut-and-paste error: it should have been "same HTTP response".

I'm a little puzzled by the second part of this comment: provenance-service and 
provenance are separate links.  Is this not clear?

The paragraph now reads:
[[
There may be multiple <code>provenance-service</code> link header fields, and 
these may appear in the same HTTP response as <code>provenance</code> link 
header fields (though, in simple cases, we anticipate that 
<code>provenance</code> and <code>provenance-service</code> link relations will 
not be used together).
]]

> * Sec.3.2: "The entity-URI given by the anchor link element specifies an
> identifier for the presented document view, and which may be used within the
> provenance information when referring to this document." -- What is "the
> presented document view"? I propose to adjust this sentence as follows: "...
> specifies an identifier for the entity that may be used within the provenance
> information when referring to the document."

Thanks. Done.

> * Sec.3.3: I assume the RDF properties introduced in this section
> (prov:hasProvenance, prov:hasAnchor, and prov:hasProvenanceService) may not
> only be used for the resource that is represented as RDF but also for any
> resource that the RDF representation describes. If that's true, we may want to
> add a corresponding comment to this section (although I understand that this
> is not the focus of this section).

I added this to the initial paragraph: "(The same RDF terms may be used to 
indicate provenance of other resources too, but discussion of such usage is 
beyond the scope of this section.)"

> * Sec.4, 3rd paragraph: "This approach may be preferred when the provenance
> service cannot specify the form of URIs used for identifying provenance
> information, or when there may be more than one source of provenance
> information known to the provenance service." -- While I understand the second
> case, I have no idea what the first case means.

I agree, that was hard to follow.

Is this any better?: "This approach may be preferred when the URIs used for 
identifying provenance information are controlled by someone other than the 
provider of the provenance discovery service, or when there is more than one 
known source of provenance information."

> * Sec.4.1.1, 3rd step: Since the important part of this step is not the use of
> the template but the generation of the provenance-locations-URI, I propose to
> rephrase the sentence as follows: "Form a provenance-locations-URI by using
> the provenance locations template with entity-URI as a substitute for template
> variable uri."

That's better, thanks. Done.

> * Sec.4.1.1: "Any or all of *the* URIs in the ..."

Done.

> * Sec.4.1.2: "To use [...], starting with [...] the URI of the resource or
> context (entity-URI)" -- Replace context by entity (as in Sec.4.1.1).

Thanks - I thought I'd caught all of those.

> * Sec.4.1.2, 3rd step: Similar to Sec.4.1.1, I propose: "Form a provenance-URI
> by using the provenance information template with entity-URI as a substitute
> for template variable uri."

Done.

> * Sec.4.2.1: "Dereferencing the service URI returns a representation of this
> service description." -- Better: "Dereferencing *a* service URI returns a
> representation of *such a* service description."

Done.

> * Sec.4.2.2: "The examples below [...] and using the service description
> example above, its URI would be ..." -- "its URI" is misleading here because
> the URI is not the URI of the service description example. I propose: "The
> examples below [...] and using the service description example above. Hence,
> the URI of the corresponding provenance locations resource would be ..."

Done (also deleting "using").

> * Sec.6.1, step 1: I propose the following sentence instead: "For a given
> resource obtain its associated provenance-uri-1  and its associated entity-
> uri-1 using ..."
 >
> * Sec.6.1, step 4: "... find its provenance-URI and continue from Step 1." --
> It should be: "... from Step 2."
>
> * Sec.6.1, step 4: I propose to change the Note to: "an HTTP HEAD request for
> entity-uri-2 may be used ..."
>
> * Sec.6.1: "To reduce the overhead of multiple HTTP requests ..." -- I suggest
> to consider providing such prov:hasProvenance links as preferred practice and
> to adjust the paragraph accordingly.

At the time of writing this, I can't be sure this does not change the meaning of 
the words, so I'm posting this as an issue.

> Finally, it would be nice to link my name in the authors list to
> http://olafhartig.de  ;-)

Of course! Done.

#g

Received on Monday, 9 January 2012 15:20:42 UTC