W3C home > Mailing lists > Public > public-prov-wg@w3.org > March 2013

PROV-AQ responses to Simon's review

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Mon, 11 Mar 2013 10:00:19 +0000
Message-ID: <513DAB33.6080900@zoo.ox.ac.uk>
To: W3C provenance WG <public-prov-wg@w3.org>, Simon Miles <simon.miles@kcl.ac.uk>
Simon (http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0061.html):

>>> My responses are prefixed like this.

In the intro bullet list of Section 1, "forward provenance" is mentioned for the 
first time. It would be good to give brief intuition about what this is, as it 
may not be obvious to the readers.

>>> Done.  Also added entry in section 1.1 (Concepts)

In Section 3, the term "consumer" is defined, but then "requester is used in 
later paragraphs, including the mechanism bullet list, and then "client" a bit 
further down. I was not clear if these were the same or related concepts.

>>> Good point.  I think they are same in this context.
>>> s/requester/consumer/ applied, and added entries in section 1.1 (Concepts)

Section 3.1 says "Provenance indicated in this way is not guaranteed to be 
authoritative". Isn't this true of all the access mechanisms, not just the one 
described in Section 3.1?

Maybe this should be moved up to section 2, following the para that starts "How 
much or how little provenance..."?

>>> Good point.
>>> The text has been removed from section 3.1, and the same point is made in
section 1.3 (rather than section 2)

Section 4.1 does not say (as far as I could see) whether the RDF returned from 
dereferencing a service URI would include any triples for which the subject was 
not the service, i.e. any other RDF data. If it can, then I don't see it is 
guaranteed the client could unambiguously extract the information that described 
the appropriate query service (especially if the RDF describes more than one 
provenance query service). Shouldn't there be some restriction on what the RDF 
contains?

>>> I accept some clarification might be in order, but I disagree that the RDF
should be restricted.  The RDF service description may describe an open-ended 
list of service endpoints whose URIs may be different from the initial service 
URI dereferenced.  If there are also other RDF statements in the graph returned, 
I don't see that is a problem.
>>> Applying Stian's proposal has made the structure more obvious (IMO), but I
notice that I've not said anything explicitly about including additional 
statements in the RDF returned.


The new section, Section 5, seemed fine to me.

>>> Thanks!  Please note it has been revised since your review in response to
Stian's proposal.


Typos:

  - Section 1.1, Constrained resource definition: "it's" -> "its"
>>> Fixed

  - I don't know why the last sentence of Section 1.3 or the Dereferences column 
for Pingback-URI are in parentheses.
>>> Agree the intent was unclear.  I've rearranged thus "None specified (...)"

  - First sentence of last paragraph of Section 2, there seems to be too much 
italics.
>>> Maybe so.  It's a <cite> style because I was quoting from PROV-DM.  The
text has been rearranged slightly and I've added quotes - hopefully it's easier 
to read now.

  - Section 4, paragraph 3, final sentence has too many "not described here"s.
>>> Agree - fixed.
Received on Monday, 11 March 2013 10:01:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:23 UTC