- From: Miles, Simon <simon.miles@kcl.ac.uk>
- Date: Mon, 11 Mar 2013 10:57:29 +0000
- To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, W3C provenance WG <public-prov-wg@w3.org>
Graham, Thanks, I'm happy with your responses/changes to my review. Simon Dr Simon Miles Senior Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166 Efficient Multi-Granularity Service Composition: http://eprints.dcs.kcl.ac.uk/1396/ ________________________________________ From: Graham Klyne [graham.klyne@zoo.ox.ac.uk] Sent: 11 March 2013 10:00 To: W3C provenance WG; Miles, Simon Subject: PROV-AQ responses to Simon's review 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:57:59 UTC