- From: Paul Groth <p.t.groth@vu.nl>
- Date: Fri, 18 Jan 2013 09:57:35 +0100
- To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
- Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Message-ID: <CAJCyKRq8aw1Wo5zgS8dBkLH3QphEcJxLOQ=OU37Vj1ZYYqY+8Q@mail.gmail.com>
Hi Graham, Here are Luc's comments, somehow they didn't make it into the archive. Paul ---------- Forwarded message ---------- From: Luc Moreau <l.moreau@ecs.soton.ac.uk> Date: Wed, Jan 16, 2013 at 3:35 PM Subject: {Disarmed} Re: prov-aq review for release as working draft (ISSUE-613) To: "public-prov-wg@w3.org" <public-prov-wg@w3.org> Hi Paul and Graham, Thanks for producing a new version of prov-aq. I think it's much improved. Find my review below. Luc ------------------------------------------------------------------- Questions for reviewers - Can this be released as a last call working draft? yes - Is the name provenance access and query appropriate for the document? No. Access yes, query very very little, ping back (if too stay in document) not reflected. I would go for "provenance access and services" - If not, where are the blocking issues? - If yes, are there other issues to work on? Comments below. 1. Layout. The external link sign does not seem to print, and leaves a white space. 2. Constrained resource definition: it's -> its 3. Provenance query service definition. I believe this name is not appropriate. I would suggest "provenance service". ... and change definition: .. a query service ... -> ... a service ... 4. Locating provenance descriptions definition. It does not seem to allow for a service (as opposed to section 3) 5. Section 1.2 "Provenance descriptions, to be useful, must be persistent and not themselves dependent on context" Not sure why: provenance embedded in a document is not persistent. Why can't provenance descriptions be dependent on context? In any case, this does not seem enforceable. I would drop 'must'. In fact I would drop the whole senentce. 6. section 1.4 prov:ProvenanceQueryService -> prov:ProvenanceService 7. Ping back is a mechanism to record arbitrary provenance. Not reflected in title. If we keep this mechanism, ProvenanceService should also support it. 8. section 2, nice to talk about bundle. Both prov-n/prov-xml also have a provenance document which could be mentioned here. 9. Section 3: terminology provider/consumer is introduced but not used consistently. Later, the text mentions 'requester', how different is this from consumer? It also mentions client/publisher. Why all these variants? If the variants are kept, then drop definitions. 9 section 3, definition of consumer: I don't think that a consumer needs to interpret provenance. My definition: ... is an agent that requests and receives provenance descriptions. 10. The mechanisms described in 3.1 (http), 3.2 (html), 3.3 (rdf), while using the same prove-uri/target-uri, interpret their combinations differently. These should be noted. 1 provenance-uri for one target-uri in http all provenance-uri for all target-uri in html/rdf 11. "An http response may include multiple hasProvenance link header fields, indicating a number of DIFFERENT PROVENANCE RESOURCES" We should also support multiple hasProvenance link header fields with different anchor URIS 12. section 3.1.1 The text has both provenance-service-URI and service-URI, which I believe, are intended to be the same. Given my suggestion of naming the service "provenance service", is would prefer provenance-service-URI everywhere. 13. section 3.1.1 (though in simple cases ...) Not sure what this brings, I would delete, since the previous sentence says "may". 14. There is a section 3.2.1 but no 3.2.2. 15 section 4: "HTTP query protocol for accessing ..." is the word query appropriate here? 16. I am not in favor of mandating RDF as the format for service descriptions and posting provenance. Popular services on the Web use json or xml only. Mandating RDF will slow down adoption for these providers. 17 section 4.2: i would suggest to *MailScanner has detected a possible fraud attempt from "http:" claiming to be* http:/www.examplec.om/entity123 <http:/www.examplec.om/entity123> as the target uri to show it's an isntance. 18 section 4.2: "A provenance query service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]]." Again, we shouldn't mandate any format. We should leave everything to content negotiation, and say that mime type for serializations (rdf/prov-n/prov-xml) of prov-dm would typically be expected here. 19. Section 5. This section comes out of the blue. It's not clear to the reader why we want this. It really feals like something entirely different. I am not convinced it belongs here. Should we keep it, if we allow services to be used to access provenance, we should also allow services to be used to access provenance. So, I would like to see to templates: provenanceAccessUriTemplate and provenanceRecordUriTemplate because there may be other service specific parameters to provide for posting provenance. We could also have a anchor uri parameter, to keep the parallel with access. 20. section 5: again, we shouldn't mandate rdf to be posted. 21. I didn't understand the commen below the last figure of section 5. Is it a requirement or not to return those links. I couldn't really see what was being achieved here. 22. This is to become a note. Should we use IETF MUST/SHOULD/MAY conventions? On 01/10/2013 05:21 PM, Paul Groth wrote: Following up - the due date for review is next thursday January 17, 2012 Thanks Paul On Thu, Jan 10, 2013 at 4:13 PM, Paul Groth <p.t.groth@vu.nl> wrote: > Dear all, > > PROV-AQ is now ready for review. This should be considered as a "last > call" working draft version. > > You can find the draft to review at: > > https://dvcs.w3.org/hg/prov/raw-file/b3f397c7b15c/paq/prov-aq.html > > Tim, Simon, Luc, Dong and Stian agreed to review but all comments are > appreciated. > > Questions for reviewers > - Can this be released as a last call working draft? > - Is the name provenance access and query appropriate for the document? > - If not, where are the blocking issues? > - If yes, are there other issues to work on? > > We particularly encourage reviewers to look at Section 5 Forward > provenance as this is a new section. > > In your review please include ISSUE-613 > > Thank you, > Paul and Graham > > -- your friendly prov-aq editors > > > -- > -- > Dr. Paul Groth (p.t.groth@vu.nl) > http://www.few.vu.nl/~pgroth/ > Assistant Professor > - Knowledge Representation & Reasoning Group | > Artificial Intelligence Section | Department of Computer Science > - The Network Institute > VU University Amsterdam > -- -- Dr. Paul Groth (p.t.groth@vu.nl) http://www.few.vu.nl/~pgroth/ Assistant Professor - Knowledge Representation & Reasoning Group | Artificial Intelligence Section | Department of Computer Science - The Network Institute VU University Amsterdam -- Professor Luc Moreau Electronics and Computer Science tel: +44 23 8059 4487 University of Southampton fax: +44 23 8059 2865 Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk United Kingdom http://www.ecs.soton.ac.uk/~lavm -- -- Dr. Paul Groth (p.t.groth@vu.nl) http://www.few.vu.nl/~pgroth/ Assistant Professor - Knowledge Representation & Reasoning Group | Artificial Intelligence Section | Department of Computer Science - The Network Institute VU University Amsterdam
Received on Friday, 18 January 2013 08:58:03 UTC