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

Hi All,

While I'm enjoying people discussing my thesis and I agree with Luc it
could be considered a potential design, I didn't write up the contribution
and submit it for consideration by the group whereas Tim and Stian did. So
that's my own fault.

I think the core issue is the role of the note. Graham's position is that
this is very much something to go and try and out so it's not as formal. I
think we have other notes that we do consider in a more formal sense (e.g.
the Primer, prov-xml). I'd like to here Ivan's commentary on this one.

This is the crux of the matter. We can go with an idea and wait for
implementation experience.

One thing that we can do is to ask people what they think of pingback. We
just published a working draft. If we get support from a wider audience
then this argues in favour of keeping it in. If we get hard questions on
the mechanism, then this doesn't.

Can I ask people to ping people they know? We can also write a blog post
(the solution to all problems) asking people specifically for input.

cheers
Paul





On Tue, Mar 12, 2013 at 1:56 PM, Timothy Lebo <lebot@rpi.edu> wrote:

> I think Stian and Graham have covered any response that I would make,
> and they have done so much more eloquently than I could.
>
> I am in favor of keeping ping back in the note.
>
> Regards,
> Tim
>
>
> On Mar 12, 2013, at 7:45 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk>
> wrote:
>
> > 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
> >>> --
> >>>
> >>>
> >>
> >
> >
> >
>
>
>


-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam