- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Mon, 11 Mar 2013 09:59:03 +0000
- To: W3C provenance WG <public-prov-wg@w3.org>, Luc Moreau <l.moreau@ecs.soton.ac.uk>
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