W3C home > Mailing lists > Public > public-prov-wg@w3.org > March 2013

Re: [PROV-AQ] ISSUE-618: Should pingback be described in PROV-AQ?

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Mon, 11 Mar 2013 22:50:35 +0000
Message-ID: <EMEW3|47a99a7f5e843542d4be3c58dd022f86p2AMp208l.moreau|ecs.soton.ac.uk|513E5FBB.6020008@ecs.soton.ac.uk>
To: public-prov-wg@w3.org

Hi ,

I have now read the new ping back functionality.  To say the least, it's 
radically different from the original one.

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.

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.

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.

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.

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.

6.  The rest of the PAQ was driven by the scenario 
      I don't know what the  scenario is for ping back.

7. I don't think the group in the eleventh hour should try to define 
this scenario.

My recommendation is to:
- put in our wiki Tim's original proposal for ping back
- 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.


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
> -- 

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 Monday, 11 March 2013 22:51:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:32 UTC