Fwd: Re: prov-aq review for release as working draft (ISSUE-613)

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