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

RE: PROV-AQ responses to Simon's review

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>
Message-ID: <AA3FA22D967B5C4E8948AADF719DA7C4108B157D@AM2PRD0311MB409.eurprd03.prod.outlook.com>
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

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