Re: PROV-AQ responses to Tim's review

Thanks, Graham.

-Tim

On Mar 11, 2013, at 6:00 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk> wrote:

> Tim (http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0064.html):
> 
>>>> My responses are prefixed like this.
> 
> 1)
> copy/paste error:
> PROV-DM (Candidate Recommendation), the PROV data model for provenance (this document);
>>>> Fixed
> 
> 2)
> Should "PROV-AQ" be linked in:
> PROV-AQ (To be published as Note), the mechanisms for accessing and querying provenance (this document);?
>>>> Agree, should be removed (Ivan also noted). This should be handled during
> staging, as the text is all being replaced.
> 
> 3)
> I wonder if
> "B. Names added to prov: namespace"
> should become
> "B. _Terms_ added to prov: namespace"
>>>> Agree - done.
> 
> 4)
> "The Provenance Data Model [PROV-DM], Provenance Ontology [PROV-O] and related specifications (see the [PROV-OVERVIEW]) define how to represent provenance in the World Wide Web."
> suggest change to:
> "The Provenance Data Model [PROV-DM], Provenance Ontology [PROV-O] and related specifications define how to represent provenance in the World Wide Web (see the [PROV-OVERVIEW])."
>>>> Done.
> 
> 5)
> The reference to "(see section 1.2 for discussion)" in the definition of Target-URI #dfn-target-uri seems like too much of a crutch. And, going there does not seem to clarify the concept as much as the reference seems to suggest.
> I suggest to remove the "(see section 1.2 for discussion)" in the definition of Target-URI, and if something is "missing" in the definition to simply add it there.
>>>> I think I agree - if any definition should have this forward link, it's
> "Constrained resource".  Text reorganized along these lines.
> 
> 6)
> Provenance description
> refers to provenance represented in some fashion.
> Why the need for "description"? The DM's definition for provenance is that it is a "record" [1], which _is_ a description and "represents in some fashion." Using more terms for the same concept seems like it could confuse readers.
> [1] http://www.w3.org/TR/prov-dm/#introduction
>>>> In response to this and other comments, the text now uses "provenance
> record", for consistency with other PROV documents (esp. PROV-DM, IIRC).
> 
> 7)
> Provenance query service
> a query service that provides a provenance description given a target-URI or other information about the desired provenance.
> Service-URI
> the URI of a provenance query service.
> These two definitions do not seem to be aligned. A Provenance query service is a query service, but the URI that denotes it is simply a "Service URI"? Since a service is more general than a query service (and, a provenance query service).
> If this is done for brevity, I guess it's reasonable. But it reads oddly in isolation.
>>>> I couldn't think of suitably brief alternative. "query-uri" doesn't really
> fit.  No change here, but the language around query services has been reviewed through the document to be more query oriented.
> 
> 8)
> Similar to 5) above, why use a section reference for a crutch in a definition? Or, why don't they _all_ have a section reference?
> "see section 5. Forward provenance)"
>>>> There have been several changes around here, so I've lost the original
> referent of this comment.  But I think the offending forward reference you refer to is gone.
> 
> 9)
> Section 1.2 Provenance and resources spends a few paragraphs describing "prov:specialization" without actually talking about prov:specialization.
> It leaves a sense that "resources are slippery" without much promise that it will be adequately addressed by PROV.
> Suggest to add a line at the end of 1.2 foreshadowing how this kind of situation will be addressed.
>>>> I've added text that more specifically relates the material to "entity" and
> "specialization" in [PROV-DM] (and, by implication, PROV-O).
> 
> 
> 10)
> 1.4 URI types and dereferencing
> What does "actual" in
> "actual URIs for accessing provenance descriptions are determined via the query service description." mean?
> It seems to imply that the Service-URI is _not_ an actual URI.
>>>> I've lost the "actually"
> 
> 
> 11)
> It seems to me that "individual" could be dropped from:
> "When there is no easy way to associate a provenance-URI with individual resources"
> since the "smallness", or "distinctness" is not really part of the condition for when to use a provenance query service.
> (I see that "multiple" is used later in that sentence, but I'm not sure why the multiplicity matters)
>>>> [section 2] s/individual resources/a resource/
>>>> Text re-worked.
> 
> 12)
> The following seems out of place in section 2:
> "When publishing provenance descriptions, corresponding provenance-URIs or service-URIs should be discoverable using one or more of the mechanisms described in section 3. Locating provenance descriptions."
> Perhaps if it were combined with the previous para-sentence, it would make sense (i.e., provenance-uris and service-uris should be included in "return enough")?
>>>> I haven't changed this text, but I think re-arrangement of the preceding
> material makes it follow more intelligibly?
> 
> 13)
> By the time I get to:
> 
> "The consumer of a provenance description will generally need to isolate information about some specific target resource or resources. These may be constrained resources identified by separate target-URIs than the original resource. In such circumstances, a provenance consumer will need to know the target-URI used by a provenance description."
> 
> I'm still not sure what a Target-URI is. Is it the URI of a provenance description? (I don't think so) Is it a possibly distinct URI that is used to denote the *same* resource about which we originally asked for provenance? (probably not "same", but "closeish" -- but what does "closeish" mean?) Hopefully some examples will come along to help clarify. If I request URI X and I'm given a Target-URI of Y, how do X and Y relate? I know I should find Y described in the given provenance-uri, but once I find it how do I know what it means w.r.t. URI X?
> 
>>>> I've lost track of the exact referent here, but I think the comment has
> been addressed by more general re-working of the text.
> 
> 14)
> When:
> The presence of a hasProvenance link in an HTTP response does not preclude the possibility that other publishers may offer provenance descriptions about the same resource. In such cases, discovery of the additional provenance descriptions must use other means (e.g. see section 4. Provenance query services).
> 
> should a reference to the forward provenance section be included, too?
> 
>>>> I don't see the need.  Forward provenance is a somewhat different topic
> than is covered here, IMO, and I think mentioning it here would be more confusing than helpful.  No change made.
> 
> 15)
> in:
> "An HTML document header may include multiple hasProvenance link elements, indicating a number of different provenance descriptions that are known to the creator of the document, each of which may provide provenance about the document."
> 
> suggest to add another sentence about the ambiguity of multiple anchors and multiple hasProvenances. Could refer back to section 3 where it is mentioned: "a client presented with multiple provenance-URIs and multiple target-URIs should look at all of the provenance-URIs for information about any or all of the target-URIs."
>>>> Hmmm.  I don't really want to repeat or labour information about what I
> think is an edge case.  I've added some material in  section 1.3 Interpreting provenance records, and added a cross-reference.
> 
> 16)
> Regarding:
> "It is recommended that this convention be used only when the document is static and has a stable URI that is reasonably expected to be available to anyone accessing the document (e.g. when delivered from a web server"
> couldn't one embed RDFa to give the URI of the document? If so, then we could relax the desire to keep it at a fixed location.
>>>> I agree that the requirement as-stated is slightly over-prescriptive.  The
> main requirement is that the document's URI is known or easily discovered by a consumer.  I've reworked the text (Section 3.2).
> 
> 17)
> Similar to 15) above, would be helpful to reinforce the "multiplicity problem" by referring back to the beginning of section 3.
>>>> Similar response.  Sections 3.1 and 3.2 have cross-reference to section 1.3.
> 
> 18)
> should:
> "returning a provenance for a particular resource"
> be:
> "returning a provenance description for a particular resource"
> ?
>>>> [sect 4, para 1, 4th bullet]  Yes, this is wrong.  Probably missed in last
> round of edits.
>>>> The text here has been generally re-worked.
> 
> 19)
> fantastic! I greatly appreciate how these are now two of many possible options.
> "if a recognized query mechanism is described, extract information needed to use that mechanism (e.g. a URI template or a SPARQL service endpoint URI); and"
>>>> No change requested :)
>>>> The latest changes have, if anything, gone further in this approach.
> 
> 20) [section 4.1.1]
> The suggestion to use a blank node should be avoided in 4.1.1:
> "where service-URI is the URI of the provenance query service, and query_option_node is any distinct RDF subject node (i.e. a blank node or a URI)."
>>>> I know blank nodes are sometimes controversial.  But I disagree that it's
> suggestion; it's an enumeration of the possibilities, and as such is correct RDF.  Propose no change.
> 
> I suggest to state the the RDF subject node is the URI of the service (which could be chosen by the server).
>>>> This is actually where I started, but actually backed away from.  I
> wouldn't prohibit it as an option, but I think that requiring it could create increased coupling between the service gateway that serves the description, and true actual corresponding service.
>>>> Stian's proposal, which has now been adopted, makes it more explicit that
> the overall service document and individual mechanism descriptions are, in general, different resources.
> 
> 21)
> "variable uri set to the target-URI for which provenance is required"
> ->
> "variable uri set to the target-URI for which provenance is requested"
> ?
>>>> Done.
> 
> 
> 22) [Section 4.1.2]
> Similar to 20) above, recommend to avoid encouraging a bnode in 4.1.2:
> "query_option_node is any distinct RDF subject node (i.e. a blank node or a URI)."
>>>> Same response as (20).  No change applied.
> 
> 23) [Section 5]
> Should the domains in "acme.example.com, and is subsequently used by wile-e.example.org" be in a different font style?
>>>> I agree.  Done.
> 
> 24)
> "is the provenance-URI that has been described previously." - cite the section with a link?
>>>> I agree.  Done.
> 
> 
> 25) [Appendix B]
> perhaps add to "Relates a resource to a provenance ping back service" so that it becomes:
> "Relates a resource to a provenance pingback service that may receive provenance about the resource."
>>>> I agree.  Done (adjusted for revised pingback details).
> 
>

Received on Monday, 11 March 2013 12:18:59 UTC