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

Hello,

I agree that evidence of usefulness would be good. At present, I would support keeping the pingback mechanism. I think it is potentially useful, no less tested than the access mechanisms, and it is not compulsory to implement as part of supporting PROV or the rest of PAQ (though this could be emphasised more in the document).

With regards to the Note status, I find pingback less controversial than PROV-Links and see it as no less tested than PROV-Dictionary, and it has the same status as each.

I agree with Luc that "forward provenance" and "historical provenance" are terrible names. There are similar (and similarly unpleasant) terms in circulation used for different concepts, which may also cause confusion. It also suggests a false distinction: the provenance data is exactly of the same kind, it is all just provenance, only the means by which a particular agent (the resource/provenance provider) acquires it is different.

thanks,
Simon

Dr Simon Miles
Senior Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Efficient Multi-Granularity Service Composition:
http://eprints.dcs.kcl.ac.uk/1396/

________________________________________
From: Ivan Herman [ivan@w3.org]
Sent: 13 March 2013 11:09
To: Paul Groth
Cc: Timothy Lebo; Graham Klyne; Luc Moreau; public-prov-wg@w3.org
Subject: Re: [PROV-AQ] ISSUE-618: Should pingback be described in PROV-AQ?

On Mar 13, 2013, at 12:00 , Paul Groth <p.t.groth@vu.nl> wrote:

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

Ivan cannot really comment:-) What the goal of a Note is up to the group to decide, as long as this is clearly stated. So maybe the status section (or the abstract) of a note may include a reference to whether that note is considered to be 'experimental' or 'final'. Of course, an additional matter is a certain level of consistency among all our notes. But an explicit wording in text would be helpful anyway.

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

I think that is the right thing to do.

Ivan

> 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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Wednesday, 13 March 2013 11:21:18 UTC