- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Tue, 12 Mar 2013 11:45:04 +0000
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
On 11/03/2013 22:50, Luc Moreau wrote: > > Hi , > > I have now read the new ping back functionality. To say the least, it's > radically different from the original one. Actually, it's only different in a small way: the mechanism is by-reference rather than by-value. That has significant implications, mainly simplification, but the underlying idea is very similar. > > Here are a few comments. > > 1. I am not convinced by the "forward provenance/historical provenance" > terminology. I think it's confusing, > in particular, given that all provenance is meant to be historical. > I find the term quite evocative, but I don't want to get hung up on that. I'm open to others. > 2. In the previous draft, I commented that we didn't have a good set of > requirements for the design space > of the "old ping back" mechanism, that essentially allowed arbitrary > recording provenance statements. > The argument still holds here, for the new mechanism. > I think we had a fairly good requirement, even if it wasn't explicitly articulated. Roughly: "I want a way to find out what people do with my published resource." > 3. Terminology is forward/historical provenance is misleading. Really, it's > provenance from two different > perspectives the consumer of an entity and its producer. > > The current document lists questions such as "what was this resource based > upon?, how was it constructed? > who made it? when was it made?" which could perfectly well be answered by > provenance asserted by the consumer of the resource. That's exactly what the text says. It then goes on to say what different questions are addressed by "forward" provenance. Maybe the text needs to more emphatically make the distinction that;'s being made. > 4. There is actually some precedent here. Someone, called Paul Groth, > discussed how a client and a service > can share the locations of the stores in which they respectively record > provenance. > See section 4.3.3 http://users.ecs.soton.ac.uk/pg03r/Thesis.pdf > > In short, transposed to the PAQ, a get request could contain a > provenance-uri/provenance-service-uri indicating where provenance > related to the current request can be found ... linked to it, we will > find the response, and any statement made by the client about > the retrieved resource. > > No more ping back, no more posting of provenance-uris to pingback uri, > just make sure you exchange > provenance-uri/provenance-service-uri in both request and response. > I can't see how that addresses the goal of forward provenance. In pure information terms, it's about discovering information that the original publisher has no other way to know about using the existing mechanisms, and without cooperation of future users of the published resource. I would expect that Paul would have mentioned this if he thought his own work would address this. We did discuss his prior work in passing, but from what he said that was more to do with aspects of provenance storage, which the pingback proposal very carefully avoids saying anything about. There's one sentence from Paul's thesis that makes a big difference, IMO: " We assume that A knows from its configuration that B always stores its p-assertions in PB.". The point of the forward provenance mechanism is that the provider of forward information is unknown and unknowable to the publisher of a resource when the resource is published. This, I would suggest, is a dominant interaction style in the World Wide Web. Earlier (section 4.3.1) we have: "Either such knowledge is built into A, or it is communicated to A in the course of application execution". I would suggest that the pingback described here is exactly a mechanism that allows such communication to take place. Indeed, in terms of Paul's thesis, I think pingback could be offered as _a_ minimal mechanism for interacting parties in the web to exchange "View links" and "Cause links", outside the scope of a direct interaction. (Where there is direct interaction, the previously described mechanisms apply.) > 5. Obviously, the new ping back and Paul's protocols are not equivalent, > but they are two points in a space of solutions. > Why should we prefer one over the other? > I would argue that we cannot because we have not identified the > requirements we are trying to address. I don't think they are two points in a space of solutions so much as mechanisms operating at different levels. My reading of Paul's mechanism is that it takes place in the context of a direct interaction between cooperating agents, and as such is able to offer a complete solution for creating a provenance graph in the context of such interaction. By comparison, the pingback, in conjunction with the other PROV-AQ mechanisms, proves a mechanism which _might_ be used as part of the mechanisms Paul describes, but does not attempt to provide such a complete solution. But, crucially, the pingback is also applicable in situations where one or more of the parties contributing to an overall provenance graph is unknown to the other(s). > 6. The rest of the PAQ was driven by the scenario > http://www.w3.org/2011/prov/wiki/ProvenanceAccessScenario > I don't know what the scenario is for ping back. Pingback likewise. http://www.w3.org/2011/prov/wiki/Provenance_ping-backs > 7. I don't think the group in the eleventh hour should try to define this > scenario. Hardly eleventh hour. It's been under consideration for over a year now. > > > My recommendation is to: > - put in our wiki Tim's original proposal for ping back Er, I'm not aware that Tim proposed a mechanism so much as a set of requirements. The current proposal (arrived at through some iteration) was intended to address those requirements. > - put in our wiki put in our wiki Stian's proposal for ping back > - add a future work/other issues section to the PAQ with reference to the two > wiki pages, a link to this issue. > This will ensure that the work is not lost, and still referenced from the PAQ, > while not formally part of it. > Well, that's a choice, but the current mechanisms have been significantly reviewed that inclusion in a NOTE is not inappropriate. If this document were to be a REC, I'd be fully in agreement with your position that an untried mechanism like Pingback is inappropriate. (The same *could* be said of all the mechanisms that are documented in PROV-AQ.) If thePingback were radically different from the other mechanisms in PROV-AQ, I'd be more inclined agree with you, but it is really a very small extension of what is already there: using a combination of existing HTTP and link-passing mechanisms to provide access to information. My own concern is that if we park the material in the wiki, it *will* be lost for practical purposes. We have a low cost, low risk mechanism available to make this material available for ongoing reference, discussion and experimentation, specifying a mechanism that several people have expressed interest in, and I'm not seeing any compelling reason why we shouldn't use it. #g -- > > On 11/03/13 11:05, Graham Klyne wrote: >> Re: http://www.w3.org/2011/prov/track/issues/618 >> >> "Some reviewers have commented that the provenance ping back description may >> be out-of-place in the PROV-AQ document. >> >> This issue is a place-holder to bring this to a group vote, when the current >> PROV-AQ editing round is done. (One reason for this delay os that Stian has >> proposed a small change to how pingback may work that could make it function >> more like an alternative discovery mechanism." >> >> PROPOSE: to keep Pingback in PROV-AQ as described at >> http://www.w3.org/TR/2013/WD-prov-aq-20130312/#forward-provenance >> >> ... >> >> My thoughts: >> >> There was a legitimate concern that the original Pingback proposal was >> pushing the scope of PROV-AQ beyond "Access and Query", and associated >> discovery functions. >> >> In my view, the revised proposal (substantially as suggested by Stian) >> substantially reduces this scope extension, as the pingback is now simply a >> provenance discovery mechanism, aimed at provenance which can be created only >> after the original resource is published, and is hence not amenable to the >> other defined mechanisms. >> >> Several working group members have expressed interest in the capability >> provided by this mechanism. As this document is NOTE, not a REC, I think it >> is reasonable to publish something that we has received significant >> consideration by several WG members, to encourage some commonality in >> deployment of the desired capability. A future WG in this area may look to >> any deployment experience (or lack of) in deciding whether or not the >> specifications would usefully be progressed on a recommendation track, or >> equivalent. >> >> #g >> -- >> >> >
Received on Tuesday, 12 March 2013 11:46:23 UTC