PROV-AQ responses to Luc's review

Luc (http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0082.html)

 >>> My responses are prefixed like this.

- 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"
 >>> I think "provenance access and services" is a reasonable title, but this 
may make work for other editors.
 >>> I also thing the document in its current form also reflects access and 
query, including the pingback which is really just a different provenance 
discovery mechanism,
 >>> Raised issue https://www.w3.org/2011/prov/track/issues/632


Comments below.

1. Layout. The external link sign does not seem to print, and leaves a
white space.
 >>> Fixed.  Here's the revised CSS:

a.externalRef:after {
content:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAVklEQVR4Xn3PgQkAMQhDUXfqTu7kTtkpd5RA8AInfArtQ2iRXFWT2QedAfttj2FsPIOE1eCOlEuoWWjgzYaB/IkeGOrxXhqB+uA9Bfcm0lAZuh+YIeAD+cAqSz4kCMUAAAAASUVORK5CYII=);
}

 >>> (Though I think Paul said he had a problem with this when staging.)


2. Constrained resource definition: it's -> its
 >>> fixed


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 ...
 >>> I think "query" *is* appropriate.  It *is* a kind of query.
 >>> Raised as issue; no change currently applied
 >>> http://www.w3.org/2011/prov/track/issues/632


4. Locating provenance descriptions definition.
   It does not seem to allow for a service (as opposed to section 3)
 >>> Good catch - added "or provenance query service" and rework sentence 
accordingly.

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.

 >>> I think it's an important point to make, but here it's maybe not so well made.
 >>> I've extensively re-worked the language in section 1.2


6. section 1.4
   prov:ProvenanceQueryService -> prov:ProvenanceService
 >>> Removed reference in response to a previous comment


7. Ping back is a mechanism to record arbitrary provenance.  Not
    reflected in title. If we keep this mechanism, ProvenanceService should
also
     support it.
 >>> Pingback is *not* a ProvenanceQueryService.  (ProvenanceService no longer 
exists.)  It's a kind of discovery mechanism.
 >>> Some up-front introduction of "Forward provenance" has been added in 
sections 1 and 1.1


8. section 2, nice to talk about bundle. Both prov-n/prov-xml also
have a provenance document which could be mentioned here.
 >>> The discussion has been revised in response to other comments, and moved to 
a note to make it clearer that it's not actually part of the spec.


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.
 >>> They are different but overlapping roles. I think I agreed elsewhere that 
we could use "consumer" for "requester" in this context.  The same applies to 
"client" in section 3.  I think other references to |"client" are more related 
to that specific role in an HTTP transaction.
 >>> I agree 'publisher' should be 'provider'
 >>> This text has been revised, and the reference to publisher is not the 
provenance provider.
 >>> Definitions have been moved forward to the section 1.1 (concepts )


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.
 >>> Disagree.  The specific reference to consumer in this section does assume 
that provenance data is being analyzed. (Otherwise, I would probably have used 
'receiver')
 >>> No further change here, but the related text has been reorganized in 
repoonse to other comments.


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
 >>> Probably could be clarified.  I've been trying not to dwell too much on 
edge cases, which I think this is.
 >>> Covered in the general case by section 1.3
 >>> Also raised as https://www.w3.org/2011/prov/track/issues/628


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
 >>> That's not prohibited, but I see it as another edge case that I don't see 
any need to dwell upon.
 >>> Added "(and anchors)", and an earlier cross-reference to further discussion 
in section 1.3


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.
 >>> Changed to <service-URI> for consistency


13. section 3.1.1 (though in simple cases ...) Not sure what this
brings, I would delete, since the previous sentence says "may".
 >>> Deleted sentence.


14. There is a section 3.2.1 but no 3.2.2.
 >>> Indeed there is.  I don't see a problem there.
 >>> No change


15 section 4: "HTTP query protocol for accessing ..."
     is the word query appropriate here?
 >>> I really think it is.  We may need to discuss this.  It's a very simple 
query protocol where the query is encoded in a URI.  (I observe that SPARQL 
queries can be similarly encoded in URIs, but that's too complex a formukation 
to describe with a URI template.)
 >>> In reworking the text, I am referring to this as "Direct HTTP query service"


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.
 >>> It's not mandated by the current text.  The revised text should make this 
clearer.  But only an RDF form of service description is described by this 
document - others are form other specifications to define.
 >>> Also raised as issue https://www.w3.org/2011/prov/track/issues/425


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.
 >>> I'm OK with this (add '123' to target URI in example)
 >>> Done.


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.
 >>> I've now taken a different stance, that the mechanisms are independent of 
provenance format used.  But that provenance publishers are suggested to use 
PROV-O in RDF for interoperability.  This is in the introduction, and I no 
longer mention provenance formats when describing the mechanisms.
 >>> See issue https://www.w3.org/2011/prov/track/issues/428


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.
 >>> It is different, but it was requested by WG members.  I think it was agreed 
at the last F2F to add this?  I also think it's a good idea.
 >>> In response to other comments, this is signposted earlier in the document.
 >>> Following Stian's proposal, the mechanism has been changed in a subtle but 
important way, which means it now functions as a discovery mechanism and as such 
I think it is quite consistent in style and intent to other parts of the 
document.  I have taken care to make this a minimal mechanism for discovery that 
places no additional requirements on how forward provenance is handled.
 >>> See also: https://www.w3.org/2011/prov/track/issues/618

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.
 >>> That's not making any sense to me.

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.
 >>> I disagree here.  As far as I can see, it's just adding complexity for no 
discernible benefit.
 >>> No change made


20. section 5: again, we shouldn't mandate rdf to be posted.
 >>> Given the revised mechanism, there is no mention of provenance format for 
forward provenance.  This is one reason that I enthusiastically embraced this 
change - it keeps the actual mechanism completely separate from provenance 
format, and allows the full flexibility of content negotiation to be deployed.


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.
 >>> OK, I think the revised text makes it clear that additional information is 
optional.  I think the text to which you referred has now been removed.


22. This is to become a note. Should we use IETF MUST/SHOULD/MAY
conventions?
 >>> Left to myself, I probably would not.  But we've had this discussion, and 
others have argued that they help to clarify what is being specified.  I go with 
the consensus.
 >>> Unless there's a strong request to change this, I propose to leave as-is.

Received on Monday, 11 March 2013 10:01:55 UTC