- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Wed, 16 Jan 2013 14:35:48 +0000
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|66cf14ebfebb4f94bb04cd61fb10a0f1p0FEZp08l.moreau|ecs.soton.ac.uk|50F6BAC4>
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
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
> <mailto: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 <mailto:p.t.groth@vu.nl>)
> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
> 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 <mailto:p.t.groth@vu.nl>)
> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
> 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
Received on Wednesday, 16 January 2013 14:38:11 UTC